Anmelden

WordPress mit Static Publisher auf S3 und CloudFront veröffentlichen

Static Publisher macht WordPress zur Redaktions- und Steuerungsebene einer professionellen Architektur für statische Veröffentlichungen.

Im Gegensatz zu einem Frontend-Widget-Plugin ist Static Publisher absichtlich in zwei koordinierte Teile aufgeteilt:

  • WordPress-Plugin-Verwaltung für Konfiguration, Warteschlange, Status, Diagnose und Protokollzugriff.
  • Externer Exporter für Crawling, URL-Umschreibung, Bereitstellung, Invalidierung und zeitgesteuerte Ausführung.

Diese Trennung ist beabsichtigt. Das Plugin ruft keine Shell-Befehle aus PHP auf. Es schreibt deterministische JSON-Dateien in das Laufzeitverzeichnis. Der externe Node.js-Runner verarbeitet sie in einer Umgebung mit Node.js, Playwright sowie Datei- und AWS-Zugriff.

Was Static Publisher gut kann​

  • WordPress als statische Artefakte auf S3 + CloudFront veröffentlichen,
  • die gerenderte Frontend-Ausgabe statt nur der Datenbank zu crawlen,
  • Quell-URLs für Staging- oder Produktivziele umzuschreiben,
  • Veröffentlichungs-, Bereitstellungs- und Invalidierungsaufträge aus der WordPress-Verwaltung in die Warteschlange zu stellen,
  • Beiträge, Auflistungen, Archive, Seitennummerierungen und Sitemaps ohne vollständigen Crawl gezielt zu aktualisieren,
  • ein Crawl-Artefakt für mehrere Deployment-Ziele wiederverwenden,
  • WordPress als redaktionelle Kontrollinstanz beizubehalten und AWS als Auslieferungsumgebung einzusetzen.

Steuerungsebene vs. Ausführungs-Engine​

Denke in zwei Schichten:

  • Steuerungsebene in WordPress: Website-Betreiber konfigurieren Laufzeitpfade, Zieleinstellungen, Auftragswarteschlange, Diagnose und Zeitplanregeln in der Verwaltung.
  • Ausführungsengine außerhalb von WordPress: Der Exporter läuft per Shell, CI, Cron oder eigenem Runner-Host und führt den schweren Teil gegen die vollständige gerenderte Seite aus.

Das Modell ist für produktive Umgebungen besser geeignet als ein reiner PHP-Exporter. Der WordPress-Server muss keine Playwright-Abhängigkeiten, Shell-Aufrufe oder langlebige Deployment-Credentials im Request-Pfad bereithalten.

Typische Einsatzszenarien​

Static Publisher passt gut, wenn Sie eines oder mehrere dieser Muster benötigen:

  • WordPress bleibt privat, aber die öffentliche Seite läuft am Edge,
  • die öffentliche Laufzeitumgebung in einem kundeneigenen AWS-Konto liegt,
  • Crawl/Deploy brauchen nachvollziehbares Logging und externe Automation,
  • eine Umgebung publiziert in mehrere Ziele wie Staging und Produktion,
  • später statische Seiten geschützte Routen, Cognito Login, KI oder backend-verbundene Formulare benötigen.

Inhalt dieser Dokumentation​

  • Publishing-Architektur — Produktaufteilung, AWS-Auslieferungsweg und Einbindung in WP Suite
  • Externen Exporter einrichten — Host-Voraussetzungen, Installation von Node.js und Playwright sowie erste Befehle
  • Gezielte Inhaltssynchronisierung — Änderungsplanung für Professional und Agency, Baselines, Archivabgleich, Löschungen und Multisite-Umfang
  • Betrieb — Laufzeitdateien, Warteschlange, Zeitplanregeln, Protokolle und Bereitstellungsprofile