Anmelden

Statische WordPress-Publishing-Architektur auf AWS

Static Publisher ist kein einzelner „Export-Button“. Es ist eine Publishing-Architektur, die auf klare Trennung der Verantwortlichkeiten setzt.

Die drei Hauptschichten​

1. WordPress ist Quelle und Steuerungsebene​

WordPress bleibt die maßgebliche redaktionelle Quelle. Redakteure können weiterhin mit Gutenberg, Elementor, Medien, SEO-Plugins und ihren gewohnten Inhaltsabläufen arbeiten.

Das Static Publisher Plugin ergänzt WordPress mit:

  • Ziel- und Laufzeitkonfiguration,
  • Queueing von Crawl-, Deploy-, Invalidate- und Einzel-URL-Jobs,
  • Diagnostik- und Statusansichten,
  • Audit- und Logzugriff,
  • Scheduler-Regel-Konfiguration,
  • einem belastbaren Journal für Inhaltsänderungen zu gezielter Synchronisierung.

2. Exporter als Ausführungsengine​

Das separat installierte Befehlszeilenwerkzeug @smart-cloud/publisher-exporter übernimmt die eigentliche Arbeit:

  • die gerenderte Website crawlen,
  • erforderliche Assets finden,
  • URLs an Zielumgebungen umschreiben,
  • Deployment nach S3,
  • CloudFront invalidieren,
  • Aufträge aus Laufzeitdateien verarbeiten,
  • abgeschlossene Journalbereiche beanspruchen und betroffene öffentliche Seiten abgleichen.

Da er außerhalb von PHP läuft, kann der Exporter auf demselben Host, auf einem eigenen Runner oder in einer CI/CD-Umgebung betrieben werden.

3. AWS ist die Auslieferungsumgebung​

Der öffentliche Auslieferungsweg basiert auf S3 + CloudFront. In diesem Modell ist WordPress das Redaktionssystem, AWS bedient die Seite.

Das schafft eine klare Trennung zwischen:

  • Redaktion und Betrieb in WordPress,
  • Crawl- und Deploy-Ausführung im Exporter,
  • öffentlicher Auslieferung am AWS-Edge.

Warum mehr als ein einfacher Export​

Ein einfacher statischer Export erzeugt Dateien. Static Publisher deckt zusätzlich die Produktionskontexte ab:

  • gerendertes Crawling,
  • Ziel-Domain-Rewrite,
  • Queue- und Scheduler-Workflows,
  • wiederholbare Logs und archivierte Artefakte,
  • Bereitstellungsprofile für mehrere Zielumgebungen,
  • verifizierte Baselines, fortsetzbare Prüfpunkte und manifestbasierte Löschmarkierungen für die gezielte Inhaltssynchronisierung,
  • Ausführung außerhalb des Hosts, wenn WordPress kein Node/Playwright ausführen kann.

Ablauf der gezielten Inhaltssynchronisierung​

Mit einem Professional- oder Agency-Abonnement kann eine Zeitplanregel ausgewählte öffentliche Inhaltstypen verfolgen. WordPress speichert Veröffentlichungen, Aktualisierungen sowie Änderungen an Taxonomien, Hervorhebungen, Veröffentlichungsstatus und Löschungen in einem dauerhaften Journal. Der externe Runner beansprucht einen abgeschlossenen Bereich und leitet aus den gespeicherten Vorher- und Nachher-Zuständen die Auswirkungen auf die öffentliche Website ab.

Die Auswirkung kann die Post-URL, konfigurierte Listing-Routen, die Beitragsseite, Post-Type- und Taxonomie-Archive, optionale Autoren- und Datums-Archive, Paginierung und die Sitemap-Chain umfassen. Ein erfolgreicher normaler Voll- oder inkrementeller Publish legt zuerst eine verifizierte Baseline fest. Danach wird ein Kandidaten-Manifest erst nach Deploy, CloudFront-Invalidierung und öffentlicher Verifikation übernommen; der Journal-Cursor wird erst dann vorangetrieben.

Dieses Modell macht Wiederholungsversuche idempotent und verhindert, dass ein fehlgeschlagener gezielter Deploy stillschweigend Inhalt als veröffentlicht markiert. Konfiguration und Wiederherstellung beschreibt Gezielte Inhaltssynchronisierung.

Verbindung zu WP Suite​

Gatey und Static Guardian​

Static Publisher betreibt die öffentliche Auslieferung. Wenn eine statisch veröffentlichte Seite authentifizierte Bereiche braucht, übernimmt Gatey den Cognito-Login im Browser und Static Guardian kann CloudFront-Pfade auf AWS schützen.

AI-Kit​

AI-Kit kann Frontend KI-Funktionen, Chat oder Knowledge-Search auf statisch ausgelieferten Seiten bereitstellen. Static Publisher passt damit zu einem WordPress-as-editor, AWS-as-runtime Modell.

Flow​

Flow fügt Formulare und Workflows wieder hinzu, wenn statische Auslieferung allein nicht reicht. Öffentliche Seiten bleiben statisch, während Submissions, Automationen und Backend-Logik weiter über Flow und AWS laufen.

Konsequenz für den Betrieb​

Behandle das Plugin als Steuerungsebene und den Exporter als Ausführungsengine. WordPress konfiguriert die Abläufe und stellt Aufträge in die Warteschlange; der Runner crawlt und veröffentlicht.