Cada versión de Moodle exige un rango concreto de PHP, y ese rango cambia con cada release. El problema no suele ser actualizar PHP en sí (eso lo hace en minutos cualquier panel de hosting), sino descubrir después que un plugin de terceros deja de funcionar porque usaba una función que la nueva versión de PHP ya no soporta, o al revés: un plugin que necesita una extensión que el servidor nuevo no tiene activada.
En esta guía vas a ver cómo comprobar la compatibilidad antes de tocar nada, qué extensiones exige Moodle, y el proceso para actualizar PHP sin dejar plugins a medias.
Por qué PHP y Moodle van de la mano
Moodle define, para cada versión, un PHP mínimo y un PHP máximo soportado, no puedes simplemente “usar la última versión de PHP” sin comprobarlo antes. Por ejemplo, Moodle 4.5 LTS requiere como mínimo PHP 8.1.0, con soporte también para 8.3.x, mientras que su predecesora 4.1 LTS fue la última en admitir PHP 7.4. Ese rango exacto está siempre documentado en las notas de release de cada versión en Moodle Developer Resources.
Desde Moodle 4.2, además, solo se admiten versiones de PHP de 64 bits: un servidor con PHP de 32 bits, aunque técnicamente esté dentro del rango de versión, no permite avanzar. Esto casi nunca es un problema en hosting moderno, pero sí lo es en servidores heredados que se arrastran desde hace años: si vienes de un Moodle muy antiguo, comprueba la arquitectura antes de planear nada. Un php -i | grep "Architecture" en la línea de comandos te lo confirma en un segundo.
El informe de entorno: tu primera parada
Antes de cambiar una sola línea de configuración, Moodle ya te dice qué le falta. En Administración del sitio > Servidor > Comprobaciones del entorno (Environment) tienes una tabla que compara tu servidor actual con los requisitos de la versión de Moodle instalada: versión de PHP, extensiones activas, parámetros del php.ini y ajustes de base de datos. Cada fila sale en verde (cumple), amarillo (aviso, funciona pero conviene revisarlo) o rojo (bloqueante).
El truco que casi nadie usa: esa comprobación acepta una versión de destino. Si vas a subir Moodle además de PHP, puedes revisar el informe de entorno de la versión a la que quieres migrar antes de instalarla, para ver qué extensiones o parámetros vas a necesitar de más. Es la forma más rápida de descubrir que te falta sodium o intl sin esperar a que el sitio se caiga.
Apunta en una lista lo que salga en rojo o amarillo. Esa lista es exactamente lo que tienes que dejar resuelto en la nueva versión de PHP antes de apuntar ningún dominio hacia ella.
Extensiones que Moodle necesita sí o sí
Más allá de la versión, Moodle exige varias extensiones de PHP activas. El problema clásico al cambiar de versión de PHP es que la nueva instalación no arrastra las extensiones de la anterior: activas PHP 8.2, apuntas el dominio, y Moodle se niega a arrancar porque sodium no está compilada en ese binario. Estas son las que más problemas dan si faltan:
| Extensión | Para qué la usa Moodle | Obligatoria |
|---|---|---|
sodium | Cifrado moderno de tokens y datos sensibles | Sí (versiones recientes) |
mbstring | Manejo correcto de cadenas multibyte (tildes, caracteres especiales) | Sí |
intl | Formato de fechas, números e idiomas según la configuración regional | Sí |
curl | Comunicación con servicios externos (webservices, plugins de integración) | Sí |
gd | Procesamiento de imágenes (avatares, miniaturas, gráficos) | Sí (o imagick) |
zip | Empaquetado y desempaquetado de copias de seguridad de curso (.mbz) | Sí |
xml | Lectura y escritura de XML (backups, importaciones, servicios web) | Sí |
opcache | Caché de bytecode: rendimiento, no funcionalidad | Recomendada |
opcache es la excepción de la lista: sin ella Moodle arranca igual, pero cada petición vuelve a compilar el PHP desde cero y el sitio va notablemente más lento. En un campus con carga real, tenerla activa marca la diferencia entre una página que responde en medio segundo y una que tarda dos. Actívala siempre en el PHP nuevo aunque el informe de entorno no la marque en rojo.
También hay dos parámetros de configuración, no extensiones, que se olvidan a menudo. El primero es max_input_vars, que debe estar en 5000 o más:
; php.ini de la nueva versión de PHP
max_input_vars = 5000Formularios largos de Moodle, calificar a muchos alumnos a la vez, editar un cuestionario con decenas de preguntas, guardar permisos de un rol, envían cientos o miles de campos en una sola petición. Si max_input_vars se queda corto, PHP descarta silenciosamente los campos que sobran: el formulario parece guardarse, pero pierde datos sin dar ningún error. Es uno de esos fallos “aleatorios” que en realidad son de configuración. El segundo es post_max_size / upload_max_filesize, que conviene revisar en paralelo si subes backups grandes, pero el que rompe de forma más traicionera es max_input_vars.
El verdadero riesgo: los plugins de terceros
El núcleo de Moodle se prueba oficialmente contra cada versión de PHP soportada antes de publicarse. Los plugins de terceros no siempre reciben el mismo nivel de prueba, y es ahí donde aparecen la mayoría de roturas tras actualizar PHP:
- Funciones de PHP marcadas como obsoletas (
deprecated) en versiones antiguas y eliminadas en las nuevas, que algunos plugins todavía usan. - Comportamiento distinto en el manejo de tipos de datos entre versiones de PHP, que puede producir errores silenciosos en vez de un fallo visible inmediato.
- Plugins sin mantenimiento activo, cuyo desarrollador nunca llegó a probarlos contra la versión de PHP más reciente.
Antes de actualizar PHP en producción, revisa cada plugin instalado en el directorio oficial de plugins de Moodle para comprobar si su desarrollador confirma compatibilidad con la versión de PHP destino. En la ficha de cada plugin, la pestaña de versiones indica contra qué releases de Moodle (y por tanto qué rango de PHP) se ha probado. Si no hay información clara, o el último release es de hace años, trátalo como sospechoso y pruébalo antes que ningún otro. Tenemos una guía dedicada a este cribado en plugins de Moodle incompatibles; la regla corta es: desactiva o actualiza el plugin dudoso antes de cambiar la versión de PHP, no después de que reviente.
Por qué PHP 8.x rompe lo que 7.x toleraba
El salto de PHP 7 a PHP 8 es el que más roturas genera, y no es casualidad. PHP 8 convirtió en errores fatales muchas cosas que PHP 7 dejaba pasar con solo un aviso (warning) en el log:
- Pasar
nulla una función que espera una cadena o un número: en 7.x se convertía a""o0calladamente; en 8.x salta unTypeErrory la página muere. - Acceder a una clave de array que no existe, o a una propiedad de objeto no definida: en 7.x era un aviso, en 8.x sigue siendo aviso pero se registra mucho más ruidosamente y algunos frameworks lo elevan a error.
- Cambios en el orden de operaciones aritméticas y de concatenación, que alteran el resultado de expresiones que un plugin daba por sentadas.
Traducido a la práctica: un plugin que “funcionaba perfectamente” en PHP 7.4 durante años puede caerse el primer día bajo PHP 8.1 sin que su código haya cambiado una coma. No es que el plugin esté mal escrito según los estándares de su época; es que PHP endureció las reglas. Por eso el núcleo de Moodle no basta como prueba: Moodle se adapta a cada PHP, pero cada plugin de terceros es responsabilidad de su autor.
Proceso paso a paso
Todo lo que sigue asume que tienes un sitio de pruebas separado de producción. Si aún no lo tienes, móntalo antes: en cómo crear un entorno de staging de Moodle explicamos cómo clonar tu campus para experimentar sin miedo. Cambiar la versión de PHP directamente sobre el sitio en vivo es la causa número uno de las incidencias que nos llegan por soporte con este tema.
- Confirma el rango de PHP de tu versión de Moodle en las notas de release oficiales, no asumas que “la versión más reciente de PHP siempre es compatible”.
- Instala la nueva versión de PHP en paralelo, sin desactivar la anterior todavía. La mayoría de paneles (cPanel, Plesk) permiten tener varias versiones de PHP convivendo y asignarlas por dominio.
- Activa las extensiones necesarias en la nueva versión:
sodium,mbstring,intl,curl,gdoimagick,zip. - Ajusta
max_input_varsa 5000 o más en elphp.inicorrespondiente a la nueva versión. - Cambia la versión de PHP solo en el entorno de pruebas primero, apuntando el dominio de staging a la nueva versión.
- Revisa el log de errores de PHP tras el cambio:
tail -f /var/log/php-fpm/error.log- Prueba cada plugin de terceros activo, no solo la navegación general del sitio, entra en cada uno de sus paneles de configuración y ejecuta su funcionalidad principal.
- Solo si todo funciona en staging, repite el cambio de versión de PHP en producción, en una ventana de mantenimiento planificada.
¿Cambiar solo PHP o aprovechar y subir Moodle?
Muchas veces el cambio de PHP viene forzado porque tu versión de Moodle ya no admite el PHP que caduca en tu hosting. En ese caso tienes dos frentes: subir Moodle y subir PHP. La tentación es hacer ambas cosas de golpe para no repetir la ventana de mantenimiento, pero cada cambio grande que juntas hace más difícil saber cuál rompió qué. Si puedes, sepáralos: primero PHP con la versión de Moodle actual (si el rango lo permite), verificas, y luego el salto de Moodle. Cuando no queda otra que hacerlo todo junto, sigue el orden y las comprobaciones de la guía de migración y actualización de Moodle, que cubre el proceso completo de extremo a extremo.
Errores comunes al actualizar PHP en Moodle
- Actualizar PHP directamente en producción sin haberlo probado antes en staging.
- Olvidar activar una extensión concreta, como
sodium, que puede impedir el arranque completo de Moodle tras el cambio. - No revisar
max_input_vars, causando fallos intermitentes en formularios largos que parecen aleatorios. - Asumir que el núcleo de Moodle funcionando bien significa que todo funciona, sin probar específicamente cada plugin de terceros activo.
- Dejar activa una versión de PHP de 32 bits en servidores antiguos, que bloquea cualquier intento de actualizar más allá de Moodle 4.1.
Preguntas frecuentes
¿Puedo tener dos versiones de PHP activas a la vez en el mismo servidor? Sí, la mayoría de paneles de hosting permiten mantener varias versiones de PHP instaladas y asignar una distinta a cada dominio o subdominio, lo que facilita mucho probar en staging sin tocar producción.
¿Cómo sé si un plugin es compatible con la nueva versión de PHP? Revisando su página en el directorio oficial de plugins de Moodle, y si no hay información clara, probándolo directamente en un entorno de pruebas antes de aplicar el cambio en producción.
¿Qué pasa si actualizo PHP y un plugin deja de funcionar? Depende del plugin: algunos fallan de forma visible (error 500 o pantalla en blanco en esa sección concreta), otros fallan de forma silenciosa, mostrando datos incorrectos sin ningún error aparente, por eso conviene probar activamente cada plugin, no solo navegar por el sitio.
¿Necesito reinstalar los plugins después de actualizar PHP? No, normalmente no hace falta reinstalarlos, pero sí puede ser necesario actualizarlos a una versión más reciente si la que tienes no es compatible con el nuevo PHP.
¿Qué extensión de PHP causa más problemas si falta?
sodium es de las más críticas en versiones recientes de Moodle, sin ella, el propio núcleo puede no completar el arranque, no solo un plugin concreto.
¿PHP 8.3 es compatible con Moodle 4.5? Sí, Moodle 4.5 LTS admite tanto PHP 8.1 (mínimo) como PHP 8.3.
¿Cuánto tarda en detectarse un problema de compatibilidad tras actualizar PHP? Puede ser inmediato (un error visible al cargar el sitio) o tardar días en notarse, si el problema afecta a una función que no se usa a diario, por eso las pruebas activas en staging son más fiables que esperar a ver qué pasa en producción.
¿Dónde compruebo qué extensiones de PHP me faltan antes de actualizar? En Administración del sitio > Servidor > Comprobaciones del entorno. Esa tabla marca en rojo las extensiones o parámetros que no cumplen los requisitos de tu versión de Moodle. Revísala apuntando ya al PHP nuevo (o a la versión de Moodle destino, si también vas a subirla) para saber qué activar antes de mover producción.
¿Es obligatoria la extensión sodium en todas las versiones de Moodle?
No en las muy antiguas, pero sí en las recientes. Moodle la usa para cifrado moderno, y en las últimas versiones el núcleo no arranca sin ella. Si vienes de un servidor viejo con PHP 7.2 o 7.3, es una de las que más se olvidan al montar el PHP nuevo, porque antes no hacía falta.
¿Puedo volver a la versión de PHP anterior si algo sale mal? Sí, y es justo por eso que conviene instalar la versión nueva en paralelo sin desinstalar la vieja. Si tras el cambio en producción aparece un problema grave, revertir es tan sencillo como reasignar el dominio a la versión de PHP anterior desde el panel, cuestión de segundos, sin reinstalar nada. Ten el plan de vuelta atrás decidido antes de tocar producción, no improvisado a las tres de la tarde con el campus caído.
¿opcache afecta a la compatibilidad de los plugins?
No a la compatibilidad, pero sí al rendimiento. Es una caché de bytecode: acelera cada petición reutilizando el PHP ya compilado. Un detalle práctico: si actualizas el código de un plugin y no ves el cambio reflejado, puede que opcache esté sirviendo la versión antigua en caché, recarga PHP-FPM para vaciarla.
Conclusión
Actualizar PHP en Moodle no debería ser más arriesgado que cualquier otro cambio de infraestructura, siempre que se haga con el mismo cuidado: comprobar el rango exacto de compatibilidad, activar las extensiones necesarias, y probar cada plugin activo en un entorno de pruebas antes de tocar producción.
Si prefieres no estar pendiente de qué extensión falta o qué plugin se rompe con cada cambio de versión de PHP, en Avantys lo gestionamos como parte del mantenimiento continuo de cada Moodle. Puedes pedir una auditoría gratuita de tu configuració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
- Plugins de Moodle incompatibles: cómo detectarlos antes de actualizar
- Cómo crear un entorno de pruebas (staging) de Moodle
- Requisitos de servidor para Moodle (CPU, RAM, disco)
¿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.
