Aprendes a programar tareas periódicas en tu plugin, evitar duplicados, controlar coste de ejecución y limpiar correctamente al desactivar.
Muchos plugins añaden tareas programadas sin control y terminan generando trabajo duplicado, lentitud o logs llenos de errores.
En esta lección construirás tareas periódicas para WP Avisos Contextuales con patrón seguro: programar una vez, ejecutar con guardas y limpiar al desactivar.
También verás cómo evitar que una tarea pesada se dispare en cascada y cómo registrar resultados para diagnóstico.
El objetivo es automatizar mantenimiento sin comprometer rendimiento ni estabilidad.
No es un daemon del sistema; depende de tráfico al sitio.
WP-Cron se ejecuta cuando hay peticiones y detecta eventos pendientes, por eso en sitios sin tráfico puede retrasarse.
En proyectos críticos, suele combinarse con cron del sistema que llame a `wp-cron.php` de forma controlada.
Entender esto evita expectativas falsas sobre precisión temporal.
Cada activación/reinicio no debe crear nuevas copias del mismo evento.
Antes de programar usa `wp_next_scheduled` para comprobar si ya existe la tarea.
Programa en activación o en bootstrap controlado, nunca en cada `init` sin condición.
Desprograma en `register_deactivation_hook` para evitar eventos huérfanos.
Una tarea programada no debe comportarse como proceso infinito.
Divide trabajo en lotes (batch) y evita consultas masivas en una sola ejecución.
Si la tarea puede solaparse, usa lock transitorio para impedir doble ejecución simultánea.
Registra métricas básicas: duración, elementos procesados y errores para detectar degradación.
Sin chequeo previo, cada activación puede multiplicar tareas.
En un plugin de notificaciones, cada despliegue añadía un nuevo evento diario. Al mes había decenas de tareas idénticas ejecutándose.
El impacto fue aumento de CPU y logs duplicados. Se corrigió añadiendo `wp_next_scheduled` y limpieza estricta en desactivación.
Resultado: ejecución única y consumo estable.
Aprendes a programar tareas periódicas en tu plugin, evitar duplicados, controlar coste de ejecución y limpiar correctamente al desactivar.
Código del tema: wp_schedule_event
No es un daemon del sistema; depende de tráfico al sitio.
WP-Cron se ejecuta cuando hay peticiones y detecta eventos pendientes, por eso en sitios sin tráfico puede retrasarse.
En proyectos críticos, suele combinarse con cron del sistema que llame a `wp-cron.php` de forma controlada.
Entender esto evita expectativas falsas sobre precisión temporal.
Cada activación/reinicio no debe crear nuevas copias del mismo evento.
Antes de programar usa `wp_next_scheduled` para comprobar si ya existe la tarea.
Programa en activación o en bootstrap controlado, nunca en cada `init` sin condición.
Desprograma en `register_deactivation_hook` para evitar eventos huérfanos.
register_activation_hook(WPAC_FILE, function (): void {
if (!wp_next_scheduled('wpac_daily_maintenance')) {
wp_schedule_event(time(), 'daily', 'wpac_daily_maintenance');
}
});
register_deactivation_hook(WPAC_FILE, function (): void {
wp_clear_scheduled_hook('wpac_daily_maintenance');
});Una tarea programada no debe comportarse como proceso infinito.
Divide trabajo en lotes (batch) y evita consultas masivas en una sola ejecución.
Si la tarea puede solaparse, usa lock transitorio para impedir doble ejecución simultánea.
Registra métricas básicas: duración, elementos procesados y errores para detectar degradación.
Loop pesado sin límites ni locks.
Lotes, lock y observabilidad.
Sin chequeo previo, cada activación puede multiplicar tareas.
En un plugin de notificaciones, cada despliegue añadía un nuevo evento diario. Al mes había decenas de tareas idénticas ejecutándose.
El impacto fue aumento de CPU y logs duplicados. Se corrigió añadiendo `wp_next_scheduled` y limpieza estricta en desactivación.
Resultado: ejecución única y consumo estable.