Actualizar Moodle 4.5 a 5.3 LTS.

Moodle 5.3 LTS se publicó el 5 de octubre de 2026. El calendario oficial diferencia soporte general y correcciones de seguridad:

Por tanto, seguir temporalmente en 4.5 no equivale a usar una rama sin correcciones de seguridad. Hay margen para preparar el salto, manteniendo los parches de la rama actual. Tampoco conviene dar por hecho que esperar unos días resolverá un plugin sin mantenimiento.

El calendario sitúa 5.3.1 el 7 de diciembre de 2026; es una fecha prevista, no una versión ya disponible. La decisión de publicar debe atender a compatibilidad, incidencias relevantes, ensayos y calendario académico. Un campus puede preparar ahora la infraestructura y el ensayo y fijar después su versión exacta de producción.

Las notas oficiales de 5.3 permiten actualizar desde 4.4 o posterior. El origen 4.5 entra en esa ruta; el núcleo no exige pasar sucesivamente por 5.0, 5.1 y 5.2. Para versiones anteriores hay que planificar pasos intermedios verificando los requisitos de cada destino.

Se utiliza el motor que corresponda a la instalación. No hay que disponer de todos. Oracle dejó de estar soportado desde Moodle 5.0.

PostgreSQL 16 y MariaDB 10.11 corresponden a requisitos anteriores: no deben copiarse como mínimos de 5.3. Tampoco «PHP 8.3 o superior» permite dar por soportada cualquier versión futura. Comprobar una familia admitida y su parche concreto evita esa ambigüedad.

El informe de Administración del sitio → Servidor → Entorno ayuda a identificar requisitos. Hay que contrastar también el PHP de la web y el de consola: pueden utilizar distintos ejecutables, extensiones y configuraciones. Memoria, almacenamiento, cachés y capacidad se dimensionan con el campus; cumplir mínimos no demuestra rendimiento bajo su carga.

La preparación debe recorrer las notas intermedias. Esta selección organiza los cambios con efecto en el ensayo; no sustituye sus listas completas.

Moodle 5.0: evaluación, temas y componentes retirados

Las notas de 5.0 incorporan bancos de preguntas compartidos y cambios en los intentos de cuestionario. Conviene probar permisos para usar preguntas, categorías, tipos de pregunta de terceros, intentos anteriores y nuevos, calificación y restauración de cursos.

La guía de actualización de 5.0 recoge Bootstrap 5 y la salida del núcleo de Chat, Survey, Atto, autenticación CAS y componentes MNet. Si se usan, hace falta decidir cómo conservar su función y sus datos. Que un componente salga del núcleo no significa que deba borrarse sin revisar su alternativa mantenida. Los temas propios necesitan comprobar sus plantillas, estilos e interacciones. También cambia la configuración de proveedores de IA y se retira MimeTeX: se ensaya el editor, la integración de IA y la representación de fórmulas cuando formen parte del campus.

Moodle 5.1: nueva raíz pública y ubicación de plugins

Desde 5.1, el servidor web debe apuntar a la carpeta public, no a la raíz completa de instalación. Los plugins que estaban en mod, local o theme pasan a sus ubicaciones bajo public. config.php permanece fuera de esa carpeta. El cambio alcanza las rutas usadas por despliegues, cron y otras tareas. Aviso oficial de 5.1.

Moodle 5.2: entorno y recorridos que siguen evolucionando

5.2 eleva PHP a 8.3 y modifica elementos del acceso, la evaluación y la gestión de preguntas. Aunque una actualización desde 4.5 no se detenga en esta rama, se prueban autenticación, roles y evaluación con el conjunto final. La incorporación de telemetría es una capacidad opcional: no hace falta implantarla para completar la actualización. Notas de 5.2.

Moodle 5.3: tema, navegación y contenido que requiere una decisión

5.3 actualiza la interfaz y la navegación e introduce mejoras de evaluación e IA. Para una instalación existente interesan especialmente estas comprobaciones:

• Classic sale del núcleo. Si hay que conservar el tema y sus ajustes, su versión mantenida debe prepararse antes del upgrade. Instalarlo después no recupera automáticamente sus selecciones anteriores. Revisar también cualquier tema forzado en config.php. Notas del tema en v5.3.0.
• El bloque Activities se retira. Identificar los cursos y páginas que dependían de ese acceso y comprobar cómo se llega a sus actividades.
• Las descripciones de subsecciones quedan ocultas hasta decidir su tratamiento. La administración permite migrarlas a actividades de texto y medios o eliminarlas; hay que revisar contenido antes de elegir.

Las retiradas y la migración de subsecciones están documentadas en la guía de actualización de 5.3. Deben formar parte de las pruebas y de la comunicación al profesorado cuando afecten a su trabajo.

El inventario incluye actividades, bloques, tipos de pregunta, formatos de curso, tema, autenticación, matriculación, informes, integraciones y extensiones locales. Para cada componente, se conserva versión instalada, versión propuesta, dependencias, fuente del mantenedor y resultado del ensayo.

La compatibilidad declarada permite preparar una combinación; su funcionamiento local necesita pruebas. Un plugin propio requiere revisar sus migraciones de datos, APIs, consultas, permisos, tareas, servicios e interfaz. Las notas de actualización para desarrolladores ayudan a localizar cambios y retiradas. Cambiar únicamente el número de versión requerido no adapta un plugin.

También se comparan las modificaciones del núcleo con la versión original correspondiente. Un parche no registrado puede desaparecer al sustituir el código. Debe decidirse si sigue siendo necesario, si se puede convertir en extensión o si requiere adaptación.

La decisión puede ser actualizar, adaptar, sustituir, conservar una versión comprobada o aplazar. Desinstalar un complemento puede eliminar datos asociados; no es una limpieza automática para superar el upgrade.

La copia debe partir de la versión de origen y conservar las características relevantes: plugins, datos representativos, archivos y configuración. Una instalación nueva y vacía de 5.3 no prueba las migraciones de un Moodle 4.5 existente.

Antes de iniciar tareas en la copia, se aíslan sus efectos externos: correo, pagos, matrícula, notificaciones, servicios de identidad y automatizaciones. También se separan las cachés y los espacios de sesión que puedan confundirse con producción. Los accesos y el tratamiento de los datos se acuerdan según el contenido del campus.

El ensayo reproduce el cambio de servidor y aplicación previsto, mide la duración y registra errores y diferencias. Si se va a actualizar la base de datos, esa operación merece un ensayo y un procedimiento de retorno propios. Las otras aplicaciones del servidor pueden depender de ese mismo motor o de PHP.

La checklist descargable se puede completar con responsables y evidencias. Marcar una casilla significa haber comprobado el punto, no haber leído este artículo.

Antes de fijar la ventana

1. Registrar versión y parche de origen, método de instalación y versión exacta de destino.
2. Verificar ruta admitida, PHP de web y consola, motor de datos y requisitos del entorno.
3. Completar el inventario de plugins, tema, integraciones y parches del núcleo; resolver las incompatibilidades críticas.
4. Revisar las notas 5.0–5.3 y localizar contenidos o componentes afectados por retiradas.
5. Preparar una copia aislada de la instalación de origen y ejecutar en ella la actualización prevista.
6. Ensayar restauración, medir tiempos y acordar quién decide publicar o volver atrás.
7. Seleccionar recorridos con docentes y operación; conservar el resultado del ensayo y los pendientes.

Durante la intervención

1. Comunicar el cambio, activar mantenimiento y detener entradas externas, cron y trabajadores según el plan. Esperar a que terminen los procesos en curso.
2. Obtener la copia final coherente y comprobar que se puede utilizar para recuperar el entorno.
3. Desplegar el código preparado, plugins, configuración web y dependencias; ejecutar el upgrade con la versión PHP acordada.
4. Resolver los pendientes previstos de tareas y contenido, purgar cachés y realizar las comprobaciones de aceptación antes de reabrir.

Al reabrir y después

1. Reactivar coordinadamente procesos e integraciones y verificar su ejecución; recuperar el acceso de usuarios cuando se acepte el resultado.
2. Observar errores, tiempos, tareas atrasadas e incidencias académicas frente a la referencia anterior.
3. Conservar evidencias, copia y procedimiento de retorno durante el periodo acordado; documentar las diferencias que quedan pendientes.

Si un punto crítico no tiene evidencia, la publicación queda pendiente. El orden exacto de mantenimiento y despliegue debe ajustarse a la arquitectura ensayada.

El despliegue se prepara con un árbol limpio de la versión elegida y las extensiones inventariadas. Superponer todos los archivos nuevos sobre los anteriores puede dejar código obsoleto. Se conserva el árbol previo como parte de la recuperación y se trasladan solo configuración y extensiones identificadas, en sus versiones acordadas.

En una instalación convencional cuyo código está en /srv/moodle, la estructura de destino es:

/srv/moodle/
  config.php
  public/
    admin/cli/
    mod/
    local/
    theme/
    r.php
/srv/moodledata/

La raíz web apunta a /srv/moodle/public. moodledata queda fuera del acceso público. Si la URL del campus se mantiene, no se añade /public a wwwroot solo porque haya cambiado la carpeta física. El servidor debe atender también el enrutamiento de r.php; la configuración concreta depende de Apache, Nginx, IIS o el alojamiento. Reestructura oficial.

Composer requiere distinguir el método de instalación. La guía oficial de 5.3 indica que, si la instalación utiliza Composer o conserva un directorio vendor de una ejecución anterior, hay que actualizar sus dependencias después de cambiar el código y antes del upgrade:

# Solo para el caso descrito, desde la raíz de instalación preparada.
composer install --no-dev --classmap-authoritative

Si no se utiliza Composer y no existe ese vendor, la misma guía no exige ejecutar el comando. No se copia un vendor antiguo a ciegas ni se utiliza composer update para sustituir el conjunto fijado por la versión elegida. Condición documentada.

Estos ejemplos presuponen Linux, instalación convencional, usuario de servicio www-data, ejecutable PHP seleccionado y código en /srv/moodle. Deben adaptarse al ensayo. No crean las copias, no configuran el servidor y no constituyen un despliegue automático.

Sobre el código 4.5 de origen, la activación del mantenimiento utiliza la ruta anterior:

sudo -u www-data /usr/bin/php /srv/moodle/admin/cli/maintenance.php --enable

Después de preparar el código 5.3 de destino, las rutas quedan bajo public:

# Consultar opciones en el código de destino antes de la ejecución acordada.
sudo -u www-data /usr/bin/php /srv/moodle/public/admin/cli/upgrade.php --help

# Ejecutar las migraciones; conservar y revisar la salida completa.
sudo -u www-data /usr/bin/php /srv/moodle/public/admin/cli/upgrade.php --non-interactive

# Después del upgrade correcto, antes de aceptar el campus.
sudo -u www-data /usr/bin/php /srv/moodle/public/admin/cli/purge_caches.php

El código publicado confirma la ubicación de upgrade.php en v5.3.0. La administración por consola explica su uso. Se utiliza el usuario y ejecutable del entorno; ejecutar php desde la consola no prueba que sea la misma versión configurada en la web.

Tras aceptar las pruebas y coordinar la reactivación:

sudo -u www-data /usr/bin/php /srv/moodle/public/admin/cli/maintenance.php --disable

El cron debe apuntar a la ruta nueva, por ejemplo /srv/moodle/public/admin/cli/cron.php, con el PHP acordado. Conviene revisar su ejecución y las tareas ad hoc pendientes; iniciar el proceso no garantiza que todo el trabajo haya terminado. Documentación de cron.

El ensayo reúne resultados esperados y observados. La matriz descargable propone escenarios que deben seleccionarse y concretarse con cada campus:

Cada prueba necesita un usuario con el rol correspondiente, datos de referencia y un resultado que permita detectar el fallo. Si el campus concentra actividad en exámenes, se añade una prueba de carga representativa. Una copia reducida no acredita capacidad para una convocatoria completa.

Moodle no ofrece un downgrade general que revierta las migraciones. La recuperación debe conservar código, base de datos y moodledata del mismo estado, además de las configuraciones necesarias. Una copia de cursos no reemplaza esa copia del sitio. Copias y restauración.

El plan fija quién decide, qué incidencias activan el retorno y hasta qué momento es viable. Si ya hay entregas o matrículas posteriores a la copia, hay que resolver qué ocurrirá con ellas. Restaurar Moodle tampoco deshace un correo, una operación de pago o una matrícula enviada a otro sistema.

Se ensaya la restauración y se comparan el tiempo medido y la pérdida observada con los límites acordados. La versión previa de la base de datos y del servidor debe seguir siendo recuperable: restaurar sus datos sobre un motor distinto puede exigir otro procedimiento. Sin esa comprobación, disponer de un archivo de copia no acredita que el campus pueda volver a su estado anterior.

Un mensaje durante el upgrade debe interpretarse con su contexto. La documentación identifica, por ejemplo, un aviso conocido sobre preguntas sin contexto; eso no permite ignorar cualquier error del banco de preguntas. Ante un fallo no explicado se conserva la salida y se decide si corregir dentro de la ventana o aplicar el procedimiento de recuperación. No se improvisa borrando tablas o desinstalando componentes con datos académicos.

Están disponibles la checklist, el inventario de plugins y la matriz de pruebas. Sus resultados están sin completar; sirven para registrar una comprobación propia.

Si la ejecución se encarga a un proveedor, el alcance debe identificar quién prepara infraestructura, adapta extensiones, valida recorridos y decide publicar o recuperar. La oferta de actualización de Moodle de MDL Soluciones permite plantear esa intervención. La guía sigue siendo utilizable por el equipo que administra el campus, con independencia de quién ejecute el proyecto.

El siguiente paso práctico es completar el inventario y seleccionar los recorridos con el equipo académico. Esas dos piezas permiten organizar el ensayo y convertir una fecha deseada en una decisión de publicación respaldada por pruebas.