Moodle 5.1 a 5.2: las cinco causas reales de que la actualización se rompa
El código pasa a vivir en public/, el enrutado va por r.php y vendor/ deja de ser opcional: los cinco fallos que se repiten al subir de la 5.1 a la 5.2.
Que una actualización de Moodle se rompa suele tener poco que ver con la base de datos. Quien ha depurado varias migraciones de la 5.1 a la 5.2 asegura que casi todos los fallos que parecen misteriosos se concentran en cinco puntos, y los cinco están fuera de MySQL.
El servidor web: public/ y r.php
Desde la 5.1 el código accesible por web vive bajo public/. Si el vhost sigue apuntando al directorio padre, aparecen 404, fallos en las comprobaciones de seguridad y errores raros de todo tipo. En Apache se arregla con DocumentRoot /var/www/moodle/public; en Nginx, con root /var/www/moodle/public;. Si el alojamiento es cPanel o compartido y no permite tocar el docroot, quedan el enlace simbólico o un alias. Si no hay forma, es una limitación del hosting, no de Moodle.
La 5.1 también cambió el enrutado: las peticiones que no piden un fichero pasan por r.php. Sin eso hay 404, assets que no cargan y errores de router en el chequeo de entorno. En Apache, FallbackResource /r.php; en Nginx, try_files $uri $uri/ /r.php$is_args$args;. Un detalle que despista: si una ruta con pinta de .php devuelve 404 en lugar de 302, puede que PHP-FPM esté resolviendo esa ruta antes de que Apache llegue al fallback.
Dependencias, plugins y cachés
vendor/ tiene que existir. Se genera desde la raíz del sitio, no desde public/:
composer install --no-dev --classmap-authoritative
Sin acceso a shell, toca construir el release en otro sitio y subir el árbol completo, vendor/ incluido.
Un error como Class "Mustache_Engine" not found después de una actualización del núcleo que ha ido bien no apunta a la base de datos: la 5.2 usa las clases de Mustache con espacio de nombres, y un plugin o un tema antiguo que siga llamando al nombre viejo tumba el sitio. Tener el fichero limpio no demuestra que la extensión sea compatible; hay que revisar cada plugin no nativo contra la versión de destino.
Queda la caché. Tras una actualización limpia, muchos «esto no funciona» son restos viejos. El selector de ficheros que se niega a cargar es el ejemplo típico. Se ejecuta php admin/cli/upgrade.php y después se purgan todas las cachés desde Administración del sitio. En producción conviene la CLI: evita los problemas de proxy y de tiempo de espera que da el actualizador web en instalaciones grandes.
Antes de tocar nada, copia de las tres cosas: código, moodledata y base de datos. Solo con los ficheros no hay plan de vuelta atrás, y la prueba se hace siempre sobre una copia del sitio.
