Activación, desactivación y uninstall: ciclo de vida sin sustos en producción

Implementas correctamente el ciclo de vida del plugin para crear opciones iniciales, programar tareas, desactivar sin dejar procesos vivos y desinstalar con limpieza controlada.

Muchos plugins funcionan en local pero generan problemas en vida real porque no controlan bien su ciclo de vida.

Activar no es solo "encender" el plugin: aquí debes crear estado inicial seguro, validar requisitos y dejar todo preparado para operar.

Desactivar tampoco es borrar datos sin más: normalmente se paran procesos (cron, colas, cachés), pero la configuración se conserva.

La desinstalación sí es el momento de limpieza profunda, siempre respetando qué espera el cliente: borrar todo o conservar datos.

  • Separar responsabilidades evita pérdidas de datos y efectos secundarios.
  • En activación: validas versión mínima de PHP/WordPress, defines opciones por defecto y, si aplica, registras eventos periódicos.
  • En desactivación: limpias tareas en segundo plano (como cron) y transitorios efímeros, pero normalmente conservas ajustes de usuario.
  • En uninstall: eliminas opciones/tablas según política de borrado definida por el proyecto.
  • Activación: preparar entorno y defaults.

Qué debe pasar en cada fase del ciclo de vida

Separar responsabilidades evita pérdidas de datos y efectos secundarios.

En activación: validas versión mínima de PHP/WordPress, defines opciones por defecto y, si aplica, registras eventos periódicos.

En desactivación: limpias tareas en segundo plano (como cron) y transitorios efímeros, pero normalmente conservas ajustes de usuario.

En uninstall: eliminas opciones/tablas según política de borrado definida por el proyecto.

  • Activación: preparar entorno y defaults.
  • Desactivación: detener procesos y dejar sitio estable.
  • Uninstall: limpieza final explícita y controlada.

Activación segura: requisitos, defaults y esquema

La activación debe fallar rápido si el entorno no cumple requisitos.

Antes de crear nada, comprueba requisitos mínimos. Si no se cumplen, desactiva automáticamente y muestra mensaje claro al admin.

Define defaults de configuración con `add_option` para no sobreescribir valores existentes en reactivaciones.

Guarda una versión de esquema (`wpac_db_version`) para futuras migraciones controladas.

Desactivación vs uninstall: no son lo mismo

Confundirlas es un error clásico que provoca pérdida de datos.

Un cliente puede desactivar temporalmente tu plugin para pruebas. Si borras sus datos en ese momento, rompes confianza y operación.

La desactivación debe centrarse en parar tareas activas: desregistrar cron, vaciar cache temporal y dejar el sistema limpio.

La desinstalación (`uninstall.php`) sí puede borrar opciones/tablas, idealmente respetando una opción de "conservar datos".

Caso real: plugin con cron huérfano en producción

Si no limpias eventos al desactivar, el sitio puede seguir ejecutando trabajo fantasma.

En un proyecto editorial, un plugin dejó un evento `wp_cron` activo tras desactivarse. El evento seguía intentando procesar datos inexistentes y llenó logs con errores durante semanas.

El problema no estaba en el feature, sino en ciclo de vida mal cerrado.

Con una limpieza correcta en desactivación (`wp_clear_scheduled_hook`) y versionado de esquema en activación, el equipo eliminó incidentes recurrentes.

WordPress Plugin
04

Activación, desactivación y uninstall: ciclo de vida sin sustos en producción

Implementas correctamente el ciclo de vida del plugin para crear opciones iniciales, programar tareas, desactivar sin dejar procesos vivos y desinstalar con limpieza controlada.

Código del tema: register_activation_hook

📘 Teoría

Qué debe pasar en cada fase del ciclo de vida

Separar responsabilidades evita pérdidas de datos y efectos secundarios.

En activación: validas versión mínima de PHP/WordPress, defines opciones por defecto y, si aplica, registras eventos periódicos.

En desactivación: limpias tareas en segundo plano (como cron) y transitorios efímeros, pero normalmente conservas ajustes de usuario.

En uninstall: eliminas opciones/tablas según política de borrado definida por el proyecto.

  • Activación: preparar entorno y defaults.
  • Desactivación: detener procesos y dejar sitio estable.
  • Uninstall: limpieza final explícita y controlada.

Activación segura: requisitos, defaults y esquema

La activación debe fallar rápido si el entorno no cumple requisitos.

1

Antes de crear nada, comprueba requisitos mínimos. Si no se cumplen, desactiva automáticamente y muestra mensaje claro al admin.

2

Define defaults de configuración con `add_option` para no sobreescribir valores existentes en reactivaciones.

3

Guarda una versión de esquema (`wpac_db_version`) para futuras migraciones controladas.

Ejemplo de activación robusta
register_activation_hook(WPAC_FILE, function (): void {
    if (version_compare(PHP_VERSION, '8.1', '<')) {
        deactivate_plugins(plugin_basename(WPAC_FILE));
        wp_die('WP Avisos Contextuales requiere PHP 8.1 o superior.');
    }

    add_option('wpac_message', 'Aviso inicial');
    add_option('wpac_db_version', '1.0.0');

    if (!wp_next_scheduled('wpac_daily_maintenance')) {
        wp_schedule_event(time(), 'daily', 'wpac_daily_maintenance');
    }
});

Desactivación vs uninstall: no son lo mismo

Confundirlas es un error clásico que provoca pérdida de datos.

Un cliente puede desactivar temporalmente tu plugin para pruebas. Si borras sus datos en ese momento, rompes confianza y operación.

La desactivación debe centrarse en parar tareas activas: desregistrar cron, vaciar cache temporal y dejar el sistema limpio.

La desinstalación (`uninstall.php`) sí puede borrar opciones/tablas, idealmente respetando una opción de "conservar datos".

1

Error frecuente

Borrar opciones en `register_deactivation_hook`.

  • Pérdida de configuración por desactivación temporal.
  • Soporte técnico innecesario.
  • Mala experiencia para cliente y equipo.
2

Patrón recomendado

Borrar en `uninstall.php` con política explícita.

  • Respeta uso temporal de desactivación.
  • Permite rollback rápido.
  • Controla destrucción de datos.

Caso real: plugin con cron huérfano en producción

Si no limpias eventos al desactivar, el sitio puede seguir ejecutando trabajo fantasma.

1

En un proyecto editorial, un plugin dejó un evento `wp_cron` activo tras desactivarse. El evento seguía intentando procesar datos inexistentes y llenó logs con errores durante semanas.

2

El problema no estaba en el feature, sino en ciclo de vida mal cerrado.

3

Con una limpieza correcta en desactivación (`wp_clear_scheduled_hook`) y versionado de esquema en activación, el equipo eliminó incidentes recurrentes.

🧪 Aprende probando

Ejemplo Ejemplo guiado: ciclo completo mínimo (activate/deactivate/uninstall) Implementamos activación con defaults, desactivación con limpieza de cron y uninstall con borrado controlado.

🏁 Retos

Reto Reto real: añade guardas y limpieza consistente Completa el ciclo de vida para que el plugin sea seguro al activarse y limpio al desactivarse.

¿Qué es esto?

Soy Cristian Eslava y a veces hago webs para procrastinar yo y vosotros 😉.

Esta la hice en febrero de 2026 para facilitar el aprendizaje de mis alumnxs. Aprender desarrollo web practicando. La idea es que crezca semanalmente con nuevos temas, tests y retos.

Inspirado en MDN, en W3Schools, en Codepen, en el crack de Manz y en mil sitios de documentación sobre desarrollo web. Quería aportar además de bloques teóricos con ejemplos, la gamificación de los retos y el sistema de test que ya tenía en culTest .

Si te gustó, si no te gustó, si quieres saludarme, o invitarme a 🍻 no dudes en escribirme en cristianeslava@gmail.com .