Actualizar Moodle: compatibilidad, pruebas y vuelta atrás

Que Moodle termine la actualización sin mostrar errores es una buena señal, pero todavía queda por comprobar si el campus sirve para lo que se necesita. Un cuestionario puede abrirse y fallar al calcular la nota. Un docente puede entrar en su curso y no encontrar las entregas. Una matrícula puede aparecer en Moodle mientras el sistema que la envió sigue esperando una respuesta.

La dificultad está en que cada comprobación aislada puede parecer correcta. El plugin se instala, la página carga y la cuenta de administrador tiene acceso. El problema aparece cuando un alumno o un docente intenta completar su trabajo con los permisos y las condiciones de uso habituales.

Por eso considero insuficiente dar por terminada una actualización cuando acaba el proceso técnico. Antes de reabrir el campus hay que comprobar las tareas de las que depende su actividad y saber qué se hará si falla alguna de ellas.

Qué significa que un plugin sea compatible

La compatibilidad empieza por una combinación concreta: la versión del plugin, la de Moodle y el entorno en el que se van a ejecutar. También cuentan las dependencias entre extensiones y las modificaciones que se hayan hecho al código. Una adaptación local puede comportarse de forma distinta al complemento que distribuye su mantenedor.

La declaración de compatibilidad permite elegir qué versión probar. Después hay que comprobar lo que el campus hace con ella. Un plugin de matriculación, por ejemplo, puede instalarse correctamente y fallar al interpretar un dato que recibe del sistema académico. Si solo se revisa su pantalla de configuración, esa parte queda sin probar.

Interesa averiguar cuánto depende el campus de cada extensión antes de decidir qué hacer con una incompatibilidad. Un bloque de navegación y una actividad que guarda años de entregas plantean problemas distintos. Desinstalar la actividad puede eliminar sus datos; sustituirla exige pensar cómo se conservarán y cómo se consultarán después.

Al revisar las extensiones pueden aparecer también cambios en el núcleo, informes antiguos o plugins cuyo mantenimiento se ha abandonado. Hay que decidir cuáles se mantienen, cuáles necesitan adaptarse y cuáles se reemplazan o retiran. Para retirar uno, primero hay que comprobar que nadie depende de su función y decidir cómo se conservarán los datos que aún sean necesarios.

Una prueba útil termina donde termina el trabajo

Pensemos en un examen con preguntas de un plugin. Abrir el cuestionario comprueba solo una parte. El alumno debe poder iniciar el intento, responder, entregarlo y consultar el resultado cuando corresponda. El docente necesita ver las respuestas y las calificaciones con las mismas reglas que aplicará en la convocatoria. Si la nota se envía a otro sistema, la prueba continúa hasta comprobar que llega correctamente.

Conviene acordar de antemano qué resultado se espera. Si las respuestas de la prueba tienen una nota esperada, se puede comparar con la que calcula Moodle. Limitarse a guardar el intento deja ese cálculo sin comprobar. También hay que comprobar qué puede ver cada usuario. La cuenta de administrador no sirve para verificar que un alumno solo accede a sus resultados.

El mismo razonamiento se aplica a una tarea, una rúbrica o un certificado. Lo relevante es elegir actividades que representen el uso del campus y comprobarlas completas. Quien administra el servidor puede revisar errores y tiempos; el profesorado debe reconocer en la prueba el trabajo que necesita hacer al día siguiente.

Las pruebas automatizadas de Moodle ayudan a repetir esas comprobaciones y a detectar regresiones. Para que resulten útiles, tienen que cubrir el comportamiento que importa: una prueba que solo comprueba que la página carga seguirá pasando aunque se haya calculado mal una nota.

Preparar una copia que permita encontrar los fallos

Un Moodle recién instalado ayuda a conocer la versión nueva. Para ensayar una actualización hace falta partir de la instalación que se va a actualizar, con sus extensiones, configuraciones y datos relevantes. Si la copia omite el tipo de pregunta que más se utiliza en los exámenes, no permitirá comprobarlo.

También deben mantenerse las diferencias de permisos entre usuarios. Una copia en la que todo se prueba como administrador oculta problemas de acceso. Y si se reduce el volumen de datos, hay que tener presente qué deja de representar: comprobar una tarea con diez entregas no permite estimar cuánto tardará un proceso sobre miles de ellas.

Las conexiones externas necesitan preparación aparte. El ensayo debe utilizar entornos de prueba o impedir los envíos que puedan producir matrículas, correos o cobros reales. Desconectar la integración evita esos efectos, pero deja su funcionamiento sin verificar. Si se ha desconectado, esa prueba sigue pendiente hasta que pueda hacerse de forma controlada.

Anotar qué se ha probado, con qué cuentas y qué ha ocurrido permite volver sobre un fallo sin reconstruir toda la sesión. Un resultado como «correcto» dice poco si nadie puede saber qué se hizo. Para una exportación de notas, conviene conservar los valores esperados y recibidos; para una entrega, comprobar el archivo, su autor y la fecha, además de que aparezca en la pantalla.

Volver atrás exige recuperar los datos

Después de una actualización, volver a poner el código anterior no devuelve Moodle a su estado anterior. El proceso puede haber modificado la estructura y los datos de la base de datos. La recuperación necesita un conjunto coherente de base de datos, archivos y código, con la configuración que permita ponerlo en marcha.

Hay que ensayar también la restauración de la copia. Comprobar que existe un archivo de respaldo no demuestra que se pueda restaurar, cuánto tardará ni si contiene lo necesario. La prueba termina cuando el campus recuperado permite entrar, acceder a los cursos y consultar las entregas y calificaciones que debían estar en esa copia.

El momento de reabrir el acceso cambia el problema. Si la copia se hizo el domingo a las diez de la noche y el lunes por la mañana ya hay entregas nuevas, restaurarla puede recuperar el servicio y perder esas entregas. Antes de reabrir hay que acordar cómo se conservará y recuperará el trabajo registrado después de la copia si resulta necesario restaurarla. Si no se puede conservar, esa pérdida debe tenerse en cuenta al decidir si se restaura. Tampoco se deshace automáticamente lo que Moodle haya enviado a otro sistema: una matrícula comunicada o un correo entregado seguirán existiendo fuera del campus.

Por eso los criterios para decidir si el campus puede reabrirse deben acordarse antes de la parada. Si no se puede completar una evaluación o se han alterado los permisos de acceso a las entregas, hay motivos para mantener el campus cerrado mientras se resuelve el fallo. Una diferencia menor de presentación puede corregirse después de reabrir el campus, si no impide trabajar y se sabe cómo corregirla.

La versión de destino determina qué cambios técnicos hay que hacer; el uso del campus determina qué hay que comprobar. En el análisis sobre el salto de Moodle 4.5 a 5.3 trato las decisiones específicas de esa actualización. En cualquier versión, yo daría por terminado el trabajo cuando el alumnado y el profesorado puedan hacer lo que se ha acordado comprobar y exista una recuperación practicable. Eso requiere probar la instalación que se va a reabrir, con sus datos y sus particularidades.