Se connecter

File d'attente et opérations de publication statique WordPress

Static Publisher est conçu autour de jobs mis en file d'attente et d'une exécution externe.

Fichiers runtime​

Le plugin écrit son état sous wp-content/uploads/smartcloud-static-publisher/runtime, notamment :

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

La synchronisation ciblée du contenu conserve également les états de base, de curseur, de point de contrôle, de manifest candidat, de plan d'impact, de diff de déploiement et d'invalidation dans ce répertoire runtime. Ces fichiers constituent un état opérationnel, et non un cache jetable, tant qu'un job de synchronisation du contenu est en file d'attente, en cours d'exécution ou en attente de reprise.

Les journaux se trouvent dans le répertoire de logs configuré, et les jobs terminés archivent leurs artefacts sous archive/<timestamp-command-jobId-status>/.

Commandes de la file d'attente​

L'interface d'administration peut mettre en file d'attente les commandes suivantes :

  • publish
  • crawl
  • deploy
  • invalidate
  • retry-timeouts
  • url pour une exécution sur un chemin unique

Les jobs content-sync sont créés par les règles de planificateur Professional ou Agency. Il ne s'agit pas d'une commande manuelle libre d'URL : le job récupère une plage immuable du journal de contenu WordPress et utilise le périmètre enregistré de la règle. La publication incrémentale et la synchronisation ciblée du contenu nécessitent le même niveau d'abonnement actif.

Des identifiants AWS temporaires peuvent être associés aux jobs publish, deploy et invalidate. Ils ne sont injectés que dans l'environnement du processus enfant de ce job et sont masqués dans les charges utiles d'état de l'administration.

Modèle du planificateur​

Les règles du planificateur sont évaluées par publisher-exporter queue-runner au début de chaque invocation de l'exécuteur.

Conséquences importantes :

  • le plugin ne lance pas lui-même l'exécuteur,
  • les environnements de production doivent utiliser cron, des timers systemd, CI ou un autre planificateur externe,
  • un tick d'exécuteur d'1 minute est le socle recommandé,
  • les jobs équivalents en doublon sont ignorés dans le bucket d'intervalle courant,
  • les demandes répétées de synchronisation du contenu sont coalescées ; les modifications arrivant pendant une plage récupérée deviennent du travail en attente plutôt que d'étendre la plage en cours.

Avant d'activer un planning de synchronisation du contenu, lancez une publication normale complète ou incrémentale réussie. Cette version établit le manifest de confiance et la base vérifiée. Les changements de thème, de plugin, de permalien, de sitemap, de réécriture, de périmètre ou de cible de déploiement marquent volontairement la base comme obsolète et exigent une nouvelle publication normale. L'écran des paramètres du planificateur affiche directement cet état.

Modèle cron Linux typique :

* * * * * /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

Profils de déploiement​

Static Publisher considère les paramètres de cible de premier niveau comme la cible de base. Les cibles supplémentaires vivent sous deploymentProfiles et sont sélectionnées pendant deploy ou invalidate.

Cela vous permet de :

  • crawler une seule fois,
  • déployer vers la cible de base,
  • réutiliser le même artefact pour la préproduction, la production ou des cibles spécifiques à un client,
  • éviter de recrawler l'origine à chaque étape de promotion.

Si un profil modifie targetOrigin, préférez un mode de réécriture absolue afin que le déploiement puisse retargeter en toute sécurité l'artefact déjà crawlé.

Journaux et workflow de reprise​

  • les fichiers journaux racine constituent l'ensemble de travail courant,
  • les jobs terminés, échoués et arrêtés archivent des artefacts de journaux compressés gzip ainsi que job.json,
  • retry-timeouts résout les URL de reprise à partir du dernier exécution archivés crawl ou publish complet lorsque c'est possible,
  • les anciennes archives doivent être purgées avec publisher-exporter prune-logs depuis un job de rétention.

Les reprises de synchronisation du contenu conservent la même plage récupérée et le même point de contrôle. Le backoff borné évite de marteler continuellement une cible en échec. Si un opérateur abandonne une reprise en file d'attente dans WordPress, son plan local est supprimé mais le curseur du journal reste inchangé ; un tick ultérieur du planificateur peut redécouvrir la plage non acquittée. Consultez Synchronisation ciblée du contenu pour les règles de suppression et de sécurité de la base.

Exécution hors hôte​

Si l'hôte WordPress ne peut pas exécuter Node, Playwright ou cron, traitez la file d'attente depuis une autre machine qui peut voir le même répertoire runtime, ou téléchargez la configuration d'un job mis en file d'attente et rejouez-la depuis votre propre shell ou exécuteur CI.