Automatización y visualización de informes en Moodle con PHP: guía paso a paso

Por qué automatizar informes en Moodle reduce el trabajo manual

Moodle ya contiene matriculaciones, accesos, actividades, entregas, intentos, calificaciones, finalización y participación. El problema rara vez es la ausencia de datos. El problema es el recorrido necesario para convertirlos en una decisión.

Cuando una persona entra en varios cursos, consulta pantallas distintas, descarga archivos y combina columnas, no está haciendo seguimiento. Está preparando el terreno para poder hacerlo. El valor aparece después: cuando el tutor identifica a quién contactar o coordinación detecta una incidencia antes de que se convierta en abandono.

Aquí la automatización en Moodle con PHP sí marca una diferencia. No hace falta empezar con inteligencia artificial, un data warehouse o un cuadro de mando institucional. Basta con encontrar una pregunta repetitiva, fijar sus reglas y devolver una respuesta consistente.

Qué significa la automatización en Moodle con PHP

En términos prácticos, la automatización en Moodle con PHP hace tres cosas: recoge datos del LMS, aplica reglas conocidas y entrega un resultado sin obligar a nadie a reconstruir el proceso a mano.

Por ejemplo, en lugar de pedir cada lunes una exportación con los estudiantes que todavía tienen actividades obligatorias sin completar, Moodle puede preparar ese listado de forma automática y mostrarlo al tutor con los filtros y permisos adecuados.

El problema no suele ser la falta de datos

Cuando un equipo pide “un Excel de Moodle”, casi nunca está pidiendo un archivo. Está intentando saber quién necesita ayuda, qué actividad está generando problemas, qué grupo avanza más despacio o qué curso requiere revisión.

Si esa necesidad queda mal definida, el resultado será una hoja con muchas columnas y poca capacidad de acción. Antes de automatizar, formula una pregunta que admita una respuesta útil.

Señales de que tu Moodle necesita mejores informes

No hacen falta miles de estudiantes para justificar una automatización. Las primeras señales aparecen mucho antes, escondidas en tareas cotidianas que el equipo ya considera “normales”.

Casos iniciales de automatización en Moodle con PHP

Para empezar con la automatización en Moodle con PHP, los mejores casos de uso son aquellos que combinan una pregunta sencilla, datos disponibles y una acción clara.

Asimismo, un informe puede combinar varias señales. Por ejemplo, un tutor podría recibir un resumen con estudiantes que no han accedido recientemente, tienen dos actividades vencidas y muestran un progreso inferior al esperado.

Un ejemplo sencillo: actividades pendientes por estudiante

Por ejemplo, imaginemos un curso con varias actividades obligatorias. Cada lunes, el tutor necesita saber qué estudiantes acumulan tareas pendientes para organizar el seguimiento de la semana.

El proceso manual

1. Entrar en el curso.
2. Consultar la finalización de cada actividad.
3. Descargar uno o varios archivos.
4. Combinar los datos en una hoja de cálculo.
5. Eliminar actividades opcionales y usuarios que no correspondan.
6. Preparar un listado por grupo o tutor.
7. Enviar o compartir el resultado.

El proceso automatizado

1. Moodle identifica las actividades que deben formar parte del seguimiento.
2. Comprueba la finalización de los estudiantes incluidos.
3. Aplica los filtros de curso, grupo, fecha y estado.
4. Genera una vista clara o un archivo descargable.
5. Actualiza el resultado con la frecuencia definida.
6. El tutor revisa la información y decide qué acción realizar.

Informes nativos, plugins existentes o desarrollo personalizado

Sin embargo, automatizar no significa necesariamente desarrollar desde cero. Moodle ya incluye informes y herramientas que pueden resolver muchos casos. Además, existen plugins Moodle a medida que amplían las posibilidades de consulta, integración y construcción de reportes.

Cómo funciona la automatización en Moodle con PHP antes del código

Desde el punto de vista técnico, la automatización en Moodle con PHP puede entenderse como una cadena de seis pasos. Esta separación evita que toda la lógica quede mezclada en una única pantalla o consulta.

Qué cambia en 2026 en la automatización en Moodle con PHP

En 2026, la automatización en Moodle con PHP ya no debería plantearse como un script aislado que consulta tablas y genera un CSV. En cambio, el enfoque profesional consiste en construir una pequeña capa de reporting integrada en Moodle: plugin local, capacidades, servicios reutilizables, tareas programadas, control de contexto, exportación segura y una estrategia mínima de mantenimiento.

Asimismo, el cambio es técnico y operativo a la vez: las instituciones educativas dependen cada vez más de datos fiables para tutoría, calidad académica, seguimiento de la actividad, cumplimiento normativo e integraciones con sistemas externos. Por tanto, un informe de Moodle debe ser comprensible para el usuario académico y, al mismo tiempo, robusto para el equipo técnico.

Compatibilidad para la automatización en Moodle con PHP

Antes de iniciar un proyecto de automatización en Moodle con PHP, conviene decidir qué versiones se van a soportar. Moodle 4.5 LTS continúa con soporte de seguridad hasta octubre de 2027, mientras que Moodle 5.1 y Moodle 5.2 son las ramas estables durante 2026. Por eso, la decisión debe equilibrar compatibilidad, ciclo de soporte e infraestructura disponible.

Matriz de versiones, PHP y estrategia de soporte

Arquitectura para la automatización en Moodle con PHP

Una arquitectura de automatización en Moodle con PHP puede dividirse en cinco capas: extracción de datos, procesamiento, visualización, exportación y ejecución programada. Además, conviene añadir una sexta capa de gobierno del dato. En proyectos reales también deben contemplarse observabilidad, registros, política de retención y compatibilidad con la versión de Moodle y PHP del entorno.

De hecho, esta separación evita duplicar lógica. La misma clase que genera los datos puede utilizarse desde una interfaz web, una tarea programada o una futura integración externa.

Caso práctico de automatización en Moodle con PHP: actividades pendientes

El caso práctico construye un informe de actividades pendientes. Es deliberadamente pequeño: una pregunta clara permite enseñar la arquitectura sin esconderla detrás de un cuadro de mando enorme.

¿Qué estudiantes tienen actividades del curso sin completar?

Así, la respuesta puede ayudar a tutores, docentes y coordinadores a priorizar acciones de seguimiento. No se trata solo de ver datos: se trata de convertir esos datos en intervención educativa.

En concreto, el flujo funcional será el siguiente:

1. Al acceder al informe, el usuario entra desde el curso de Moodle.
2. A continuación, el sistema comprueba que tiene permisos sobre el curso.
3. Después, el plugin obtiene los usuarios inscritos.
4. También revisa las actividades visibles con finalización habilitada.
5. Con esos datos, el sistema consulta el estado de finalización de cada estudiante.
6. Entonces se genera una tabla con las actividades pendientes.
7. Finalmente, el usuario puede filtrar, revisar y descargar el informe en CSV.
8. Opcionalmente, una tarea programada genera el informe periódicamente.

Estructura del plugin para automatización en Moodle con PHP

A continuación, para implementar esta automatización en Moodle con PHP crearemos un plugin local llamado reportpending. Los plugins locales siguen siendo una opción adecuada para funcionalidades transversales que no pertenecen a una actividad concreta, sino a procesos internos del LMS: reporting, integraciones, utilidades administrativas o cuadros de mando internos.

moodle/
└── local/
    └── reportpending/
        ├── version.php
        ├── db/
        │   ├── access.php
        │   └── tasks.php
        ├── classes/
        │   ├── report_generator.php
        │   └── task/
        │       └── generate_report.php
        ├── lang/
        │   ├── en/
        │   │   └── local_reportpending.php
        │   └── es/
        │       └── local_reportpending.php
        ├── index.php
        └── download.php

moodle/
└── local/
    └── reportpending/
        ├── version.php
        ├── db/
        │   ├── access.php
        │   └── tasks.php
        ├── classes/
        │   ├── report_generator.php
        │   └── task/
        │       └── generate_report.php
        ├── lang/
        │   ├── en/
        │   │   └── local_reportpending.php
        │   └── es/
        │       └── local_reportpending.php
        ├── index.php
        └── download.php

En conjunto, esta estructura cubre las piezas necesarias para un primer MVP: metadatos del plugin, permisos, tarea programada, clase generadora, cadenas de idioma, interfaz web y descarga CSV.

Definir los metadatos del plugin

Después de crear la estructura, el archivo version.php identifica el plugin y define la versión mínima de Moodle requerida. En este ejemplo mantenemos Moodle 4.5 LTS como base mínima porque sigue siendo una referencia razonable durante 2026. Sin embargo, si el proyecto nace exclusivamente para Moodle 5.2 o superior, puede elevarse el requisito y trabajar directamente con una base PHP más moderna.

defined('MOODLE_INTERNAL') || die();

$plugin->component = 'local_reportpending';
$plugin->version   = 2026061400;
$plugin->requires  = 2024100700; // Moodle 4.5 LTS como base mínima de compatibilidad.
$plugin->maturity  = MATURITY_STABLE;
$plugin->release   = '1.0.0';

defined('MOODLE_INTERNAL') || die();

$plugin->component = 'local_reportpending';
$plugin->version   = 2026061400;
$plugin->requires  = 2024100700; // Moodle 4.5 LTS como base mínima de compatibilidad.
$plugin->maturity  = MATURITY_STABLE;
$plugin->release   = '1.0.0';

Configurar permisos del informe

Por seguridad, un informe académico puede contener datos personales y datos de progreso. Por tanto, no debe estar disponible para cualquier usuario autenticado. La capacidad del plugin se define en db/access.php.

defined('MOODLE_INTERNAL') || die();

$capabilities = [
    'local/reportpending:view' => [
        'captype' => 'read',
        'contextlevel' => CONTEXT_COURSE,
        'archetypes' => [
            'manager' => CAP_ALLOW,
            'editingteacher' => CAP_ALLOW,
            'teacher' => CAP_ALLOW,
        ],
    ],
];

defined('MOODLE_INTERNAL') || die();

$capabilities = [
    'local/reportpending:view' => [
        'captype' => 'read',
        'contextlevel' => CONTEXT_COURSE,
        'archetypes' => [
            'manager' => CAP_ALLOW,
            'editingteacher' => CAP_ALLOW,
            'teacher' => CAP_ALLOW,
        ],
    ],
];

De este modo, en este ejemplo usamos CONTEXT_COURSE porque el informe se consulta por curso. Así podemos validar si el usuario tiene permiso en ese curso concreto, no en todo el sitio.

Crear las cadenas de idioma

Además, las cadenas de idioma hacen que el plugin sea más mantenible y facilitan futuras traducciones.

defined('MOODLE_INTERNAL') || die();

$string['pluginname'] = 'Informe de actividades pendientes';
$string['reportpending:view'] = 'Ver informe de actividades pendientes';
$string['generatetask'] = 'Generar informe de actividades pendientes';
$string['selectcourse'] = 'Selecciona un curso';
$string['downloadcsv'] = 'Descargar CSV';
$string['student'] = 'Estudiante';
$string['email'] = 'Email';
$string['activity'] = 'Actividad';
$string['type'] = 'Tipo';
$string['state'] = 'Estado';
$string['pending'] = 'Pendiente';

defined('MOODLE_INTERNAL') || die();

$string['pluginname'] = 'Informe de actividades pendientes';
$string['reportpending:view'] = 'Ver informe de actividades pendientes';
$string['generatetask'] = 'Generar informe de actividades pendientes';
$string['selectcourse'] = 'Selecciona un curso';
$string['downloadcsv'] = 'Descargar CSV';
$string['student'] = 'Estudiante';
$string['email'] = 'Email';
$string['activity'] = 'Actividad';
$string['type'] = 'Tipo';
$string['state'] = 'Estado';
$string['pending'] = 'Pendiente';

Extraer datos con la API de Moodle

A continuación, para construir el informe necesitamos obtener tres elementos: el curso, los usuarios inscritos y las actividades con seguimiento de finalización. Para ello, Moodle ofrece APIs internas que permiten acceder a esta información sin escribir SQL directo desde el primer momento. Cuando el dato deba consumirse desde otra aplicación, también puede utilizarse la API REST de Moodle para automatizaciones.

global $CFG;

require_once($CFG->libdir . '/enrollib.php');
require_once($CFG->libdir . '/completionlib.php');

$course = get_course($courseid);
$context = context_course::instance($courseid);

$users = get_enrolled_users($context);
$modinfo = get_fast_modinfo($course);
$completion = new completion_info($course);

global $CFG;

require_once($CFG->libdir . '/enrollib.php');
require_once($CFG->libdir . '/completionlib.php');

$course = get_course($courseid);
$context = context_course::instance($courseid);

$users = get_enrolled_users($context);
$modinfo = get_fast_modinfo($course);
$completion = new completion_info($course);

De este modo, estas funciones permiten trabajar con datos del curso respetando mejor la lógica interna de Moodle: contexto, usuarios inscritos, visibilidad de actividades y finalización.

Crear la clase generadora del informe

A continuación, la clase report_generator se convierte en el núcleo del plugin. Su función será devolver un array estructurado con las actividades pendientes. Esa misma salida podrá usarse después para pintar una tabla HTML, generar un CSV o ejecutar una tarea programada.

namespace local_reportpending;

defined('MOODLE_INTERNAL') || die();

class report_generator {

    public static function get_pending_activities(
        int $courseid,
        int $groupid = 0,
        bool $includesuspended = false
    ): array {
        global $CFG;

        require_once($CFG->libdir . '/enrollib.php');
        require_once($CFG->libdir . '/completionlib.php');

        $course = get_course($courseid);
        $context = \context_course::instance($courseid);

        $users = get_enrolled_users(
            $context,
            '',
            $groupid,
            'u.id, u.firstname, u.lastname, u.email, u.suspended',
            'u.lastname ASC, u.firstname ASC'
        );

        $modinfo = get_fast_modinfo($course);
        $completion = new \completion_info($course);
        $rows = [];

        foreach ($users as $user) {
            if (!$includesuspended && !empty($user->suspended)) {
                continue;
            }

            foreach ($modinfo->get_cms() as $cm) {
                if (!$cm->uservisible) {
                    continue;
                }

                if (!$completion->is_enabled($cm)) {
                    continue;
                }

                $data = $completion->get_data($cm, false, $user->id);

                if ((int) $data->completionstate === COMPLETION_INCOMPLETE) {
                    $rows[] = [
                        'userid' => (int) $user->id,
                        'fullname' => fullname($user),
                        'email' => $user->email,
                        'activity' => format_string($cm->name),
                        'type' => $cm->modname,
                        'cmid' => (int) $cm->id,
                        'state' => get_string('pending', 'local_reportpending'),
                    ];
                }
            }
        }

        return $rows;
    }
}

namespace local_reportpending;

defined('MOODLE_INTERNAL') || die();

class report_generator {

    public static function get_pending_activities(
        int $courseid,
        int $groupid = 0,
        bool $includesuspended = false
    ): array {
        global $CFG;

        require_once($CFG->libdir . '/enrollib.php');
        require_once($CFG->libdir . '/completionlib.php');

        $course = get_course($courseid);
        $context = \context_course::instance($courseid);

        $users = get_enrolled_users(
            $context,
            '',
            $groupid,
            'u.id, u.firstname, u.lastname, u.email, u.suspended',
            'u.lastname ASC, u.firstname ASC'
        );

        $modinfo = get_fast_modinfo($course);
        $completion = new \completion_info($course);
        $rows = [];

        foreach ($users as $user) {
            if (!$includesuspended && !empty($user->suspended)) {
                continue;
            }

            foreach ($modinfo->get_cms() as $cm) {
                if (!$cm->uservisible) {
                    continue;
                }

                if (!$completion->is_enabled($cm)) {
                    continue;
                }

                $data = $completion->get_data($cm, false, $user->id);

                if ((int) $data->completionstate === COMPLETION_INCOMPLETE) {
                    $rows[] = [
                        'userid' => (int) $user->id,
                        'fullname' => fullname($user),
                        'email' => $user->email,
                        'activity' => format_string($cm->name),
                        'type' => $cm->modname,
                        'cmid' => (int) $cm->id,
                        'state' => get_string('pending', 'local_reportpending'),
                    ];
                }
            }
        }

        return $rows;
    }
}

Como resultado, este primer generador ya permite obtener actividades incompletas. En un entorno real habría que enriquecerlo con reglas adicionales: filtrar usuarios suspendidos, seleccionar solo roles de estudiante, limitar por grupo, excluir actividades no obligatorias o tener en cuenta fechas de apertura y cierre.

Visualizar el informe dentro de Moodle

Una vez generado el array de datos, necesitamos una interfaz para consultarlo. Por ello, la página index.php se encargará de comprobar permisos, llamar al generador y mostrar una tabla dentro de Moodle.

require_once(__DIR__ . '/../../config.php');

use local_reportpending\report_generator;

$courseid = required_param('courseid', PARAM_INT);

$course = get_course($courseid);
$context = context_course::instance($courseid);

require_login($course);
require_capability('local/reportpending:view', $context);

$PAGE->set_url(new moodle_url('/local/reportpending/index.php', [
    'courseid' => $courseid,
]));
$PAGE->set_context($context);
$PAGE->set_title(get_string('pluginname', 'local_reportpending'));
$PAGE->set_heading(format_string($course->fullname));

echo $OUTPUT->header();

$rows = report_generator::get_pending_activities($courseid);

$table = new html_table();
$table->head = [
    get_string('student', 'local_reportpending'),
    get_string('email', 'local_reportpending'),
    get_string('activity', 'local_reportpending'),
    get_string('type', 'local_reportpending'),
    get_string('state', 'local_reportpending'),
];

foreach ($rows as $row) {
    $table->data[] = [
        s($row['fullname']),
        s($row['email']),
        s($row['activity']),
        s($row['type']),
        s($row['state']),
    ];
}

echo html_writer::table($table);

$downloadurl = new moodle_url('/local/reportpending/download.php', [
    'courseid' => $courseid,
    'sesskey' => sesskey(),
]);

echo html_writer::link(
    $downloadurl,
    get_string('downloadcsv', 'local_reportpending'),
    ['class' => 'btn btn-primary mt-3']
);

echo $OUTPUT->footer();

require_once(__DIR__ . '/../../config.php');

use local_reportpending\report_generator;

$courseid = required_param('courseid', PARAM_INT);

$course = get_course($courseid);
$context = context_course::instance($courseid);

require_login($course);
require_capability('local/reportpending:view', $context);

$PAGE->set_url(new moodle_url('/local/reportpending/index.php', [
    'courseid' => $courseid,
]));
$PAGE->set_context($context);
$PAGE->set_title(get_string('pluginname', 'local_reportpending'));
$PAGE->set_heading(format_string($course->fullname));

echo $OUTPUT->header();

$rows = report_generator::get_pending_activities($courseid);

$table = new html_table();
$table->head = [
    get_string('student', 'local_reportpending'),
    get_string('email', 'local_reportpending'),
    get_string('activity', 'local_reportpending'),
    get_string('type', 'local_reportpending'),
    get_string('state', 'local_reportpending'),
];

foreach ($rows as $row) {
    $table->data[] = [
        s($row['fullname']),
        s($row['email']),
        s($row['activity']),
        s($row['type']),
        s($row['state']),
    ];
}

echo html_writer::table($table);

$downloadurl = new moodle_url('/local/reportpending/download.php', [
    'courseid' => $courseid,
    'sesskey' => sesskey(),
]);

echo html_writer::link(
    $downloadurl,
    get_string('downloadcsv', 'local_reportpending'),
    ['class' => 'btn btn-primary mt-3']
);

echo $OUTPUT->footer();

Con esto ya hay una primera pantalla funcional dentro de Moodle. No es todavía una pantalla de producción: los cursos grandes exigirán filtros, búsqueda, paginación y ordenación.

Añadir filtros y paginación

Un informe útil no obliga al usuario a leer cientos de filas. Los filtros por estudiante, email, actividad o tipo de recurso no son decoración de interfaz: reducen el tiempo necesario para llegar a la respuesta.

$search = optional_param('search', '', PARAM_TEXT);
$type = optional_param('type', '', PARAM_ALPHANUMEXT);
$page = optional_param('page', 0, PARAM_INT);
$perpage = optional_param('perpage', 50, PARAM_INT);

$rows = report_generator::get_pending_activities($courseid);

if ($search !== '') {
    $rows = array_filter($rows, function(array $row) use ($search): bool {
        $needle = core_text::strtolower($search);

        return strpos(core_text::strtolower($row['fullname']), $needle) !== false
            || strpos(core_text::strtolower($row['email']), $needle) !== false
            || strpos(core_text::strtolower($row['activity']), $needle) !== false;
    });
}

if ($type !== '') {
    $rows = array_filter($rows, function(array $row) use ($type): bool {
        return $row['type'] === $type;
    });
}

$total = count($rows);
$rows = array_slice($rows, $page * $perpage, $perpage);

$search = optional_param('search', '', PARAM_TEXT);
$type = optional_param('type', '', PARAM_ALPHANUMEXT);
$page = optional_param('page', 0, PARAM_INT);
$perpage = optional_param('perpage', 50, PARAM_INT);

$rows = report_generator::get_pending_activities($courseid);

if ($search !== '') {
    $rows = array_filter($rows, function(array $row) use ($search): bool {
        $needle = core_text::strtolower($search);

        return strpos(core_text::strtolower($row['fullname']), $needle) !== false
            || strpos(core_text::strtolower($row['email']), $needle) !== false
            || strpos(core_text::strtolower($row['activity']), $needle) !== false;
    });
}

if ($type !== '') {
    $rows = array_filter($rows, function(array $row) use ($type): bool {
        return $row['type'] === $type;
    });
}

$total = count($rows);
$rows = array_slice($rows, $page * $perpage, $perpage);

Sin embargo, este filtrado en memoria solo resulta suficiente para un MVP o para cursos pequeños. En instalaciones grandes, conviene optimizar el enfoque: preprocesar resultados con cron, almacenar snapshots en una tabla propia o limitar el informe por grupos y actividades concretas.

Exportar el informe en CSV

Por otra parte, la exportación CSV es una de las salidas más útiles porque permite abrir el informe en Excel, Google Sheets, LibreOffice o herramientas de análisis. Sin embargo, debe hacerse de forma segura, comprobando sesión, curso y permisos.

require_once(__DIR__ . '/../../config.php');

use local_reportpending\report_generator;

$courseid = required_param('courseid', PARAM_INT);
require_sesskey();

$course = get_course($courseid);
$context = context_course::instance($courseid);

require_login($course);
require_capability('local/reportpending:view', $context);

$rows = report_generator::get_pending_activities($courseid);

$filename = 'pending-activities-course-' . $courseid . '-' . date('Ymd-His') . '.csv';

header('Content-Type: text/csv; charset=utf-8');
header('Content-Disposition: attachment; filename="' . $filename . '"');
header('Pragma: no-cache');
header('Expires: 0');

$output = fopen('php://output', 'w');

// BOM opcional para mejorar compatibilidad con Excel en algunos entornos.
fwrite($output, "\xEF\xBB\xBF");

fputcsv($output, [
    'User ID',
    'Full name',
    'Email',
    'Activity',
    'Type',
    'Course module ID',
    'State',
]);

foreach ($rows as $row) {
    fputcsv($output, [
        $row['userid'],
        $row['fullname'],
        $row['email'],
        $row['activity'],
        $row['type'],
        $row['cmid'],
        $row['state'],
    ]);
}

fclose($output);
exit;

require_once(__DIR__ . '/../../config.php');

use local_reportpending\report_generator;

$courseid = required_param('courseid', PARAM_INT);
require_sesskey();

$course = get_course($courseid);
$context = context_course::instance($courseid);

require_login($course);
require_capability('local/reportpending:view', $context);

$rows = report_generator::get_pending_activities($courseid);

$filename = 'pending-activities-course-' . $courseid . '-' . date('Ymd-His') . '.csv';

header('Content-Type: text/csv; charset=utf-8');
header('Content-Disposition: attachment; filename="' . $filename . '"');
header('Pragma: no-cache');
header('Expires: 0');

$output = fopen('php://output', 'w');

// BOM opcional para mejorar compatibilidad con Excel en algunos entornos.
fwrite($output, "\xEF\xBB\xBF");

fputcsv($output, [
    'User ID',
    'Full name',
    'Email',
    'Activity',
    'Type',
    'Course module ID',
    'State',
]);

foreach ($rows as $row) {
    fputcsv($output, [
        $row['userid'],
        $row['fullname'],
        $row['email'],
        $row['activity'],
        $row['type'],
        $row['cmid'],
        $row['state'],
    ]);
}

fclose($output);
exit;

En este caso, la implementación genera el CSV en tiempo real. Para informes pesados, es más recomendable que el cron genere el archivo en Moodledata y que download.php solo lo entregue después de comprobar permisos.

Automatizar el informe con cron y scheduled tasks

La visualización bajo demanda resuelve la consulta inmediata. Sin embargo, muchos equipos necesitan generar informes de forma periódica: cada madrugada, cada lunes, al cierre de una unidad didáctica o antes de una reunión de coordinación.

Por su parte, Moodle implementa la automatización recurrente mediante scheduled tasks. Estas tareas se registran dentro del plugin y se ejecutan cuando el cron general está configurado correctamente. Además, esta guía sobre automatización en Moodle con cron, scheduled tasks y tareas ad hoc amplía los patrones para procesos pesados.

defined('MOODLE_INTERNAL') || die();

$tasks = [
    [
        'classname' => 'local_reportpending\task\generate_report',
        'blocking' => 0,
        'minute' => '0',
        'hour' => '3',
        'day' => '*',
        'dayofweek' => '*',
        'month' => '*',
    ],
];

defined('MOODLE_INTERNAL') || die();

$tasks = [
    [
        'classname' => 'local_reportpending\task\generate_report',
        'blocking' => 0,
        'minute' => '0',
        'hour' => '3',
        'day' => '*',
        'dayofweek' => '*',
        'month' => '*',
    ],
];

Después se crea la clase de la tarea en classes/task/generate_report.php.

namespace local_reportpending\task;

defined('MOODLE_INTERNAL') || die();

class generate_report extends \core\task\scheduled_task {

    public function get_name(): string {
        return get_string('generatetask', 'local_reportpending');
    }

    public function execute(): void {
        global $DB;

        $courses = $DB->get_records('course', ['visible' => 1]);

        foreach ($courses as $course) {
            if ((int) $course->id === SITEID) {
                continue;
            }

            mtrace('Generating pending activities report for course ID: ' . $course->id);

            $rows = \local_reportpending\report_generator::get_pending_activities((int) $course->id);

            mtrace('Rows generated: ' . count($rows));
        }
    }
}

namespace local_reportpending\task;

defined('MOODLE_INTERNAL') || die();

class generate_report extends \core\task\scheduled_task {

    public function get_name(): string {
        return get_string('generatetask', 'local_reportpending');
    }

    public function execute(): void {
        global $DB;

        $courses = $DB->get_records('course', ['visible' => 1]);

        foreach ($courses as $course) {
            if ((int) $course->id === SITEID) {
                continue;
            }

            mtrace('Generating pending activities report for course ID: ' . $course->id);

            $rows = \local_reportpending\report_generator::get_pending_activities((int) $course->id);

            mtrace('Rows generated: ' . count($rows));
        }
    }
}

Por ahora, esta tarea es sencilla: genera los datos y escribe trazas con mtrace(). En una versión más completa, podría guardar CSV en Moodledata, enviar un email al tutor, registrar la ejecución en una tabla propia o actualizar un dashboard.

Configurar el cron de Moodle

En primer lugar, para que las tareas programadas funcionen, el cron de Moodle debe estar activo en el servidor. Una configuración habitual en Linux sería:

*/1 * * * * /usr/bin/php /var/www/html/moodle/admin/cli/cron.php >/dev/null 2>&1

*/1 * * * * /usr/bin/php /var/www/html/moodle/admin/cli/cron.php >/dev/null 2>&1

Además, en producción hay que comprobar que el usuario del sistema tenga permisos correctos, que la versión de PHP CLI sea compatible con Moodle y que los errores de ejecución queden registrados.

Dónde guardar los informes generados

Además, si los informes se generan automáticamente, es habitual almacenarlos en Moodledata. Esta carpeta no debería ser accesible directamente desde el navegador, por lo que es adecuada para archivos protegidos.

global $CFG;

$dir = $CFG->dataroot . '/local_reportpending';

if (!is_dir($dir)) {
    mkdir($dir, 0770, true);
}

$filename = 'pending-activities-' . $courseid . '-' . date('Ymd-His') . '.csv';
$filepath = $dir . '/' . $filename;

global $CFG;

$dir = $CFG->dataroot . '/local_reportpending';

if (!is_dir($dir)) {
    mkdir($dir, 0770, true);
}

$filename = 'pending-activities-' . $courseid . '-' . date('Ymd-His') . '.csv';
$filepath = $dir . '/' . $filename;

Por último, también conviene definir una política de retención: por ejemplo, conservar informes durante 30, 60 o 90 días. Esto evita acumular ficheros innecesarios y ayuda a cumplir criterios de minimización de datos.

Casos de uso de informes automatizados en Moodle

A partir de ahí, el informe de actividades pendientes es solo un punto de partida. La misma arquitectura puede utilizarse para muchos otros escenarios de seguimiento y analítica educativa.

Errores frecuentes al automatizar informes en Moodle

El error más tentador es empezar por la consulta. Parece progreso porque ya hay filas en pantalla, pero todavía no sabemos qué decisión debe mejorar el informe. Un buen informe empieza con una pregunta, no con un SELECT.

Checklist antes de llevar el informe a producción

Antes de instalar un plugin de informes en un Moodle real, conviene revisar una serie de puntos técnicos, funcionales y de protección de datos. Además, esta revisión debe repetirse después de cada cambio relevante de versión o infraestructura.

Cómo escalar esta solución

Después del MVP, el plugin puede crecer hacia una capa de reporting completa. El peligro está en construir ese futuro antes de comprobar que alguien usa el primer informe. La demo cabe en una tarde; el mantenimiento se queda durante años.

Preguntas frecuentes sobre informes automáticos en Moodle

Recursos oficiales recomendados

Por último, para mantener el plugin actualizado, conviene revisar la documentación oficial de Moodle antes de cerrar cada versión. Especialmente: notas de versión, requisitos de PHP, API de tareas programadas y guías de desarrollo de plugins.

Conclusión: automatiza el trabajo repetitivo, no el criterio

La automatización en Moodle con PHP no empieza en version.php ni termina al descargar un CSV. Empieza cuando una tarea repetitiva se convierte en una pregunta bien definida. A partir de ahí, el plugin recoge datos, aplica reglas, protege el acceso y entrega una respuesta que alguien puede utilizar.

El ejemplo de actividades pendientes es pequeño a propósito. La misma arquitectura sirve para progreso, participación, calificaciones, SCORM, H5P, competencias o alertas tempranas. Lo importante es mantener separadas las responsabilidades: el generador construye los datos, la página los presenta, el endpoint controla la descarga y la tarea programada se ocupa del trabajo pesado.

Un CSV automático puede ahorrar tiempo. Un proceso bien diseñado devuelve capacidad de seguimiento. No son la misma cosa.