Caso de éxito: actualizar un Moodle antiguo y pasarlo a HTTPS para una entidad de oposiciones en Murcia

Este caso explica cómo se plantea actualizar Moodle y pasarlo a HTTPS en una plataforma antigua. Una entidad de formación dedicada a la preparación de oposiciones tenía su plataforma Moodle funcionando sobre una versión de PHP muy antigua y sin certificado HTTPS en el dominio de la plataforma. Nos pidió actualizar el Moodle que usaba a diario y dejarlo preparado para funcionar con conexión segura. Trabajamos a partir de una copia de seguridad completa, en un entorno aparte y sin tocar el servidor en uso. Este es el planteamiento, el método y lo que conviene saber antes de actualizar una plataforma que lleva años sin moverse.

Proyecto para un cliente de la provincia de Murcia. Caso anonimizado: por confidencialidad, la ubicación y los datos que podrían identificar al cliente se han modificado.

La situación de partida

El proveedor de hosting del cliente describió el estado del servidor en un correo de abril de 2023. La suscripción contenía tres sitios:

• La web corporativa, en WordPress.
• El Moodle que se usaba para dar clase.
• Otro Moodle creado, pero probablemente sin uso.

El correo recogía además dos problemas técnicos:

• Versiones de PHP muy antiguas. La web funcionaba con PHP 7.4, porque al intentar actualizarla habían aparecido problemas con un tema modificado. Los dos Moodle funcionaban con PHP 5.6.
• Sin HTTPS en el dominio del Moodle. La plataforma donde los alumnos entran con su usuario y su contraseña no tenía certificado.

Ninguno de los dos problemas es un detalle. Una versión antigua de PHP deja de recibir correcciones de seguridad, y las versiones modernas de Moodle exigen versiones de PHP más recientes. Y una plataforma con acceso de alumnos sin HTTPS expone las credenciales en el trayecto y los navegadores la señalan como no segura, algo que resta confianza a una entidad cuyo negocio es que las personas estudien en ella.

Lo que se pidió

La petición era clara: actualizar el Moodle en uso y pasarlo a HTTPS. El cliente tenía una limitación importante, que es la de cualquier academia con alumnos activos: la plataforma no podía quedarse inutilizable durante semanas ni arriesgarse a perder datos de alumnos, cursos o resultados.

Eso condicionó el método. Antes de hablar de versiones, había que decidir dónde se iba a probar todo.

Cómo trabajamos

1. Recibir una copia completa

El cliente generó una copia de seguridad completa de la suscripción desde el panel de su hosting. Era voluminosa, porque incluía los tres sitios, y se nos entregó mediante un enlace de descarga. Junto a ella, el cliente nos indicó cómo restaurarla: sin contraseña y con la comprobación de firmas desactivada al restaurar.

Partir de una copia completa tiene una ventaja decisiva: se trabaja con los datos y la configuración reales, no con una instalación de laboratorio. Los problemas de verdad, como un plugin antiguo, un tema modificado o una configuración heredada, aparecen aquí y no en producción.

2. Restaurar en un entorno aparte

La copia se restauró fuera del servidor del cliente. Ahí se hizo la actualización del Moodle en uso. Mientras tanto, el servidor del cliente seguía funcionando con normalidad. El entorno de pruebas es lo que permite equivocarse sin consecuencias, repetir un paso las veces que haga falta y comparar el resultado con el original.

3. Actualizar y preparar el paso a HTTPS

En el entorno de pruebas se actualizó el Moodle y se preparó su funcionamiento con conexión segura. Se comprobó que la plataforma arrancaba, que los cursos y los usuarios seguían ahí y que el acceso funcionaba.

4. Entregar la copia del Moodle actualizado

El 10 de mayo de 2023 entregamos al cliente la copia de seguridad del Moodle ya actualizado, con un enlace para descargarla. En la carpeta del proyecto constan las copias de los días 8 y 9 de mayo como pasos intermedios. De ese modo, el cliente o su proveedor de hosting disponían de una versión lista para desplegar en su servidor, con todo lo que se había hecho en el entorno de pruebas.

Qué se persigue con este tipo de proyecto

Los beneficios que perseguía el encargo, no resultados medidos, son estos:

• Un Moodle actualizado a una versión que pueda seguir recibiendo correcciones.
• Acceso de los alumnos mediante HTTPS.
• Un camino de actualización probado antes de tocar el servidor en uso.
• Una copia de seguridad del resultado, que sirve a la vez de punto de partida y de red de seguridad.

Qué hay que mirar al actualizar un Moodle antiguo

Lo que sigue es contenido general, útil para quien se plantee algo parecido. No describe lo que ocurrió en este proyecto concreto, sino los puntos que revisamos habitualmente.

La versión de partida y la de destino. Moodle no siempre permite saltar directamente de una versión muy antigua a la última. Cada versión exige un mínimo de la anterior, y a veces hay que pasar por versiones intermedias. Por eso lo primero es saber qué versión hay instalada y cuál se quiere alcanzar.

La versión de PHP y la base de datos. Cada versión de Moodle admite un rango de versiones de PHP y de motores de base de datos. Actualizar Moodle suele implicar actualizar PHP, y actualizar PHP puede romper otros sitios que comparten el mismo servidor, como una web en WordPress con un tema modificado. Conviene valorar si cada sitio debe vivir en su propio entorno.

Los plugins. Cada plugin de terceros debe tener una versión compatible con la nueva versión de Moodle. Si no la hay, se sustituye, se adapta o se prescinde de él. Es el punto que más sorpresas da.

El tema. Un tema personalizado puede dejar de funcionar al cambiar de versión. Se comprueba antes y, si hace falta, se adapta o se recurre a un tema compatible.

Los datos del alumno. Calificaciones, finalizaciones, intentos de cuestionario y mensajes deben conservarse. Se verifica comparando cifras entre el sitio original y el actualizado.

El tiempo de parada. Al desplegar, el sitio estará un tiempo en modo mantenimiento. Conviene elegir un momento de poca actividad, por ejemplo fuera de los días de simulacro o de examen, y avisar a los alumnos.

Qué implica pasar un Moodle a HTTPS

El certificado es solo una parte. Para que la plataforma funcione correctamente con conexión segura suelen revisarse estos puntos:

1. El certificado en el dominio. Debe instalarse y renovarse en el servidor donde esté el Moodle, y comprobarse que cubre el dominio exacto que usan los alumnos.
2. La dirección del sitio. La configuración de Moodle guarda la dirección base de la plataforma. Hay que cambiarla a la versión segura.
3. Los contenidos con direcciones antiguas. Los textos de los cursos, las imágenes y los enlaces incrustados pueden contener direcciones sin HTTPS. Si no se corrigen, el navegador muestra avisos de contenido mixto. Moodle incluye una herramienta de administración para buscar y reemplazar texto en la base de datos, que debe usarse con una copia previa.
4. La redirección. Quien acceda a la dirección antigua debe acabar en la segura, sin romper los enlaces ya compartidos.
5. Servicios conectados. Si la plataforma está integrada con otros sistemas, por ejemplo la web corporativa o una videoconferencia, cada conexión debe seguir funcionando con la nueva dirección.

Cuándo compensa actualizar y cuándo conviene otra vía

Actualizar tiene sentido cuando la plataforma funciona, los cursos están bien montados y el problema es técnico: versión, seguridad, certificado. En cambio, si el diseño pedagógico está obsoleto, si hay muchos plugins abandonados o si la plataforma necesita una reorganización completa, a veces es más sensato montar una instalación nueva y migrar los cursos. Se decide con datos, después de revisar la copia.

Algo que aprendimos en este tipo de proyectos: el entorno de pruebas es parte del servicio, no un extra. Quien actualiza directamente en producción ahorra un día y arriesga el curso entero.

¿Tiene un Moodle que lleva años sin actualizarse?

Podemos revisar su plataforma, probar la actualización en un entorno aparte y entregarle un resultado listo para desplegar, con el código y los servidores a nombre de su entidad. Consulte nuestras páginas sobre programación en Moodle y copias de seguridad, o cuéntenos su caso.

Actualizar Moodle: lo esencial del caso

Actualizar Moodle empieza por una copia completa de archivos y de base de datos. Al actualizar Moodle en un entorno de pruebas se detectan los plugins y el tema que no son compatibles. Actualizar Moodle y pasarlo a HTTPS protege las credenciales de los alumnos y evita avisos del navegador. Una vez probado, actualizar Moodle en producción es un paso corto y reversible.

Para ampliar información, puede consultar la información de Let’s Encrypt sobre certificados.

Preguntas frecuentes

¿Se pierden los datos de los alumnos al actualizar?

No debería. Por eso se trabaja sobre una copia completa y se comprueban los datos antes de desplegar. Aun así, conviene una copia reciente justo antes de cada despliegue.

¿Hay que parar la plataforma?

Durante el despliegue final, sí, durante un tiempo que depende del tamaño de los datos. Se elige un momento de poca actividad y se avisa a los alumnos.

¿Se puede actualizar un Moodle sin salir de la versión de PHP actual?

Solo dentro de lo que admita la versión de PHP instalada. Las versiones modernas de Moodle piden versiones de PHP recientes, por lo que lo habitual es actualizar ambas cosas.

¿Quién despliega el resultado en el servidor del cliente?

Se acuerda en cada proyecto: puede hacerlo el cliente, su proveedor de hosting o nuestro equipo con los accesos que se faciliten. El hosting es del cliente.

¿Pueden hacerlo si ya trabajamos con otra agencia o con otro proveedor?

Sí. Trabajamos directamente con empresas y también como subcontrata de consultoras e integradores, en marca blanca.