Se connecter

Synchronisation ciblée du contenu WordPress

La synchronisation ciblée du contenu publie les effets publics des modifications de contenu WordPress sans crawler le site complet. Elle est disponible avec un abonnement Professional ou Agency actif, comme la publication incrémentale, et s'exécute via une règle de planificateur enregistrée ainsi que la file d'attente externe @smart-cloud/publisher-exporter.

Ce qu'une règle suit​

Chaque règle sélectionne un ou plusieurs types de publication publics et interrogeables publiquement avec des permaliens stables. WordPress journalise leurs transitions publiques, notamment :

  • publication et mises à jour du contenu publié,
  • changements de taxonomie et d'état épinglé,
  • dépublication, mise à la corbeille et suppression définitive,
  • modifications de permalien, d'auteur et de date de publication qui affectent les surfaces publiques activées.

La règle peut réconcilier les archives de types de publication et de taxonomies, la page des articles configurée, les archives facultatives d'auteur et de date, la pagination et la chaîne du sitemap. Utilisez Routes de listing explicites pour les pages Query Loop ou autres surfaces de listing dont WordPress ne peut pas déduire les requêtes de manière fiable. Les routes doivent être relatives au site, une par ligne, par exemple / ou /insights/.

C'est pourquoi la publication ou la modification d'un article peut mettre à jour plusieurs fichiers statiques : l'article lui-même ne représente parfois qu'un membre de l'ensemble d'impact des listings, archives, pagination et sitemap.

Établir d'abord la base​

Une publication normale complète ou incrémentale réussie doit établir une base vérifiée avant qu'un travail ciblé puisse être déployé. La base associe la règle à la version WordPress courante, à la source et à la cible, au comportement de réécriture, à la configuration du sitemap, au périmètre sélectionné et au manifest de crawl de confiance.

Relancez une publication normale lorsque l'administration affiche Nouvelle base requise. Les causes habituelles sont une version du thème ou d'un plugin, des changements de permalien ou de sitemap, des modifications de réécriture, une cible de déploiement différente ou des ajustements du périmètre de synchronisation du contenu. La synchronisation du contenu s'arrête en toute sécurité au lieu de s'élargir vers un crawl complet implicite lorsque sa base est obsolète.

Comportement du planificateur et des tentatives​

Le planificateur WordPress ne lance pas Node.js de lui-même. Exécutez publisher-exporter queue-runner depuis cron, un timer systemd, le Planificateur de tâches Windows ou CI. Un tick d'exécuteur d'une minute est recommandé ; l'intervalle propre à la règle détermine la fréquence à laquelle la demande est évaluée.

L'exécuteur traite une plage fermée du journal. Les nouvelles modifications qui arrivent pendant l'exécution deviennent du travail en attente pour une tâche ultérieure. Les demandes équivalentes sont coalescées, et les échecs utilisent un backoff borné tout en préservant le point de contrôle. Le curseur validé n'avance qu'après la réussite du déploiement, de l'invalidation CloudFront et de la vérification finale.

Si vous abandonnez une tentative depuis l'écran des jobs, Static Publisher efface son plan local et son point de contrôle, mais n'acquitte pas la plage du journal. Un futur tick du planificateur peut donc créer un nouveau job pour le même travail en attente.

Mises à jour et suppressions sûres​

Pour le contenu publié, l'exécuteur rend la nouvelle URL publique et les surfaces de navigation concernées. Pour une dépublication, une mise à la corbeille, une suppression ou un changement de permalien, il utilise la dernière URL publique exacte enregistrée avant la transition. Les alias de corbeille WordPress se terminant par __trashed sont rejetés comme cibles de suppression.

La suppression distante est détenue par le manifest : la synchronisation du contenu ne peut marquer en tombstone qu'un chemin de sortie déjà présent dans le manifest de crawl de confiance. Elle ne liste jamais tout le préfixe S3 pour deviner ce qui doit être supprimé, de sorte que les objets sans rapport ou présents uniquement à distance sont préservés. Le nettoyage global des ressources reste de la responsabilité d'une réconciliation normale complète ou incrémentale.

Multisite WordPress​

Inclure les sous-sites multisite est désactivé par défaut. Lorsqu'il est désactivé, la règle ne suit que le site qui héberge le runtime Static Publisher.

Activez-le uniquement lorsque :

  • WordPress fonctionne comme un réseau multisite,
  • SmartCloud Static Publisher est activé au niveau du réseau,
  • les sous-sites inclus utilisent la même origine avec des URL basées sur des chemins et partagent l'espace de noms de sortie statique configuré.

L'activer suit les types de publication correspondants sur tout le réseau et donne à chaque événement son identité de site. Cela modifie aussi le périmètre de la règle, donc lancez ensuite une nouvelle publication normale. Les sous-sites hébergés indépendamment ou mappés par domaine ont besoin de cibles Publisher séparées ; ils ne sont pas traités silencieusement comme des chemins du site principal.

Contrôles opérationnels​

L'écran des paramètres du planificateur affiche les séquences observées et validées, le décalage, l'état de préparation de la base, le travail en attente, les tentatives de reprise et la dernière opération. Pour qu'une exécution terminée soit saine, les séquences observées et validées doivent correspondre, le décalage doit être nul, la base doit être prête et aucun job ni point de contrôle de synchronisation du contenu ne doit rester actif.