Statisches WordPress + Interaktionslaufzeit
WordPress statisch machen, ohne dynamische Funktionen zu verlieren
Die statische Veröffentlichung kann WordPress-PHP aus der öffentlichen Seitenauslieferung entfernen, ohne dass die Website Formulare, Diskussionen, verschachtelte Antworten, Bewertungen, Workflow-Aktionen, Anmeldung oder KI verlieren muss. Entscheidend ist, die Seitenauslieferung von Diensten zu trennen, die Status speichern und Aktionen verarbeiten.
Kurz gesagt Veröffentlichen Sie die Seitenschicht mit Static Publisher und halten Sie ausgewählte Funktionen über dedizierte Pfade vom Browser zum Dienst dynamisch. Flow verarbeitet Formulare, Workflow-Aktionen, Diskussionen, Antworten und Bewertungen; Gatey verwaltet Identität; AI-Kit stellt lokale oder über ein konfiguriertes Backend ausgeführte KI bereit; für geschützte Bereitstellung kann bei Bedarf Static Site Guardian eingesetzt werden.
Was statische Veröffentlichung verändert
Die Herausforderung ist nicht der HTML-Export, sondern das Ersetzen von Laufzeitannahmen
Eine normale WordPress-Website verbirgt viele Interaktionen hinter PHP-Anfragen und der Datenbank. Sobald das öffentliche Frontend statisch wird, benötigt jede Funktion, die Status schreibt, Benutzer authentifiziert, Daten aggregiert oder einen Workflow auslöst, einen ausdrücklichen Laufzeitpfad.
Interaktionsstatus
Formulare sind nur ein Teil der Lücke bei dynamischen Funktionen
Formularübermittlungen brauchen dauerhafte Schreibvorgänge, ebenso Diskussionsthreads, verschachtelte Antworten, Bewertungen, Moderationsstatus und andere Interaktionen auf Datensatzebene. Wird das Problem auf die Suche nach einem Formularendpunkt reduziert, bleibt die umfassendere Interaktionsschicht ungelöst.
Arbeit nach der Übermittlung
Eine Übermittlung kann einen Workflow starten, statt mit der Speicherung zu enden
Prüfung, Routing, Benachrichtigungen, Webhooks, Freigaben, Bewertung oder andere Aktionen erfolgen nach dem Absenden. Diese Prozesse benötigen ein Backend, das von der WordPress-Seitendarstellung unabhängig ist.
Identität und KI
Anmeldung und Wissensfunktionen benötigen ebenfalls eigene Ausführungspfade
Authentifizierung, geschützte APIs, DocSearch, Chat und KI-Aktionen können in einem statischen Frontend weiter funktionieren, wenn browserseitige Komponenten Cognito oder konfigurierte Backend-Dienste direkt aufrufen.
Architekturregel Ordnen Sie jede Funktion nach ihrer Verantwortung zu: statische Dateien für die Seitenauslieferung, Flow für dauerhafte Interaktionen und Workflows, Gatey für Identität, AI-Kit für KI und Suche sowie geschützte Bereitstellung nur dort, wo Zugriffskontrolle erforderlich ist.
Architektur zum Erhalt von Funktionen
Halten Sie das Frontend statisch und verlagern Sie dauerhafte Interaktionen hinter APIs
WordPress bleibt das Autorensystem. Static Publisher stellt die gerenderten Seiten bereit. Browserseitige WP Suite-Komponenten verbinden nur die Funktionen, die Status oder Laufzeitverarbeitung benötigen, mit zweckgebundenen Diensten.
WordPress CMS / Gutenberg
|
v
Static Publisher
|
v
Öffentliches Frontend auf S3 + CloudFront
|
+--> Flow
| Formulare / Speichern-Fortsetzen / Diskussionen
| verschachtelte Antworten / Bewertungen / Workflows
| --> konfiguriertes Flow Backend / APIs
|
+--> Gatey --> Amazon Cognito
| Anmeldung / Registrierung / MFA / SSO
|
+--> AI-Kit
| KI auf dem Gerät oder konfiguriertes Backend
| DocSearch / Chatbot / KI-Funktionen
|
+--> Static Site Guardian, wenn geschützte Pfade erforderlich sind
Bestätigtes Verhalten und Architektur Statische Bereitstellung stellt nicht automatisch dynamischen Status bereit. Flow, Gatey und AI-Kit erhalten bestimmte Funktionen, weil ihre Frontend-Komponenten nach dem Export mit separaten Diensten arbeiten können. Verwenden Sie nur die Laufzeitschichten, die das Projekt tatsächlich benötigt.
Migrationspfad
Erfassen Sie dynamische Funktionen, bevor Sie die öffentliche Laufzeit umstellen
Die sicherste statische Migration beginnt mit einer Liste dessen, was die aktuelle WordPress-Laufzeit über die Seitendarstellung hinaus erledigt.
- Klassifizieren Sie jede laufzeitabhängige Funktion — Listen Sie Formulare, Uploads, Speichern und Fortsetzen, Diskussionen, Antworten, Bewertungen, Anmeldung, Profile, geschützte Inhalte, KI und Suche sowie nachgelagerte Workflow-Aktionen auf, die derzeit von WordPress-Anfragen abhängen.
- Halten Sie die Seitenauslieferung getrennt — Veröffentlichen Sie das cachefähige WordPress-Frontend über Static Publisher und prüfen Sie Links, Assets, Routen, Listen und das öffentliche Ziel, bevor Sie Interaktionsverkehr verlagern.
- Weisen Sie jede dynamische Verantwortung einem Dienst zu — Nutzen Sie Flow für dauerhafte Interaktionen und Workflows, Gatey für Cognito-Identität, AI-Kit für KI oder Wissenszugriff und Kontrollen für geschützte Pfade nur bei privaten statischen Inhalten.
- Testen Sie Status, Identität und Fehlerfälle nach dem Export — Prüfen Sie Übermittlungen, Entwürfe, Diskussionsantworten, Bewertungsaggregation, Authentifizierungsübergänge, API-Autorisierung, KI-Fallback und Cacheverhalten im tatsächlichen statischen Frontend und nicht nur im WordPress-Ursprung.
Wann statisches WordPress mit externen Funktionsdiensten passt
Gut geeignet
Nutzen Sie dieses Muster, wenn die meisten Seiten cachefähig sind, ausgewählte Funktionen aber interaktiv bleiben
- Die Website benötigt Formulare, Workflows, Diskussionen, Antworten, Bewertungen, Anmeldung oder KI, aber die meisten Seitenaufrufe erfordern kein WordPress-PHP.
- Sie möchten Gutenberg und die WordPress-Inhaltsverwaltung behalten, statt das Frontend als separate Anwendung neu zu erstellen.
- Das Team ist bereit, ausdrückliche APIs und Identitätsdienste für Funktionen mit dauerhaftem Status zu betreiben.
Dynamisches WordPress beibehalten
Eine normale WordPress-Laufzeit kann einfacher sein, wenn
- Die meisten öffentlichen Seitenaufrufe serverseitigen Sitzungsstatus oder Datenbankpersonalisierung vor der Darstellung benötigen.
- Die erforderlichen Plugins stark von synchronen WordPress-PHP-Hooks abhängen und nicht durch ausdrückliche Dienstgrenzen ersetzt werden können.
- Die Betriebskosten separater APIs und Dienste durch die Bereitstellungs-, Sicherheits- oder Skalierungsanforderungen des Projekts nicht gerechtfertigt sind.
Fragen von Interessenten
FAQ zu dynamischen Funktionen nach statischer Veröffentlichung
Wie kann ich WordPress statisch machen, ohne Kommentare, Formulare oder Bewertungen zu verlieren?
Halten Sie die öffentliche Seitenschicht statisch und verlagern Sie dauerhafte Interaktionen in ein separates Backend. Flow kann Formulare, Diskussionen, verschachtelte Antworten, Bewertungen und Workflow-Aktionen unterstützen, ohne dass WordPress-PHP jede Interaktion ausliefern muss.
Kann eine statische WordPress-Website Diskussionen und Bewertungen unterstützen?
Ja, wenn die Diskussions- und Bewertungskomponenten des Frontends in ein dediziertes Interaktions-Backend schreiben. Das statische HTML liefert die Oberfläche; der Dienst speichert Antworten, Bewertungsstatus, Aggregation und zugehörige Workflow-Daten.
Funktionieren Anmeldung und geschützte APIs nach dem statischen Export?
Ja. Gatey authentifiziert im Browser gegen Amazon Cognito, und geschützte APIs können JWT- oder IAM-Identität unabhängig vom Pfad der statischen Seitenauslieferung prüfen.
Funktionieren KI-Suche oder ein Chatbot mit statischem WordPress?
Ja. AI-Kit kann unterstützte KI lokal im Browser ausführen oder ein konfiguriertes Backend direkt aufrufen. DocSearch und Chatbot-Erlebnisse können einen AWS-gestützten Wissensendpunkt ohne WordPress-PHP-Proxy verwenden.
WP Suite Funktionsumfang für statische Websites
Halten Sie die Seitenschicht statisch und verbinden Sie nur benötigte Funktionen mit einer separaten Laufzeit
Veröffentlichen Sie WordPress-Seiten mit Static Publisher und erhalten Sie mit Flow, Gatey, AI-Kit und Static Site Guardian nur die dynamischen Funktionen, die das Projekt benötigt.