La configuración se queda corta
Considero legítima la necesidad si ya se ha explorado lo que trae la plataforma y falta algo concreto. Compruebo qué opciones se evaluaron y con qué resultado.
Moodle · Ingeniería
Extensiones de Moodle mantenibles y preparadas para cada actualización
En muchos de los desarrollos que he revisado, el bloqueo no procedía de una mala implementación aislada, sino de depender de una parte de la plataforma que nunca había sido estable. He encontrado estas prácticas: llamar a funciones internas en lugar de usar las interfaces públicas, escribir directamente en tablas del núcleo, modificar ficheros de Moodle y resolver mediante código lo que ya resolvía la configuración. Respondo cuatro preguntas antes de escribir la primera línea: ¿puede resolverlo la configuración del núcleo?, ¿existe ya una extensión mantenida que lo haga?, ¿debe formar parte de Moodle o quedar fuera?, ¿merece la pena mantenerlo? En mi experiencia, con la última descarto muchas ideas antes de que generen trabajo de mantenimiento.
- Las interfaces públicas del núcleo reducen el riesgo de compatibilidad, pero cada actualización debe probarse contra la versión y la configuración concretas.
- Modificar ficheros del núcleo convierte cada actualización en un trabajo manual con riesgo.
- Una extensión que almacena datos ligados a cursos o actividades debe integrarlos en las API de copia y restauración que correspondan a su tipo.
- El desarrollo que se evita es mantenimiento que la organización no paga durante los próximos años.
Experiencia en ingeniería
Diseño extensiones sobre interfaces públicas, sin modificar el núcleo ni escribir directamente en sus tablas. Respeto la estructura del tipo de extensión, declaro privacidad, copia y restauración, documento el código según el estándar y compruebo su comportamiento bajo carga y en las versiones objetivo disponibles.
Mi trayectoriaCuándo aparece la petición de desarrollar
Distingo cuatro orígenes habituales. En dos de ellos, suelo concluir que lo correcto es no desarrollar nada.
Alguien vio una extensión en el directorio
Puede ser la solución o una dependencia sin mantenimiento que bloqueará la próxima actualización. Miro quién la mantiene y desde cuándo para decidir si la instalo.
Me plantean replicar un proceso interno tal cual
A veces reviso el procedimiento: reproducir dentro de Moodle uno que existía en otro sitio genera desarrollos grandes que envejecen mal.
El presupuesto disponible nos obliga a gastarlo
He visto escribir código solo porque era posible. Buena parte de ese código acaba sin uso, pero todos lo mantienen.
Cómo decido si lo construyo
Cinco preguntas que respondo antes de aprobar un desarrollo.
- 01
¿He comprobado con pruebas que la configuración no basta?
Pido el nombre de quien lo ha comprobado y el detalle de lo que ha probado. Un «no se puede» dicho de memoria explica una parte importante del código innecesario que hay en producción.
- 02
¿Quién lo va a mantener dentro de tres años?
Si nadie responde, doy el desarrollo por huérfano. Entonces decido si asumo el compromiso o busco otra vía.
- 03
¿Es lógica de aprendizaje o de negocio?
Mantengo dentro de Moodle lo relacionado con cursos, actividades y evaluación. Dejo fuera los procesos corporativos y los comunico mediante interfaces, porque así suelen envejecer mejor.
- 04
¿Cuánta gente lo va a usar y cuántas veces?
Comparo los costes fijos de actualización, pruebas y soporte de una funcionalidad de poco uso con su criticidad y su alcance antes de construirla.
- 05
¿Qué pasa en la siguiente actualización?
Si la respuesta depende de que una persona recuerde algo, descarto el diseño. Compruebo que la actualización siga el procedimiento normal.
Qué hace que una extensión sobreviva
Compruebo cinco condiciones. Cumplirlas no garantiza que la actualización sea gratis, pero me permite tratarla como una revisión en vez de como un proyecto.
- 01
Usar solo interfaces públicas
Uso en el código externo las interfaces que documenta la plataforma. Sé que todo lo demás puede cambiar sin previo aviso entre versiones, y cambia. Esa diferencia determina si adapto una extensión o la reescribo.
- 02
Respetar el tipo de extensión y su estructura
Respeto el lugar, los ficheros esperados y el ciclo de vida de cada tipo de extensión. Esa estructura permite que la plataforma instale, actualice y desinstale la extensión sin intervención manual.
- 03
Declarar la privacidad y la copia de seguridad
Compruebo si la extensión trata datos personales. Si los trata, reviso que declare su tratamiento en la Privacy API; si no, que implemente el proveedor nulo previsto por Moodle. Si almacena datos ligados a cursos o actividades, verifico su integración en las API de copia y restauración correspondientes a su tipo. También compruebo que la implementación coincida con el tratamiento y los datos reales.
- 04
Escribir y documentar el código según el estándar
Sigo la guía oficial, que fija la nomenclatura, la indentación, la documentación y las prácticas prohibidas. No la sigo por estética, sino para que otra persona entienda el código dentro de tres años sin hacer arqueología.
- 05
Pienso en el comportamiento bajo carga
Busco consultas dentro de bucles, índices ausentes y trabajo pesado dentro de la petición, porque con diez usuarios pasan inadvertidos. Aparecen el día del examen, cuando la extensión ya está en producción.
Lo que suele romperse
Seis defectos que encuentro una y otra vez revisando desarrollos de terceros.
Llamadas a funciones internas no públicas
Una extensión funciona hasta que la plataforma cambia algo por dentro. Identifico las llamadas a funciones internas no públicas como una causa frecuente de que deje de funcionar en una versión nueva.
Sin declaración de privacidad
Compruebo que las herramientas de privacidad no ven los datos personales que guarda la extensión. Por eso, una solicitud de supresión deja esos datos sin borrar.
La extensión no admite copias de seguridad ni restauraciones
Pruebo la restauración del curso para detectar si la funcionalidad aparece vacía. Sin esa comprobación, el fallo no se descubre hasta la edición siguiente, cuando ya nadie recuerda que la extensión era la responsable.
Sin comprobaciones de permisos
Compruebo de forma explícita el contexto y la capacidad en cada punto de entrada. No doy por hecho que quien llega a la página tenga permiso para acceder a ella.
Consultas dentro de bucles
En pruebas no lo veo; con volumen, hunde el rendimiento. Es el patrón que más veces he encontrado detrás de una degradación sin causa aparente.
Sin pruebas automatizadas
Sin pruebas automatizadas, compruebo todo a mano después de cada actualización. Adaptar una extensión puede costar casi tanto como reescribir partes relevantes.
Diez comprobaciones antes de aceptar una extensión
Aplico estas diez comprobaciones tanto al desarrollo propio como a lo que entrega un proveedor.
- Se ha comprobado que la configuración no resolvía el caso.
- No modifica ningún fichero del núcleo.
- No escribe directamente en tablas del núcleo.
- Usa solo interfaces públicas documentadas.
- Declara en la Privacy API los datos personales que guarda o implementa el proveedor nulo cuando no los trata.
- Cuando corresponde por su tipo y por sus datos, conserva la información necesaria en la copia y la restauración.
- Comprueba contexto y capacidad en cada punto de entrada.
- Cumple el estándar de código de la plataforma.
- Tiene pruebas automatizadas de su lógica propia.
- Hay alguien con nombre que la mantendrá en la próxima versión.
Qué cambia según el peso del desarrollo propio
Aplico un criterio más estricto a medida que crece lo construido.
- Una extensión en producción
Ajusto las pruebas al impacto de la extensión, a los datos que trata y a los privilegios con los que opera, aunque sea la única del sitio. Las interfaces públicas reducen el riesgo de compatibilidad, pero no lo eliminan.
- Varias extensiones en producción
Mantengo un inventario, aplico un criterio común de revisión y automatizo al menos las pruebas de la lógica propia. Así evito que las actualizaciones sean impredecibles.
- Desarrollo continuo con un equipo
Defino reglas por escrito, analizo automáticamente cada cambio, reviso con criterios explícitos y despliego de forma reproducible. Con desarrollo continuo y un equipo, el liderazgo técnico es imprescindible.
- Con proveedores externos
Fijo los criterios de aceptación en el contrato y los compruebo antes de aceptar la entrega. Si los reviso después de aceptar y pagar, tengo mucho menos margen para exigir las correcciones previstas en el contrato.
Qué exigir a un desarrollo entregado
En cinco filas, muestro qué separa un desarrollo mantenible de otro que solo funciona.
| Requisito | Evidencia exigible | Criterio de aceptación |
|---|---|---|
| Usar exclusivamente interfaces públicas | Revisar el código y analizar las llamadas | No usar funciones internas ni escribir directamente en las tablas del núcleo |
| Sin modificaciones del núcleo | Comprobación de integridad frente al núcleo oficial | Ninguna diferencia respecto a la versión publicada |
| Declaración de privacidad completa | Implementación de la interfaz de privacidad | La exportación incluye los datos de la extensión y el borrado los elimina |
| Compatibilidad con la copia y la restauración | Prueba de copia y restauración de un curso que use la extensión | El curso restaurado conserva los datos de la extensión |
| Estándar de código y pruebas | Ejecución del análisis estático y de las pruebas automatizadas | Sin incidencias bloqueantes y con todas las pruebas superadas |
Los tres atajos que se pagan en la siguiente versión
Los tres funcionan hoy. He visto plataformas imposibles de actualizar por culpa de estos tres atajos.
Tocar el núcleo
Modificar un fichero de Moodle resuelve el problema en minutos. Después, reconciliamos el cambio y repetimos la validación en cada actualización. Según el procedimiento de actualización, el cambio puede quedar sobrescrito o producir conflictos. Si se va la única persona que conoce la modificación, perdemos ese conocimiento.
Escribir directamente en las tablas del núcleo
Uso las interfaces para insertar o modificar registros. Si me las salto y trabajo a mano, dejo el sistema en estados que la plataforma no espera: cachés desincronizadas, eventos que no se lanzan y datos que no cuadran.
Copiar código de una extensión antigua
Heredo su forma de hacer las cosas, incluidas las llamadas a funciones que ya estaban señaladas como obsoletas. El desarrollo arrastra deuda desde el primer día.
Referencias
Fuentes y límites
- Documentación oficialGuía de estilo de código — documentación oficial para desarrolladores
Nomenclatura, estructura de ficheros, documentación obligatoria y funciones prohibidas. Consultado el 1 de agosto de 2026.
- Documentación oficialTipos de extensión — documentación oficial para desarrolladores
Estructura esperada y ciclo de vida de cada tipo de extensión. Consultado el 1 de agosto de 2026.
- Documentación oficialInterfaz de privacidad — documentación oficial para desarrolladores
Cómo declara una extensión los datos personales que almacena. Consultado el 1 de agosto de 2026.
El orden de las cuatro alternativas antes de desarrollar es criterio propio, no una recomendación oficial, aunque se apoya en el modelo de extensiones que documenta la plataforma. Los requisitos técnicos concretos cambian entre versiones y hay que comprobarlos siempre en la documentación para desarrolladores enlazada. Lo que cuenta como interfaz pública también evoluciona: algo estable hoy puede quedar marcado como obsoleto mañana, y por eso conviene revisar las notas de cada versión.
Blog
Casos, pruebas y fuentes.
En el blog desarrollo casos particulares, pruebas y fuentes que amplían esta página de referencia.
Ir a blog.albertolarah.comContacto
Antes de decidir si se desarrolla algo dentro de Moodle
Empiezo por la necesidad que hay que resolver, por lo que ya se ha intentado mediante la configuración, por cuánta gente lo usaría y por quién lo mantendría después. Muchas veces esa conversación termina en que no hace falta construir nada.
hola@albertolarah.comLinkedIn ↗