Los plugins son la razón por la que Moodle se adapta a instituciones muy distintas, y también la causa más frecuente de campus que no se pueden actualizar. Este artículo resume cómo evaluamos, instalamos y mantenemos plugins en instituciones peruanas, desde nuestra experiencia como Moodle Certified Partner del Perú.
Qué aporta y qué arriesga un plugin
Un plugin añade funcionalidad a Moodle sin tocar el núcleo: un tipo de actividad, un método de matrícula, un informe, una integración o un tema visual. El aporte es inmediato; el riesgo es diferido. Cada plugin instalado es código de terceros que tendrá que ser compatible con cada versión futura de Moodle, y con la de PHP y la base de datos que use tu servidor.
Esa asimetría explica el patrón que vemos en campus con varios años de vida: se instalaron plugins para necesidades puntuales, quien los pidió ya no está, nadie sabe cuáles siguen en uso y el equipo de TI evita actualizar por miedo a romper algo. Ordenar eso es parte del soporte gestionado de Moodle.
Seis criterios antes de instalar
Antes de instalar cualquier plugin conviene responder seis preguntas. Si tres o más quedan sin respuesta clara, la instalación se posterga. No es burocracia: es lo que evita que la próxima actualización se convierta en un proyecto.
- Necesidad real. ¿Qué proceso pedagógico o administrativo resuelve y quién lo pidió por escrito?
- Alternativa nativa. ¿Moodle ya lo hace con configuración, permisos o una actividad existente?
- Mantenimiento. ¿Cuándo fue su última versión y para qué releases de Moodle declara soporte?
- Adopción. ¿Cuántos sitios lo reportan instalado y qué dicen los reportes abiertos?
- Impacto en rendimiento. ¿Añade consultas pesadas en páginas de alto tráfico como el tablero o el curso?
- Salida. Si mañana el autor lo abandona, ¿qué pasa con los datos que guarda?
Cómo leer el catálogo oficial
El catálogo oficial de plugins de Moodle publica la información que necesitas para decidir: versiones de Moodle soportadas, fecha de la última release, cantidad de sitios que lo tienen instalado, licencia y enlace al repositorio. Un plugin sin actualizaciones en varias versiones mayores es una deuda técnica, por útil que parezca hoy.
Mira también el rastreador de incidencias. Un plugin con reportes recientes respondidos por el autor es más confiable que uno sin actividad: significa que alguien lo sostiene. Y verifica la licencia, porque en instituciones públicas la compatibilidad con GPL suele ser parte del expediente de contratación.
Mantenimiento y actualizaciones
El costo de un plugin no está en instalarlo, está en sostenerlo. Cada actualización de Moodle exige revisar la matriz de compatibilidad de todos los plugins instalados, probar en un entorno espejo y decidir qué se actualiza, qué se reemplaza y qué se retira. Ese trabajo es predecible si se hace por calendario y caótico si se hace por emergencia.
La secuencia que aplicamos es la misma que describimos en la guía de cómo actualizar Moodle sin tumbar el semestre: inventario de plugins, verificación de compatibilidad, clonado del sitio, actualización en pruebas, validación funcional y recién entonces la ventana de producción con respaldo probado.
Los plugins de seguridad y autenticación merecen un carril propio: sus parches no esperan al calendario de la institución.
Cuándo conviene no instalar nada
Muchos requerimientos que llegan como pedido de plugin se resuelven sin instalar código. Antes de sumar dependencias vale revisar tres caminos: configuración y permisos nativos, integración por LTI con la herramienta externa, o consumo de datos por servicios web hacia un sistema que ya tenga la institución.
El caso típico es querer un informe que ya existe en el constructor de informes del núcleo, o integrar una herramienta editorial que ofrece conector LTI estándar. En ambos escenarios, no instalar es la mejor decisión de arquitectura.
Gobierno de plugins en la institución
Un campus sano tiene una política corta y escrita: quién puede solicitar un plugin, quién lo aprueba, dónde se prueba, quién es el responsable funcional y cuándo se revisa si sigue en uso. Con eso basta para evitar el 80% de los problemas.
Ese gobierno se apoya en dos elementos operativos: un entorno de pruebas que sea copia real de producción y un acuerdo de servicio que defina quién responde cuando un plugin falla. Si estás definiendo ese acuerdo con un proveedor, nuestra checklist de SLA de soporte lista qué pedir por escrito.
Sobre presupuesto, no hay una cifra por plugin: el costo real está en las horas de prueba y mantenimiento asociadas al soporte. Los rangos referenciales de proyecto y de operación anual están en cuánto cuesta implementar Moodle y en precio de hosting y soporte.
Cómo levantar el inventario de plugins
Antes de decidir qué se queda y qué se retira hace falta una foto clara. El inventario parte del listado de plugins adicionales del área de administración del sitio y se completa con tres datos que Moodle no entrega solo: quién pidió el plugin, para qué curso o proceso se usa hoy y qué pasa si se desinstala.
Una tabla simple basta: nombre del plugin, versión instalada, versión más reciente publicada por el autor, fecha de la última actualización, responsable funcional y estado (activo, en observación, candidato a retiro). Cruzar esa tabla con los registros de uso del propio Moodle suele mostrar que hay plugins instalados hace años que ningún curso invoca.
El inventario no es un ejercicio anual. Conviene revisarlo dos veces al año y, obligatoriamente, antes de planificar una actualización mayor. Si tu equipo no tiene cómo sostener esa revisión, es parte del trabajo que cubre un servicio de soporte Moodle continuo.
Probar en un entorno espejo, no en producción
La regla es corta: ningún plugin entra a producción sin haber corrido antes en una copia del campus. Un entorno espejo replica versión de Moodle, plugins, tema y una muestra de datos, y permite responder preguntas que la documentación del plugin nunca contesta: si rompe el tema, si altera los reportes de finalización, si convive con la app móvil o si añade consultas pesadas a la base de datos.
El guion de prueba mínimo incluye cuatro recorridos: un estudiante que entra al curso y completa una actividad, un docente que califica, un administrador que genera un reporte y un usuario que abre el curso desde el celular. Si alguno falla, el plugin no está listo.
La prueba también mide el tiempo de despliegue. Saber cuánto demora la instalación, la actualización de la base de datos y la purga de cachés permite dimensionar la ventana de mantenimiento y comunicarla con anticipación a las áreas usuarias. Ese trabajo de plataforma es parte del alcance de una implementación de Moodle gestionada.
El costo real de un plugin
Un plugin gratuito no es un plugin sin costo. El gasto aparece después: horas de prueba en cada actualización, ajustes cuando el autor cambia el comportamiento, capacitación a docentes y personal de soporte, y el riesgo de quedar atados a una versión antigua de Moodle si el plugin deja de mantenerse.
Antes de aprobar la instalación conviene estimar tres partidas: el esfuerzo de puesta en marcha, el esfuerzo recurrente por actualización y el costo de salida, es decir, qué haría falta para retirar el plugin y migrar lo que dependa de él. Cuando el costo de salida es alto y el proveedor del plugin es una sola persona, la decisión merece una segunda vuelta.
En muchos casos la alternativa más barata ya está en Moodle: una configuración nativa, una actividad estándar bien usada o una integración por LTI. Empezar por ahí evita deuda técnica que se paga durante años.
Preguntas frecuentes
¿Cuántos plugins es razonable tener en un Moodle institucional?
No hay un número correcto, sino un criterio: cada plugin debe tener un responsable funcional y una razón de uso vigente. En campus peruanos que revisamos, buena parte de los plugins instalados no se usa y solo añade riesgo en cada actualización.
¿Un plugin puede impedir que actualice Moodle?
Sí. Si el plugin no tiene versión compatible con la nueva release, la actualización se bloquea o deja funcionalidad rota. Por eso la matriz de compatibilidad de plugins se revisa antes de planificar el upgrade, no durante.
¿Los plugins del catálogo oficial son seguros?
El catálogo de Moodle aplica revisión antes de aceptar un plugin, pero la seguridad y el mantenimiento dependen del autor. Hay que mirar fecha de última actualización, versiones soportadas, número de sitios que lo usan y estado de los reportes abiertos.
¿Conviene desarrollar un plugin propio?
Solo cuando el requerimiento es específico de la institución y no existe equivalente mantenido. Un plugin propio implica asumir su compatibilidad en cada actualización futura, así que conviene evaluar primero configuración nativa, LTI o integración por servicios web.
¿Quién debe instalar plugins en producción?
Nadie directamente en producción. La ruta correcta es probar en un entorno espejo, validar con usuarios funcionales y recién entonces desplegar en una ventana de mantenimiento con respaldo previo y plan de retorno.
¿Cada cuánto conviene revisar el inventario de plugins?
Dos veces al año como rutina y siempre antes de planificar una actualización mayor de Moodle. Esa revisión es la que evita descubrir incompatibilidades cuando la ventana de mantenimiento ya está abierta.
¿Qué es un entorno espejo y hace falta mantenerlo siempre activo?
Es una copia del campus con la misma versión, plugins y tema, usada solo para pruebas. No necesita estar encendido todo el año: puede levantarse para cada ciclo de pruebas y actualizaciones, lo que reduce su costo.
¿Un plugin gratuito tiene costo para la institución?
Sí, aunque no se pague licencia. El costo está en las horas de prueba de cada actualización, la capacitación y el riesgo de quedar atados a una versión antigua si el autor abandona el proyecto.