Creá tu plugin WordPress y automatizá tareas

Crear un plugin WordPress personalizado para automatizar una tarea repetitiva es más accesible de lo que parece: con un archivo PHP, el header correcto y un par de hooks, tenés un plugin funcional en menos de una hora. La clave está en saber cuándo tiene sentido hacerlo vos en vez de instalar uno genérico.

Por qué crear un plugin personalizado para automatizar

Un plugin WordPress es un archivo PHP (o una carpeta con varios archivos) que extiende la funcionalidad del core sin modificarlo. Eso es todo. La definición es sencilla, y la ejecución también puede serlo.

El debate real es: ¿cuándo tiene sentido crear el tuyo propio en vez de instalar algo como AutomatorWP? AutomatorWP es una herramienta sólida para conectar plugins entre sí sin código — si necesitás que cuando alguien compra en WooCommerce se le asigne un rol y se le mande un mail personalizado, AutomatorWP lo resuelve sin escribir una línea. Pero hay escenarios donde esa capa de abstracción estorba más de lo que ayuda.

Crear tu propio plugin tiene sentido cuando: la tarea es muy específica a tu negocio (o al del cliente), no querés agregar la dependencia de un plugin de terceros que se actualiza cuando le da la gana, o necesitás que el código sea tuyo al 100% para poder mantenerlo. También cuando la tarea es tan simple que instalar un plugin con 80 KB de código para ejecutar 15 líneas propias es, sinceramente, exagerado (sí, en serio).

La estructura mínima para crear un plugin WordPress

Ponele que querés crear un plugin que haga algo puntual: por ejemplo, agregar automáticamente un texto al pie de cada post publicado, o ejecutar una limpieza de datos cada 24 horas. El punto de entrada es siempre el mismo.

Necesitás una carpeta dentro de wp-content/plugins/ con el nombre de tu plugin (usá kebab-case: mi-plugin-limpieza) y adentro un archivo PHP con el mismo nombre. El header de ese archivo es lo que WordPress lee para reconocerlo:

<?php
/**
 * Plugin Name: Mi Plugin de Limpieza
 * Description: Automatiza la limpieza de logs cada 24 hs.
 * Version: 1.0.0
 * Author: Tu Nombre
 * Text Domain: mi-plugin-limpieza
 */

if ( ! defined( 'ABSPATH' ) ) {
 exit;
}

Ese if ( ! defined( 'ABSPATH' ) ) exit; es la primera regla de seguridad: que nadie pueda ejecutar el archivo directamente desde el navegador. Con eso y el header, ya tenés un plugin que aparece en el listado de WordPress y se puede activar. Lo que haga depende de lo que agregues abajo. Para más detalles técnicos, mirá explorar las herramientas de la comunidad.

Si tu plugin va a tener más de un archivo (funciones auxiliares, clases, templates), la convención es crear subcarpetas: includes/ para la lógica, admin/ para lo que va en el panel. Para un plugin de automatización simple, un solo archivo alcanza.

Hooks, acciones y filtros: por qué son el corazón de la automatización

WordPress ejecuta tu código cuando vos decís que lo ejecute, enganchándote a momentos específicos del ciclo de vida de la aplicación. Esos momentos son los hooks.

Hay dos tipos:

• Action hooks: se ejecutan en un momento específico. Vos enganchás una función con add_action() y esa función corre cuando WordPress llega a ese punto. No devuelven nada.
• Filter hooks: interceptan un valor, te dejan modificarlo, y lo devuelven. Se enganchan con add_filter(). Si querés cambiar el contenido de un post antes de que WordPress lo muestre, usás un filtro sobre the_content.

Ejemplos concretos de action hooks que vas a usar seguido: init (corre temprano en cada request, ideal para registrar post types o taxonomías), wp_loaded (después de que todo está cargado), save_post (cuando se guarda un post — ahí podés disparar acciones basadas en el contenido que acaba de guardarse).

¿Y qué pasa cuando querés crear tus propios puntos de ejecución? Usás do_action('mi_plugin_evento_custom') dentro de tu código, y cualquier otro plugin (o tu propio código modularizado) se puede enganchar a ese punto con add_action('mi_plugin_evento_custom', 'mi_funcion'). Así WordPress está construido internamente, y vos podés replicar el mismo patrón.

Configurar tareas programadas con WP-Cron

Acá viene lo importante si tu plugin necesita ejecutar algo automáticamente sin intervención del usuario: WP-Cron.

WP-Cron no es un cron del sistema. No corre en momentos fijos independientemente del tráfico. Corre cuando alguien visita el sitio y WordPress detecta que hay una tarea pendiente. Si tu sitio tiene poco tráfico y la tarea estaba programada a las 3 AM, probablemente se ejecute recién cuando el primer visitante llegue a la mañana siguiente. Esto importa: según la documentación técnica de WP-Cron, la solución correcta para sitios de baja concurrencia es reemplazarlo con un cron del sistema que haga un request a la URL de WP-Cron. Pero para la mayoría de los casos de automatización en sitios con tráfico razonable, WP-Cron funciona bien.

Para registrar una tarea periódica usás wp_schedule_event(). Los intervalos nativos son hourly, twicedaily y daily. Si necesitás otro intervalo (por ejemplo, cada 15 minutos), lo registrás vos con cron_schedules. Relacionado: automatizar la creación de landing pages.

// Agregar intervalo personalizado
add_filter( 'cron_schedules', 'mpl_agregar_intervalos' );
function mpl_agregar_intervalos( $schedules ) {
 $schedules['cada_15_minutos'] = array(
 'interval' => 900,
 'display' => 'Cada 15 minutos',
 );
 return $schedules;
}

// Programar la tarea en la activación del plugin
register_activation_hook( __FILE__, 'mpl_activar_plugin' );
function mpl_activar_plugin() {
 if ( ! wp_next_scheduled( 'mpl_tarea_limpieza' ) ) {
 wp_schedule_event( time(), 'daily', 'mpl_tarea_limpieza' );
 }
}

// Limpiar la tarea al desactivar
register_deactivation_hook( __FILE__, 'mpl_desactivar_plugin' );
function mpl_desactivar_plugin() {
 $timestamp = wp_next_scheduled( 'mpl_tarea_limpieza' );
 wp_unschedule_event( $timestamp, 'mpl_tarea_limpieza' );
}

Ese par de hooks — register_activation_hook y register_deactivation_hook — son los que aseguran que las tareas se creen cuando activás el plugin y se limpien cuando lo desactivás. Si no limpiás las tareas programadas al desactivar, quedan flotando en la base de datos y potencialmente ejecutándose igual.

Automatizar tu tarea repetitiva: paso a paso con ejemplo real

Supongamos el caso concreto que motiva este artículo: cada semana, a mano, vas al panel de WordPress a publicar un post con una plantilla fija (por ejemplo, un reporte semanal de estadísticas, o un recordatorio de suscripción). Lo hacés igual todas las semanas, mismo título, mismo formato, mismo contenido base. Es exactamente el tipo de tarea que justifica crear un plugin pequeño.

El flujo completo tiene cuatro pasos:

• Definir la tarea: en este caso, crear un borrador de post con título y contenido predefinidos cada lunes a la mañana.
• Crear la función callback: la función que WordPress ejecutará cuando llegue el momento.
• Enganchar la función al hook de cron: con add_action('mpl_tarea_semanal', 'mpl_crear_borrador_semanal').
• Programar el evento en la activación: con wp_schedule_event() usando el recurrence que corresponda.

La función callback que crea el post usa wp_insert_post():

add_action( 'mpl_tarea_semanal', 'mpl_crear_borrador_semanal' );
function mpl_crear_borrador_semanal() {
 $post_data = array(
 'post_title' => 'Reporte semanal - ' . date('d/m/Y'),
 'post_content' => '<p>Contenido base del reporte semanal.</p>',
 'post_status' => 'draft',
 'post_author' => 1,
 'post_type' => 'post',
 );
 wp_insert_post( $post_data );
}

Con eso, cada semana aparece un borrador listo para revisar y publicar. Subís el modelo, lo probás en local, funciona bárbaro, lo mandás a producción y de repente el cron no dispara porque el sitio tiene poco tráfico nocturno — así que también configurás un cron del servidor apuntando a https://tusitio.com/wp-cron.php?doing_wp_cron desde el panel del hosting. Si usás el hosting WordPress de Donweb, tenés acceso al panel con cron jobs configurables directamente desde ahí, sin necesidad de SSH ni nada complejo.

Probar, debuggear y validar tu plugin

El error más común cuando empezás a hacer plugins propios es testear directamente en producción. No lo hagas.

El entorno mínimo para probar: un sitio de staging (o local con LocalWP o DevKinsta), con WP_DEBUG activado en el wp-config.php:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Los errores quedan en wp-content/debug.log. Así no los ven los visitantes pero vos sí.

Para inspeccionar las tareas programadas de WP-Cron, el plugin WP Crontrol (gratuito, disponible en el repositorio oficial) te muestra todas las tareas registradas, cuándo se ejecutan, y te deja dispararlas manualmente para probarlas sin esperar. Según la documentación técnica de WP-Cron de Nelio Software, este plugin es la forma más directa de verificar que tu evento quedó correctamente registrado después de activar el plugin.

Query Monitor también suma: te muestra queries ejecutadas, hooks disparados en cada request, y errores de PHP en tiempo real desde el admin bar. Para debuggear por qué tu hook no se dispara en el momento que esperás, es muy útil. Ya lo cubrimos antes en probar cambios en un entorno seguro.

Seguridad, prefixing y mejores prácticas

Hay un detalle que diferencia un plugin que «funciona» de uno que no rompe nada cuando convive con otros 30 plugins en el sitio del cliente: el prefijo.

Todas las funciones, clases, constantes y opciones de tu plugin deben llevar un prefijo único. Si tu plugin se llama «Mi Plugin de Limpieza», usá mpl_ como prefijo en todo:

• mpl_activar_plugin() en vez de activar_plugin()
• MPL_VERSION para constantes
• mpl_opciones para las opciones guardadas en la base de datos

¿Por qué? Porque si otro plugin define una función activar_plugin() (y es muy probable que alguien ya lo haya hecho), PHP tira un fatal error y el sitio se cae. Con prefijo, la colisión es técnicamente imposible salvo que dos plugins usen exactamente el mismo prefijo (que no debería pasar si elegís algo específico).

Sobre seguridad en los cron jobs: no ejecutés código que dependa de input del usuario dentro de una tarea programada. Los cron jobs corren en background sin autenticación de usuario — si tu función hace algo basado en un valor que venía de un formulario, sanitizalo antes de guardarlo y usá ese valor sanitizado desde la base de datos. Y si tu plugin tiene páginas de admin, usá siempre nonces para verificar que las acciones vienen de donde tienen que venir.

Tabla comparativa: crear tu plugin vs usar uno existente

Errores comunes al crear tu primer plugin WordPress

No limpiar los eventos de WP-Cron al desactivar

Este es el error que más veo. Activás el plugin, registrás el evento en WP-Cron, lo desactivás para modificarlo, y el evento sigue corriendo. Si no implementás el register_deactivation_hook con el wp_unschedule_event correspondiente, acumulás tareas fantasma que corren igual aunque el plugin esté desactivado (sí, WP-Cron las ejecuta igual si están en la base de datos).

Usar nombres de funciones sin prefijo

Nombraste tu función enviar_email(). Otro plugin también tiene enviar_email(). PHP no puede tener dos funciones con el mismo nombre en el mismo scope. Resultado: fatal error, pantalla blanca, cliente que llama a las 11 PM. El prefijo específico de tu plugin en todas las funciones evita esto sin excepción. Esto se conecta con lo que analizamos en automatizar la detección de problemas.

Testear en producción directamente

¿Alguna vez activaste un plugin en producción para ver si funcionaba? Exacto, y en algún momento algo se rompió. WordPress tiene staging sites, LocalWP corre en tu máquina en 2 minutos, y los servicios de hosting decentes incluyen ambientes de staging. Usarlos no es opcional cuando estás desarrollando código que modifica la base de datos o crea contenido automáticamente.

Asumir que WP-Cron es un cron real

Si tu tarea necesita ejecutarse exactamente a las 9 AM todos los días, WP-Cron solo no lo garantiza. Se ejecuta cuando alguien visita el sitio y la tarea está vencida. Para precisión real, necesitás un cron del sistema que llame a la URL de WP-Cron, o que ejecute directamente un script WP-CLI (wp cron event run --due-now).

Preguntas Frecuentes

¿Cómo crear un plugin WordPress personalizado desde cero?

Creás una carpeta dentro de wp-content/plugins/ con el nombre de tu plugin y adentro un archivo PHP con el mismo nombre. Ese archivo necesita un bloque de comentario al inicio con al menos Plugin Name: para que WordPress lo reconozca. Con eso activado, podés agregar cualquier código PHP válido usando los hooks de WordPress para ejecutarlo en el momento correcto.

¿Cómo automatizar una tarea repetitiva en WordPress?

La combinación es: definís una función PHP que hace lo que necesitás, la enganchás a un hook de WP-Cron con add_action(), y programás ese evento con wp_schedule_event() al activar el plugin. Podés elegir intervalos nativos (cada hora, dos veces al día, diario) o crear los tuyos propios con el filtro cron_schedules.

¿Qué son los hooks y cómo se usan en WordPress?

Los hooks son puntos predefinidos en el ciclo de ejecución de WordPress donde podés enganchar tu propio código. Los action hooks ejecutan funciones en un momento específico (add_action('init', 'mi_funcion')), y los filter hooks interceptan un valor para que lo modifiques antes de que se use (add_filter('the_content', 'mi_filtro')). WordPress tiene más de 2.000 hooks documentados, y vos podés crear los tuyos con do_action() y apply_filters().

¿WP-Cron es confiable para tareas programadas importantes?

Depende del tráfico del sitio. WP-Cron no es un cron del sistema: corre cuando alguien visita el sitio y WordPress detecta tareas vencidas. Para tareas que necesitan ejecutarse en un horario preciso independientemente del tráfico, la solución es deshabilitar WP-Cron en wp-config.php con define('DISABLE_WP_CRON', true) y configurar un cron real del servidor que llame a la URL de WP-Cron o use WP-CLI.

¿Cuándo conviene crear un plugin propio en vez de usar uno existente?

Cuando la tarea es muy específica a tu negocio o al del cliente, cuando no querés depender de actualizaciones externas, o cuando la lógica es tan simple que instalar un plugin completo sería sobredimensionado. Si la tarea involucra conectar varios plugins populares entre sí (WooCommerce con un CRM, por ejemplo), AutomatorWP o herramientas similares probablemente sean más rápidas y mantenibles.

Conclusión

Crear un plugin WordPress para automatizar una tarea repetitiva no requiere ser un programador avanzado. Requiere entender el ciclo de vida de WordPress, saber dónde enchufar tu código (hooks) y saber cómo programar su ejecución (WP-Cron). Con eso, una tarea que hacías a mano cada semana pasa a ser un proceso que corre solo mientras vos hacés otra cosa.

Lo que sí importa es hacer las cosas bien desde el principio: prefijás tus funciones, limpiás los eventos al desactivar, y probás en staging antes de tocar producción. Son tres hábitos que te ahorran un buen porcentaje de las llamadas de emergencia de fin de semana.

Si a esto le sumás un cron del servidor configurado correctamente en tu hosting, tenés una automatización que funciona con precisión real. Para eso necesitás un hosting que te deje configurar cron jobs desde el panel sin complicaciones — algo que con el hosting WordPress de Donweb viene incluido sin necesidad de meterte por SSH ni depender del soporte para una tarea básica.

Fuentes

• AutomatorWP — Plugin oficial en WordPress.org
• Nelio Software — Cómo manejar tareas programadas con WP-Cron
• DecodeCMS — Tareas automáticas con WP-Cron en WordPress
• WP Tavern — Experiencia construyendo plugins de bloques (aprendizajes reales)