El núcleo de Moodle se prueba a fondo contra cada versión antes de publicarse. Los plugins de terceros, el tema personalizado, la integración con videoconferencia, ese bloque que instaló alguien hace tres años y nadie recuerda para qué, no siempre reciben el mismo nivel de prueba. Y son, con diferencia, la causa más común de que una actualización de Moodle se rompa a mitad de camino.
En esta guía vas a ver cómo revisar tus plugins antes de actualizar, qué señales indican que uno está abandonado, y qué opciones tienes cuando un plugin crítico no tiene versión compatible con la versión a la que quieres saltar.
Por qué los plugins son el punto más frágil
A diferencia del núcleo de Moodle, mantenido por un equipo con proceso de pruebas formal, cada plugin depende del compromiso de su desarrollador individual, que puede ser una empresa con soporte activo, un voluntario de la comunidad, o alguien que lo publicó una vez y nunca volvió a tocarlo. Esa variabilidad es exactamente lo que convierte a los plugins en el eslabón más débil de cualquier actualización.
Los tres tipos de fallo más habituales:
- El plugin usa una función de PHP eliminada en la nueva versión, provocando un error visible al cargarlo.
- El plugin no se ha actualizado para adaptarse a cambios internos de la API de Moodle entre versiones, causando fallos silenciosos en funciones concretas.
- El plugin simplemente no tiene versión publicada compatible con la release destino, aunque siga funcionando en la actual.
Cómo revisar tus plugins antes de actualizar
1. Haz un inventario completo
Antes de nada, necesitas la lista exacta de plugins instalados, no solo “los que recuerdas”. Desde Site administration > Plugins > Plugins overview puedes ver todos los plugins activos, con su versión actual.
2. Consulta cada uno en el directorio oficial
Para cada plugin de terceros (no los que vienen con el núcleo), busca su página en el directorio oficial de plugins de Moodle y revisa:
- Si existe una versión publicada compatible con tu versión destino.
- La fecha de la última actualización, un plugin sin cambios en más de un año, mientras Moodle ha publicado varias versiones nuevas en ese tiempo, es una señal de alerta.
- Si el desarrollador responde a incidencias reportadas recientemente en la sección de comentarios o issues del plugin.
3. Prueba en staging, no confíes solo en la documentación
Que un plugin declare compatibilidad con tu versión destino no garantiza que funcione al 100% en tu instalación concreta, con tu configuración y tus datos. La única confirmación fiable es probarlo activamente en un entorno de pruebas antes de tocar producción, lo cubrimos en detalle en cómo crear un entorno de pruebas (staging) de Moodle.
Señales de que un plugin está abandonado
| Señal | Qué indica |
|---|---|
| Última actualización hace más de 12-18 meses | El desarrollador puede haber dejado de mantenerlo activamente |
| No hay versión compatible con las últimas 2 releases de Moodle | Alto riesgo de que tampoco haya versión para tu próxima actualización |
| Comentarios o issues sin respuesta desde hace meses | Soporte inexistente si algo falla tras actualizar |
| El propio plugin recomienda una alternativa en su descripción | El desarrollador ya ha dado por cerrado el proyecto |
Qué hacer si un plugin crítico no tiene versión compatible
Tienes, en esencia, cuatro opciones:
- Buscar una alternativa mantenida que cubra la misma función, disponible en el directorio oficial.
- Mantenerte en tu versión actual hasta encontrar sustituto, asumiendo el riesgo de seguir en una versión cada vez más cerca de quedar sin soporte de seguridad.
- Desactivar el plugin durante la actualización, si su función no es imprescindible, y decidir después si merece la pena sustituirlo o prescindir de ella.
- Encargar el desarrollo de una versión compatible, si el plugin es imprescindible y no existe alternativa, una opción más costosa, pero a veces la única viable para funciones muy específicas de tu operación.
Cómo desactivar un plugin sin perder sus datos
Si decides desactivar un plugin temporalmente durante una actualización, no lo desinstales por completo desde el panel de administración: eso puede eliminar los datos asociados. En su lugar, la práctica recomendada por la propia documentación de Moodle es eliminar el código del plugin del servidor, no desinstalarlo desde dentro de Moodle, así los datos asociados permanecen intactos en la base de datos por si se reactiva más adelante con una versión compatible.
Errores comunes al gestionar plugins en una actualización
- No hacer inventario completo antes de empezar, descubriendo plugins olvidados a mitad del proceso de actualización.
- Confiar solo en la documentación del plugin sin probarlo activamente en staging.
- Desinstalar un plugin desde el panel en vez de solo retirar su código, perdiendo datos asociados innecesariamente.
- Actualizar todos los plugins a la vez sin revisar uno por uno si cada actualización concreta introduce cambios de comportamiento.
- Ignorar plugins que parecen “menores” (bloques decorativos, pequeños widgets), que a veces provocan errores que afectan a toda la carga de la página, no solo a su propia función.
Preguntas frecuentes
¿Cómo sé qué plugins tengo instalados? Desde Site administration > Plugins > Plugins overview, donde aparece el listado completo con su versión actual.
¿Qué pasa si un plugin no tiene página en el directorio oficial de Moodle? Es una señal de alerta en sí misma, significa que no pasa por el proceso de revisión de la comunidad, y deberías contactar directamente con quien lo desarrolló o instaló para confirmar su estado de mantenimiento.
¿Puedo actualizar Moodle si un plugin no es compatible? Depende del plugin: algunos simplemente dejan de funcionar sin bloquear el resto del sitio, otros pueden provocar errores que afectan a toda la instalación. Solo lo sabrás con certeza probándolo en staging antes.
¿Desinstalar un plugin borra los datos asociados? Sí, desinstalarlo desde el panel de administración de Moodle suele eliminar también sus datos. Si quieres conservarlos por si lo reactivas más adelante, retira solo el código del servidor en vez de desinstalarlo.
¿Cuánto tiempo antes de una actualización debería revisar mis plugins? Idealmente, en cuanto empiezas a planificar la actualización, no en los últimos días, así tienes margen para buscar alternativas o encargar desarrollo si hace falta.
¿Los plugins gratuitos son más propensos a quedar abandonados que los de pago? No necesariamente por ser gratuitos, pero sí es más común que dependan del tiempo libre de un único desarrollador voluntario, frente a plugins comerciales respaldados por una empresa con soporte contractual.
¿Qué hago si necesito una función que solo cubre un plugin sin mantenimiento? Evalúa si existe una alternativa mantenida que cubra la misma necesidad, aunque no sea idéntica en funcionalidad, antes de decidir mantener un plugin sin soporte de seguridad activo.
Conclusión
Los plugins, no el núcleo, son la parte de Moodle que más falla al actualizar, y también la más fácil de auditar con antelación si se hace de forma sistemática: inventario completo, revisión uno a uno en el directorio oficial, y prueba real en staging antes de dar nada por compatible.
Si prefieres no tener que revisar tú mismo cada plugin antes de cada actualización, en Avantys lo hacemos como parte del proceso de migración que gestionamos para centros de formación. Puedes pedir una auditoría gratuita de tu instalación actual en Moodle Gestionado.
Artículos relacionados
- Mantenimiento y hosting Moodle: guía completa
- Cómo actualizar Moodle 3.x a 4.5 LTS paso a paso
- Cómo crear un entorno de pruebas (staging) de Moodle
- Actualizar PHP en Moodle sin romper plugins
- Checklist de actualización de Moodle sin downtime
¿Y si tu Moodle lo lleváramos nosotros?
Actualizaciones, backups verificados, rendimiento y trazabilidad FUNDAE, gestionado de forma continua por una persona que responde. Auditoría gratuita de tu plataforma actual.
