Iniciar sesión

Cola y operaciones de publicación estática de WordPress

Static Publisher está diseñado en torno a trabajos en cola y ejecución externa.

Archivos del entorno de ejecución​

El plugin escribe el estado en wp-content/uploads/smartcloud-static-publisher/runtime, incluidos:

  • config.json
  • queue.json
  • current-run.json
  • last-run.json
  • export.lock

La sincronización específica de contenido también mantiene en este directorio la línea base, el cursor, el punto de control, el manifiesto candidato, el plan de impacto, las diferencias de implementación y el estado de invalidación. Estos archivos son estado operativo, no caché desechable, mientras un trabajo de sincronización de contenido está en cola, en ejecución o esperando un reintento.

Los registros residen en el directorio configurado y los trabajos finalizados archivan sus artefactos en archive/<timestamp-command-jobId-status>/.

Comandos de la cola​

La interfaz de administración puede poner en cola estos comandos:

  • publish
  • crawl
  • deploy
  • invalidate
  • retry-timeouts
  • url para una ejecución sobre una sola ruta

Los trabajos content-sync los crean reglas del programador de los planes Professional o Agency. No son un comando manual de URL de formato libre: el trabajo reclama un intervalo inmutable del diario de contenido de WordPress y use el alcance guardado de la regla. La publicación incremental y la sincronización específica de contenido requieren el mismo nivel de suscripción activa.

Se pueden adjuntar credenciales temporales de AWS a trabajos publish, deploy e invalidate. Solo se inyectan en el entorno del proceso secundario de ese trabajo y se ocultan en las cargas útiles de estado de la administración.

Modelo del programador​

Las reglas del programador las evalúa publisher-exporter queue-runner al inicio de cada ejecución.

Implicaciones importantes:

  • el plugin no inicia el ejecutor por sí mismo,
  • las configuraciones de producción deben usar cron, temporizadores de systemd, CI u otro programador externo,
  • se recomienda una ejecución cada minuto como base,
  • los trabajos duplicados equivalentes se omiten dentro del intervalo actual.
  • la demanda repetida de sincronización de contenido se agrupa; los cambios que llegan durante un intervalo reclamado pasan a ser trabajo pendiente en lugar de ampliar el intervalo en ejecución.

Antes de activar una programación de sincronización de contenido, ejecuta correctamente una publicación completa o incremental normal. Esa versión establece el manifiesto de confianza y la línea base verificada. Los cambios de tema, plugin, enlace permanente, mapa del sitio, reescritura, alcance o destino de implementación hacen que la línea base quede obsoleta intencionadamente y obligan a ejecutar otra publicación normal. La pantalla Ajustes del programador informa directamente de este estado.

Patrón típico de cron en Linux:

* * * * * /usr/bin/flock -n /tmp/static-publisher.cron.lock \
  publisher-exporter queue-runner \
  --runtime-dir /var/www/site/wp-content/uploads/smartcloud-static-publisher/runtime \
  --max-jobs 1 >> /var/www/site/wp-content/uploads/smartcloud-static-publisher/logs/queue-runner-cron.log 2>&1

Perfiles de implementación​

Static Publisher trata los ajustes de destino de nivel superior como destino base. Los destinos adicionales residen en deploymentProfiles y se seleccionan durante deploy o invalidate.

Esto permite:

  • rastrear una vez,
  • implementar en el destino base,
  • reutilizar el mismo artefacto para destinos de preproducción, producción o específicos de clientes,
  • evitar volver a rastrear el origen en cada paso de promoción.

Si un perfil cambia targetOrigin, elige un modo de reescritura absoluta para que la implementación pueda volver a dirigir con seguridad el artefacto ya rastreado.

Registros y flujo de reintentos​

  • los archivos de registro raíz son el conjunto de trabajo actual,
  • los trabajos terminados, fallidos y detenidos archivan artefactos de registro comprimidos con gzip y job.json,
  • retry-timeouts obtiene las URL que reintentar de la ejecución completa archivada más reciente de crawl o publish siempre que sea posible,
  • los archivos antiguos deben depurarse con publisher-exporter prune-logs desde un trabajo de retención.

Los reintentos de sincronización de contenido conservan el mismo intervalo reclamado y el punto de control. La espera progresiva limitada evita someter continuamente a solicitudes un destino que falla. Si un operador abandona un reintento en cola desde WordPress, se elimina su plan local, pero el cursor del diario no cambia; una ejecución posterior del programador puede volver a descubrir el intervalo sin confirmar. Consulte Sincronización específica de contenido para conocer las reglas de seguridad de eliminación y línea base.

Ejecución fuera del host​

Si el host de WordPress no puede ejecutar Node, Playwright o cron, procesa la cola desde otra máquina que pueda ver el mismo directorio de ejecución o descargue la configuración de un trabajo en cola y reprodúcelo desde su propio shell o ejecutor de CI.