Se connecter

Publier WordPress vers S3 et CloudFront avec Static Publisher

Static Publisher transforme WordPress en couche d'édition et de contrôle pour une chaîne de publication statique professionnelle.

Contrairement à un plugin de widget frontend, Static Publisher est volontairement découpé en deux parties coordonnées :

  • l'administration du plugin WordPress pour la configuration, la mise en file d'attente, l'état, les diagnostics et l'accès aux journaux ;
  • l'exportateur externe pour l'exécution du crawl, de la réécriture, du déploiement, de l'invalidation et des tâches pilotées par le planificateur.

Cette séparation est délibérée. Le plugin ne lance pas de processus depuis PHP. Il écrit des fichiers JSON de runtime déterministes, et l'exécuteur Node.js externe les traite sur une machine où Node.js, Playwright, l'accès au système de fichiers et les identifiants AWS sont déjà disponibles.

Ce dans quoi Static Publisher excelle​

  • publier des sites WordPress sous forme d'artefacts statiques pour S3 + CloudFront,
  • crawler le frontend rendu plutôt que seulement le contenu de la base de données,
  • réécrire les URL source pour des cibles de préproduction ou de production,
  • mettre en file d'attente le travail de publication, de déploiement et d'invalidation depuis l'administration WordPress,
  • publier des changements ciblés d'articles, de listings, d'archives, de pagination et de sitemap sans recrawl complet,
  • réutiliser un même artefact de crawl sur plusieurs cibles de déploiement,
  • conserver WordPress comme plan de contrôle éditorial tandis qu'AWS devient le runtime de diffusion.

Plan de contrôle versus moteur d'exécution​

Pensez au produit en deux couches :

  • Plan de contrôle dans WordPress : les propriétaires du site configurent les chemins runtime, les paramètres de cible, la mise en file d'attente des jobs, les diagnostics et les règles du planificateur depuis un écran d'administration familier.
  • Moteur d'exécution hors de WordPress : l'exportateur s'exécute depuis un shell, CI, cron ou un hôte d'exécution dédié et effectue le gros du travail sur le site entièrement rendu.

Ce modèle convient mieux aux environnements de production qu'un exportateur purement PHP. Le serveur WordPress n'a pas besoin d'exécuter Playwright, de gérer l'exécution de shell ni de conserver des identifiants de déploiement de longue durée dans le chemin de requête.

Cas d'usage typiques​

Static Publisher est un bon choix lorsque vous avez besoin d'un ou plusieurs des schémas suivants :

  • WordPress reste privé, mais le site public doit être diffusé en périphérie,
  • le runtime public doit vivre dans un compte AWS appartenant au client,
  • les jobs de crawl et de déploiement ont besoin de journaux reproductibles et d'une automatisation externe,
  • un environnement doit publier vers plusieurs cibles comme la préproduction et la production,
  • le site statique a ensuite besoin de routes protégées, d'une connexion Cognito, d'IA ou de formulaires reliés au backend.

Ce que couvre cette documentation​

  • Architecture de publication — la séparation du produit, le chemin de diffusion AWS et la manière dont Static Publisher s'inscrit dans la pile WP Suite au sens large
  • Configuration de l'exportateur externe — prérequis de l'hôte, installation Node/Playwright et commandes de première exécution
  • Synchronisation ciblée du contenu — planification des changements de contenu Professional et Agency, bases, réconciliation des archives, suppressions et périmètre multisite
  • Opérations — fichiers runtime, workflow de file d'attente, règles du planificateur, journaux et profils de déploiement