El sistema de eventos de Moodle permite que cualquier componente reaccione cuando ocurre algo relevante en la plataforma. Los eventos pueden lanzarse desde el core, desde otros plugins o desde el tuyo propio. Si quieres que tu plugin escuche uno de ellos, tienes que declararlo explícitamente.

Los observers se definen en:

db/events.php

En ese archivo se declara un array $observers con los eventos que el plugin escucha. Moodle lo lee en tiempo de instalación o actualización y lo cachea internamente. Si modificas ese archivo, necesitas purgar cachés o incrementar la versión del plugin para que el sistema reconstruya esa información.

Cada entrada del array indica la clase completa del evento, por ejemplo \core\event\course_created, y el callback que se ejecutará. El callback suele ser un método estático, típicamente algo como \local_miplugin\event_handler::course_created, aunque usar \observer es igualmente válido. Lo relevante es que el método reciba un objeto que herede de \core\event\base.

Un esquema habitual sería:

db/events.php declara el evento y apunta a \local_miplugin\event_handler::course_created

classes/event_handler.php implementa el método estático que recibe \core\event\course_created $event

Cuando el evento se dispara, Moodle invoca automáticamente ese método y le pasa la instancia correspondiente. No hay registro manual adicional. Está integrado en el sistema de eventos.

Desde el observer trabajas con el objeto $event, que expone datos estructurados y métodos como get_record_snapshot() o get_context(). El código se ejecuta después de que la acción principal ya haya ocurrido, normalmente dentro del mismo flujo de ejecución si el evento es síncrono.

Este mecanismo ha servido de base para capas más declarativas sobre eventos. Un ejemplo claro es tool_trigger, desarrollado por Catalyst IT, que permite definir reglas del tipo "cuando ocurra X, haz Y" sin escribir código. Aunque no tenga un ritmo constante de lanzamientos, sigue manteniéndose comunitariamente y se ha convertido en el estándar de facto para automatizaciones complejas en Moodle. La última vez que lo utilicé fue sobre core 4.5 sin ningún problema; no he probado su comportamiento en versiones posteriores.

También se mencionó durante un tiempo tool_dataflows como posible evolución en esa línea, aunque el repositorio devuelve 404 y no existe como solución mantenida.

En el ámbito empresarial, Moodle Workplace ofrece una aproximación más madura mediante Dynamic Rules, cuya arquitectura fue diseñada inicialmente por Ruslan Kabalin y que hoy mantiene y evoluciona el equipo completo de Workplace. Aquí el modelo es declarativo desde interfaz, pero con un matiz relevante: no solo reacciona a eventos, también evalúa estados mediante tareas programadas. Reglas como "el usuario lleva 10 días sin entrar" combinan lógica event-driven con evaluación periódica. Es una capa construida sobre eventos y scheduled tasks que amplía el patrón más allá del disparador inmediato.

Fuera del propio Moodle, el patrón es fácilmente reconocible. Cuando un observer reacciona a un evento y ejecuta una acción externa, el modelo recuerda a IFTTT (if this then that). Es habitual integrar eventos de Moodle con herramientas como n8n o Zapier, exponiendo web services, enviando webhooks o sincronizando cambios hacia sistemas externos. En ese escenario, el observer actúa como disparador técnico dentro de un flujo de automatización más amplio.

Desde el punto de vista de desarrollo, declarar un observer en db/events.php es sencillo. Lo relevante es entender que estás creando un punto de reacción automático dentro del sistema, que además queda cacheado como parte de la configuración del plugin. Puede ser código PHP tradicional o el primer eslabón de una arquitectura declarativa o de automatización externa.

En todos los casos, el mecanismo base es el mismo: ocurre un evento, alguien lo escucha y se ejecuta una acción. Moodle proporciona la infraestructura. Lo que construyas encima depende de tu diseño técnico y de cómo quieras integrar tu plugin en el ecosistema.