Architektur · Statische Auslieferung + explizite Laufzeit
Statisches WordPress mit dynamischer Laufzeit auf AWS
Belassen Sie die öffentliche WordPress-Seitenauslieferung auf S3 und CloudFront. Geben Sie jeder interaktiven Funktion eine eigene Browser-zu-Dienst-Laufzeit, statt die gesamte Website wieder an PHP und MySQL zu binden.
WordPress-CMS ↓ Static Publisher S3 + CloudFront ├→ Gatey → Amazon Cognito ├→ Flow → Workflow-Backend ├→ AI-Kit → konfiguriertes KI-/Wissens-Backend ├→ geschützte Pfade → signierter Zugriff └→ Anwendungsaktionen → geschützte APIs
Laufzeitgrenze
Klassifizieren Sie die Laufzeit je Funktion, nicht je Website
„Statisch“ beschreibt die Seitenauslieferung. Anmeldung, Formulare, Diskussionen, KI oder Anwendungsaktionen müssen deshalb nicht verschwinden. Jede Fähigkeit kann nur bei ihrer Nutzung durch Besucher eine eigene Laufzeitgrenze überschreiten.
Öffentlicher Seitenaufruf → CloudFront → statisches HTML/Assets Anmeldung → Browser → Cognito Geschützter statischer Pfad → Identität → signierter Zugriff → CloudFront Formular / Entwurf / Diskussion → Browser → Flow-Backend KI / DocSearch → Browser → lokaler Modus oder konfiguriertes Backend Anwendungsschreibzugriff → Browser → autorisierte API
Vertrauensgrenze Sichtbarkeit im Frontend ist keine Autorisierung. Identität, geschützter Dateizugriff, Formularvalidierung, KI-Zugriff und API-Schreibvorgänge müssen jeweils von dem zuständigen Dienst durchgesetzt werden.
Steuerungsebene und Laufzeitebene
Diese Matrix trennt redaktionelle Verantwortung von Ausführungsverantwortung. Sie zeigt, was in WordPress bleibt und was nach der statischen Veröffentlichung in Browser- oder AWS-Dienste verlagert wird.
| Verantwortung | WordPress-Rolle | AWS-/Laufzeitrolle | Warum die Trennung wichtig ist |
|---|---|---|---|
| Inhalt und Layout | Redakteure erstellen Seiten in Gutenberg und veröffentlichen CPT-Inhalte | Statische Auslieferung stellt das gerenderte Ergebnis bereit | Der redaktionelle Ablauf bleibt vertraut, während öffentlicher Traffic PHP umgeht. |
| Authentifizierungsoberfläche | Die Seite enthält einen Gatey-Block, Shortcode oder ein Widget | Cognito verarbeitet Anmeldung, MFA, SSO und Tokens | Die Anmeldung überlebt den statischen Export, weil sie im Browser gegen Cognito läuft. |
| Geschützte Inhalte | WordPress definiert die Position geschützter Bereiche | CloudFront Signed Cookies erzwingen Objektzugriff | Private statische Seiten brauchen keine WordPress-Sitzungen. |
| Formulare und Workflows | Formularlayout und Workflow-Absicht werden in WordPress bearbeitet | Das Backend validiert, speichert, routet und löst Aktionen aus | Übermittlungen skalieren unabhängig von der Seitenauslieferung. |
| KI-Funktionen | Blöcke, Chatbot-Platzierung, KB-Quellenwahl und Einstellungen liegen in WP Admin | Modellaufrufe, RAG, Guardrails und Protokollierung laufen im KI-Backend | Content Intelligence wird kontrollierte Backend-Fähigkeit statt PHP-Proxy. |
| Eigene App-Funktionen | WordPress rendert Buttons, Container und kontobewusste Oberfläche | API Gateway und Lambda erzwingen Autorisierung und schreiben Zustand | Das Frontend kann statisch bleiben, während die Anwendung interaktiv ist. |
Flow-Laufzeitgrenze nach der Backend-Vorlage
Diese Tabelle betrachtet nur Flow. Sie trennt Besucherrouten, Admin-Routen und asynchrone Workflow-Ausführung und zeigt, warum diese Aufgaben außerhalb der WordPress-Seitenanfrage liegen.
| Oberfläche | Beispielrouten | Laufzeitverantwortung | Warum außerhalb von PHP |
|---|---|---|---|
| Frontend-Formulare | /frontend/forms/{formId}/submit, /drafts, /upload-url | Besuchereingaben validieren, Entwürfe und Nutzlastreferenzen annehmen sowie Folgeverarbeitung auslösen. | Der Browser kann von einer statischen Seite senden; das Backend übernimmt Validierung, Missbrauchsschutz und Dauerhaftigkeit. |
| Admin-Aktionen | /admin/forms, /admin/submissions, /admin/templates, /admin/workflows, /admin/webhook-endpoints | Definitionen, Vorlagen und Workflows über geschützte Verwaltungsrouten konfigurieren. | Schreiboperationen können unabhängig von der Seitenauslieferung Cognito/IAM, Bereiche und IP-Beschränkungen verlangen. |
| Workflow-Ausführung | EventBridge-gesteuerte Dispatcher für Übermittlungen, Statusänderungen, E-Mail und Webhooks | Arbeit asynchron verarbeiten und Ereignisse aufzeichnen, ohne eine Seitenanfrage offen zu halten. | Formulare werden verlässliche Workflows statt eines fragilen synchronen WordPress-POSTs. |
Karte der Laufzeitoberflächen
Nutzen Sie diese Matrix nach Wahl der Funktionsgrenzen als Sicherheits- und Betriebscheckliste. Sie ordnet jeder Oberfläche typische Autorisierung, Hauptrisiko und empfohlene Durchsetzungsgrenze zu.
| Laufzeitoberfläche | Typischer Authentifizierungsmodus | WP-Suite-Beispiel | Hauptrisiko | Empfohlene Grenze |
|---|---|---|---|---|
| Anonymer Seitenaufruf | Keine | Static-Publisher-Ausgabe | Veraltete Seiten, Listen oder Assets nach Inhaltsänderung | Geprüfte Basis, Manifestverantwortung, CloudFront-Invalidierung und öffentliche Zielprüfung. |
| Anmelde-/Profiloberfläche | Öffentlicher Cognito-Client | Gatey Authenticator und Account Attribute Blocks | Fehlkonfigurierte Callback-URLs oder Token-Annahmen | Cognito App Client, Callback-Domain und Token-Verarbeitung. |
| Geschützter statischer Pfad | Cognito vor Cookie-Ausgabe | Static Site Guardian Flow | Cookie-Bereich, Ablauf, Schlüsselrotation | CloudFront Signed Cookies und Signer-Dienst. |
| Öffentlicher Formular- oder KI-Aufruf | NONE + reCAPTCHA/WAF oder Cognito | AI-Kit-Frontend-Routen, Flow-Formular-, Entwurfs- und Upload-Endpunkte | Endpunktmissbrauch und Modell-/Übermittlungskosten | Ratenlimits, Validierung, reCAPTCHA, WAF und Quoten. |
| Mitglieder-API-Aufruf | Cognito JWT oder IAM | Gatey-geschützter API-Zugriff | Frontend-Sichtbarkeit wird mit Autorisierung verwechselt | API-Gateway-Autorisierer, Bereiche oder IAM-Signaturen. |
| Admin-/Backend-Aktion | IAM oder admin-only Cognito-Bereiche | AI-Kit-Admin-Routen, KB-Aktionen | Privilegierte Aktionen für öffentliche Nutzer offenlegen | Separate /admin-Route, strengere Authentifizierung, IP-Zulassungsliste. |
API- und Cache-Design
Die Laufzeittrennung verändert auch die Auslieferungsregeln. Die Tabelle übersetzt die Architektur in konkrete Entscheidungen für Cache, API-Trennung, CORS, Zustand und sichtbare Fehlerbehandlung.
| Designbereich | Gutes Muster | Schlechtes Muster | Warum es wichtig ist |
|---|---|---|---|
| Statisches HTML-Caching | Langlebiger Cache mit deterministischer Invalidierung nach Veröffentlichung | Überall kurzer Cache, weil eine Komponente dynamisch ist | Ein dynamisches Widget darf nicht die ganze Seite in den Servermodus zwingen. |
| API-Routen | Getrennte /frontend- und /admin-Oberflächen mit unterschiedlicher Authentifizierung und Drosselung | Ein generischer Endpunkt für alle Aktionen | Öffentliche Widgets und privilegierte Aktionen haben andere Risikoprofile. |
| CORS | Exakte statische Domains und Umgebungen für Browserzugriff zulassen | Wildcard-CORS mit Anfragen samt Zugangsdaten | Statische Websites haben oft mehrere Hostnamen; CORS muss bewusst gesetzt werden. |
| Zustandsbehaftete Widgets | Sitzungszustand in Cognito, DynamoDB, temporären S3-Objekten oder zweckgebundenem Backend speichern | Nach dem Export WordPress-Sitzungszustand voraussetzen | Bei öffentlichen Anfragen besitzt die exportierte Seite keine PHP-Sitzung. |
| Fehlerbehandlung | Komponenten zeigen hilfreiche Zustände wie „Anmeldung erforderlich“, „Erneut versuchen“ oder „Nicht verfügbar“ | Statische Seite scheitert still bei gesperrter API | Das Frontend wird zur sichtbaren Laufzeitgrenze. |
Implementierungspfad
Trennen Sie zuerst die Auslieferung und ergänzen Sie nur die benötigten Laufzeiten
Die Architektur ist leichter zu betreiben, wenn jede dynamische Anforderung einen klaren Verantwortlichen und Fehlerpfad hat.
- WordPress als redaktionelle Quelle behalten — Erstellen und prüfen Sie Seiten in WordPress und veröffentlichen Sie anschließend cachefähige Ausgaben mit Static Publisher auf S3 und CloudFront.
- Interaktive Funktionen ihren Dienstgrenzen zuordnen — Nutzen Sie Cognito für Identität, Flow für Formular- und Workflow-Zustand, AI-Kit für lokale oder konfigurierte KI-Pfade, signierten Zugriff für geschützte statische Inhalte und dedizierte APIs für Anwendungsschreibvorgänge.
- Jede Laufzeit unabhängig schützen — Wenden Sie passende Autorisierung, Validierung, CORS, WAF, Drosselung oder Missbrauchsschutz an der jeweiligen Dienstgrenze an, statt auf WordPress-Sitzungen oder verborgenen Frontend-Zustand zu vertrauen.
- Produktion als Browseranwendung testen — Prüfen Sie exportierte Assets, Callback-URLs, CORS, authentifizierte und anonyme Zustände, API-Fehler und abgelaufenen Zugriff auf der Produktionsdomain.
Wann diese Architektur die richtige Grenze bildet
Gut geeignet
Überwiegend cachefähige Websites mit ausgewählten Live-Funktionen
- Die öffentliche Website besteht primär aus Inhalten, benötigt aber Anmeldung, Formulare, Diskussionen, KI oder geschützte Ressourcen.
- WordPress soll das vertraute CMS bleiben, ohne PHP und MySQL in jede öffentliche Seitenanfrage einzubeziehen.
- Verschiedene Laufzeitfunktionen benötigen unterschiedliche Sicherheits-, Skalierungs- oder Verantwortungsgrenzen.
Anderes Modell wählen
Eine andere Laufzeit kann einfacher sein, wenn
- Die meisten Seiten vor dem Rendern serverseitig personalisiert werden müssen.
- Eine separate Frontend-Anwendung bereits Produktanforderung ist und eine Headless-Architektur bewusst gewählt wird.
- Klassisches dynamisches WordPress die Aufgabe sauber löst und getrennte Laufzeitdienste keine nützliche Betriebsgrenze schaffen.
Problemlösungen
Nächste Schritte ausgehend von der Architektur
Wie mache ich WordPress statisch, ohne dynamische Funktionen zu verlieren?
Beginnen Sie mit WordPress statisch betreiben, ohne dynamische Funktionen zu verlieren. Der Leitfaden ordnet Anmeldung, Formulare, Diskussionen, Bewertungen, KI und geschützte Inhalte expliziten Laufzeiten zu.
Wie behalte ich WordPress zum Bearbeiten, ohne es öffentlich bereitzustellen?
Lesen Sie WordPress zum Bearbeiten behalten, ohne es öffentlich bereitzustellen zur Trennung von redaktionellem Ursprung und öffentlicher Auslieferung. Entscheiden Sie anschließend mit dieser Architektur über die aktiven Browserlaufzeiten.
Wie funktionieren lange Formulare und Prüfworkflows nach statischer Veröffentlichung?
Lesen Sie Lange WordPress-Formulare speichern und später fortsetzen, E-Mail- und Tabellenfreigaben durch einen WordPress-Workflow ersetzen und Einen WordPress-Prüfworkflow mit Formularen, Diskussionen und Bewertungen aufbauen für die Flow-spezifischen Pfade.
Wie funktionieren Anmeldung und geschützte Inhalte ohne PHP-Sitzungen?
Lesen Sie Anmeldung zu statischem WordPress hinzufügen, ohne PHP-Sitzungen zurückzubringen zur Cognito-Identität im Browser und Sicheres statisches WordPress mit CloudFront Signed Cookies zum Auslieferungsmechanismus.
Beginnen Sie beim Käuferproblem
Wählen Sie die Laufzeitgrenze anhand der Funktion, die erhalten bleiben soll
Bestimmen Sie zuerst mit den Problemlösungen die benötigte Interaktion und kehren Sie dann für Implementierungs- und Vertrauensgrenzen zur Architekturebene zurück.