Cron, Action Scheduler y staging
Módulo 7: Visibilidad y alojamiento · Tiempo de lectura: 10 minutos
Objetivo de aprendizaje: Tras esta lección podrá explicar cómo ejecuta WooCommerce tareas en segundo plano, revisar las acciones programadas y corregirlas si hay problemas, y configurar un entorno de staging para una tienda de forma que no se vean afectados clientes, pagos ni pedidos reales.
Conceptos clave: WP-Cron, cron real, DISABLE_WP_CRON, Action Scheduler, acciones programadas, pendiente, completado, fallido, limpieza, staging para una tienda, modo de prueba del proveedor de pago, correo desactivado, webhooks, integraciones, no restaurar la base de datos sobre producción
Lo que ocurre cuando nadie mira
Una tienda realiza mucho trabajo que no depende directamente del clic de un visitante:
- cancelar pedidos no pagados cuando ha pasado el tiempo de Mantener en inventario (lección 3.4);
- enviar correos tras un cambio de estado, y webhooks a las integraciones;
- actualizar informes y estadísticas en el panel de administración;
- limpiar sesiones caducadas y datos temporales;
- aplicar los plazos de conservación de Cuentas y privacidad (lección 2.3);
- en suscripciones o integraciones contables: cobrar pagos y enviar datos.
Para ello WordPress utiliza WP-Cron y WooCommerce añade encima el Action Scheduler. Si no funcionan bien, no lo notará enseguida. Lo notará cuando los pedidos no pagados sigan reservando existencias, los informes sigan vacíos o una integración lleve días de retraso.
WP-Cron y cron real
Cómo funciona WP-Cron y por qué es mejor una tarea cron real se explica en el curso de WordPress, lección 6.3: WP-Cron se ejecuta con las visitas, no según un reloj, y eso es poco fiable con pocos visitantes y una carga con muchos visitantes. La solución: DISABLE_WP_CRON en wp-config.php y una tarea cron en su panel de alojamiento que ejecute wp-cron.php cada pocos minutos.
Para una tienda esto no es una optimización, sino un requisito:
- De noche, cuando hay pocas visitas, los pedidos no pagados deben cancelarse igualmente a tiempo.
- Durante una promoción con mucho tráfico, precisamente no le interesa que una tarea pesada en segundo plano aproveche la petición de página de un cliente que quiere pagar.
En WebOké, esa tarea se crea en DirectAdmin en Trabajo Cron (DA 15.1, KB 48), con /usr/local/bin/php como ruta de PHP; en otros proveedores funciona de forma similar en su pantalla de cron. Para una tienda, elija un intervalo de uno a cinco minutos, mejor que diez. Una tarea que se ejecuta cada minuto y no tiene nada que hacer apenas consume recursos.
Action Scheduler: la cola de WooCommerce
El Action Scheduler es una cola de tareas en segundo plano que se incluye con WooCommerce y que también usan muchos otros plugins (suscripciones, integraciones contables, marketing por correo electrónico). Cada tarea es una acción con una fecha y hora y un estado. La cola se procesa mediante una tarea de WP-Cron (action_scheduler_run_queue), así que también aquí se aplica: sin un cron fiable, la cola se retrasa.
Lo verá todo en WooCommerce > Estado > Acciones programadas (Scheduled Actions). Hay pestañas por estado:
| Estado | Significado | Qué hacer |
|---|---|---|
| Pendiente (Pending) | Aún debe ejecutarse | Si hay cientos con una fecha pasada, la cola va con retraso: revise su cron |
| En curso (In-progress) | Se está ejecutando | Si una acción se queda bloqueada mucho tiempo, consulte el registro junto a ella |
| Completado (Complete) | Hecha | Nada; se limpian automáticamente |
| Fallido (Failed) | Dio un error | Lea el mensaje de error en la columna Registro; a menudo es un plugin o una integración que no está disponible |
| Cancelado (Canceled) | No se ejecutó de forma intencionada | Normalmente nada |
Según el código fuente, el Action Scheduler elimina por defecto las acciones completadas y canceladas al cabo de un mes, y las fallidas al cabo de tres meses. Si aun así la tabla crece mucho, probablemente haya muchas acciones que fallan o se crean una y otra vez; averigüe qué plugin las genera (la columna Grupo y el nombre del hook ayudan), en lugar de limitarse a vaciar la tabla.
Un ejemplo práctico en Theehuis Example: tras un cambio de contraseña, la integración con el programa de contabilidad ponía cada pedido en la cola como acción fallida. Al cabo de una semana había 400 acciones fallidas y faltaban 60 facturas (lección 5.6). Tras reparar la integración, el administrador pudo volver a ejecutar las acciones una por una con Ejecutar (Run).
Staging para una tienda
Qué es un entorno de staging, cómo se crea y cómo se protege (contraseña, noindex) se explica en el curso de WordPress, lección 8.3. En WebOké puede hacerse clonando en Installatron (DA 13.7, KB 232) y con un directorio protegido con contraseña (DA 15.9); otros proveedores tienen herramientas similares. En una tienda hay que añadir varias cosas, porque una copia de una tienda contiene datos reales de clientes y puede realizar acciones reales.
Justo después de clonar, antes de hacer cualquier otra cosa:
- Proveedor de pago en modo de prueba, con claves de prueba. Un staging con claves reales puede recibir pagos reales o realizar reembolsos.
- Correo desactivado o redirigido. De lo contrario, una copia envía confirmaciones, recordatorios y correos de carritos abandonados a clientes reales. Utilice un plugin que bloquee todo el correo o lo envíe a una única dirección de prueba.
- Integraciones y webhooks desactivados. Contabilidad, sincronización de inventario, etiquetas de envío, marketing por correo electrónico: de lo contrario, el staging contabiliza facturas o envía paquetes. Revise también WooCommerce > Ajustes > Avanzado > Webhooks y las claves de la API.
- Revisar las acciones programadas. La cola también se ha copiado. De lo contrario, las acciones pendientes (un correo de recordatorio, un pago de suscripción) se ejecutarán otra vez en el staging.
- Limitar los datos personales. Si no necesita datos reales de clientes para hacer pruebas, elimínelos o anonimícelos en el staging. Un staging también está sujeto al RGPD y a menudo está peor protegido (lección 5.5).
Y la regla más importante al restaurar: nunca restaure la base de datos del staging sobre una tienda en funcionamiento. Entre el momento de clonar y el de restaurar se han añadido pedidos, clientes, movimientos de inventario y pagos; los perdería. Repita los cambios en producción (ahora sabe que funcionan) o sincronice solo los archivos. Si no hay más remedio que hacerlo con la base de datos, hágalo solo con la tienda en modo de mantenimiento, justo después de una copia de seguridad reciente y con una herramienta que omita pedidos y clientes.
Probar una actualización en staging
Un procedimiento típico para una actualización importante de WooCommerce o de un plugin de pago:
- Cree un staging nuevo (clon de producción) y configure correctamente los cinco puntos anteriores.
- Actualice en el staging y ejecute la actualización de la base de datos si WooCommerce la solicita.
- Haga un pedido de prueba en modo de prueba: pagar, fallar, reembolsar (lección 4.5).
- Revise en Acciones programadas y en el registro de errores si hay errores nuevos.
- Después, actualice producción en un momento tranquilo, con una copia de seguridad justo antes (lección 6.2).
Resumen
- WooCommerce realiza mucho trabajo en segundo plano; se ejecuta mediante WP-Cron y el Action Scheduler.
- En una tienda, utilice siempre una tarea cron real (cada uno a cinco minutos) en lugar de WP-Cron con las visitas.
- Revise WooCommerce > Estado > Acciones programadas: muchas acciones pendientes atrasadas o fallidas indican que el cron o una integración no funciona.
- En el staging: proveedor de pago en modo de prueba, correo e integraciones desactivados, revisar las acciones programadas, limitar los datos personales.
- Nunca restaure una base de datos de staging sobre una tienda en funcionamiento; repita los cambios en producción.
Cuestionario
Ejercicio
Ejercicio A7.3: ¿Está protegido su entorno de staging? Es la misma comprobación que el ejercicio A8.3 del curso de WordPress. Primero necesita una prueba de propiedad de su dominio (un registro TXT _weboke-cursus.<domein> o un archivo /.well-known/weboke-cursus-<code>.txt con el código que recibirá). Después, introduzca la dirección de su tienda y la dirección de su staging (un host bajo el mismo dominio). El programa solicita la página de inicio del staging, sin credenciales, y la de producción. Verde si el staging pide una contraseña (401), o si tiene noindex y usa su propia dirección (la entrada REST apunta al host del staging), mientras que producción no tiene noindex. Naranja si el staging tiene noindex pero no contraseña, o no tiene un certificado válido. Rojo si el staging está abierto e indexable, si el staging sigue apuntando a la dirección de producción o si producción tiene noindex por error.
Preguntas para usted (no se corrigen): ¿está el proveedor de pago de su staging en modo de prueba? ¿Está el correo desactivado o redirigido? ¿Se han desactivado las integraciones y los webhooks? ¿Cuántas acciones pendientes y fallidas hay ahora en Acciones programadas en producción?
Para saber más
Estos artículos describen los pasos en los paneles de WebOké; en otros paneles funcionan de forma similar.
- Manual de DirectAdmin 15.1: Trabajo Cron: ejecutar tareas automáticamente
- Crear una tarea cron (y qué hacer si no se ejecuta)
- Crear un entorno de staging de WordPress
- Manual de DirectAdmin 13.7: Clonar y crear un entorno de pruebas (staging)
- Manual de DirectAdmin 15.9: Carpetas protegidas con contraseña
- Curso gratuito de WordPress 8.3: Staging: pruebas seguras
- Curso gratuito de WordPress 6.3: Imágenes, PHP y otras mejoras de velocidad
- Action Scheduler (actionscheduler.org, en inglés): https://actionscheduler.org/