Architektúra · Statikus kiszolgálás + explicit futtatókörnyezet
Statikus WordPress dinamikus AWS-futtatókörnyezettel
A nyilvános WordPress-oldalakat szolgálja ki S3-ról és CloudFrontból, minden interaktív funkciónak pedig adjon saját böngésző–szolgáltatás futtatási útvonalat ahelyett, hogy a teljes webhelyet visszakötné PHP-hoz és MySQL-hez.
WordPress CMS ↓ Static Publisher S3 + CloudFront ├→ Gatey → Amazon Cognito ├→ Flow → munkafolyamat-backend ├→ AI-Kit → konfigurált AI-/tudás-backend ├→ védett útvonalak → aláírt hozzáférés └→ alkalmazásműveletek → védett API-k
Futtatási határ
A futtatókörnyezetet funkciónként, ne webhelyenként osztályozza
A „statikus” az oldal kiszolgálását írja le. Nem követeli meg a bejelentkezés, űrlapok, beszélgetések, AI vagy alkalmazásműveletek eltűnését. Minden képesség csak akkor lépheti át saját futtatási határát, amikor a látogató használja.
Nyilvános oldalkérés → CloudFront → statikus HTML/assetek Bejelentkezés → böngésző → Cognito Védett statikus útvonal → identitás → aláírt hozzáférés → CloudFront Űrlap / vázlat / beszélgetés → böngésző → Flow-backend AI / DocSearch → böngésző → helyi mód vagy konfigurált backend Alkalmazásírás → böngésző → engedélyezett API
Bizalmi határ A frontend láthatósága nem jogosultság. Az identitást, a védett fájlhozzáférést, az űrlapvalidációt, az AI-hozzáférést és az API-írásokat mindig a felelős szolgáltatásnak kell kikényszerítenie.
Vezérlési sík és futtatási sík
A mátrix különválasztja a szerkesztési tulajdonlást a végrehajtási felelősségtől. Megmutatja, mi marad WordPressben, és mi kerül böngészős vagy AWS-szolgáltatásokba a statikus kiszolgálás után.
| Felelősség | WordPress szerepe | AWS-/futtatási szerep | Miért fontos a szétválasztás |
|---|---|---|---|
| Tartalom és elrendezés | A szerkesztők Gutenbergben építenek oldalakat és CPT-tartalmakat publikálnak | A statikus kiszolgálás adja a renderelt eredményt | A szerkesztési folyamat ismerős marad, a nyilvános forgalom pedig elkerüli a PHP-t. |
| Hitelesítési felület | Az oldal Gatey-blokkot, shortcode-ot vagy widgetet tartalmaz | A Cognito kezeli a belépést, MFA-t, SSO-t és tokeneket | A belépés túléli a statikus exportot, mert a böngészőből a Cognito felé fut. |
| Védett tartalom | A WordPress határozza meg a védett részek helyét | A CloudFront aláírt sütik kényszerítik ki az objektumhozzáférést | A privát statikus oldalakhoz nem kell WordPress-munkamenet. |
| Űrlapok és munkafolyamatok | Az elrendezés és a folyamat szándéka WordPressben szerkeszthető | A backend validál, tárol, továbbít és műveleteket indít | A beküldés a kiszolgálástól függetlenül skálázható. |
| AI-funkciók | Blokkok, chatbotelhelyezés, KB-forrás és beállítások a WP Adminban élnek | Modellhívások, RAG, védőkorlátok és naplózás az AI-backendben futnak | A tartalmi intelligencia szabályozott backendképesség, nem PHP-proxy. |
| Egyedi alkalmazásfunkciók | A WordPress gombokat, konténereket és fiókfüggő UI-t renderel | Az API Gateway és Lambda jogosultságot kényszerít ki és állapotot ír | A frontend statikus, az alkalmazás mégis interaktív. |
A Flow futtatási határa a backendsablon után
A táblázat csak a Flow-ra fókuszál. Elkülöníti a látogatói és adminútvonalakat, valamint az aszinkron végrehajtást, hogy látható legyen, miért kerülnek a WordPress-oldalkérésen kívülre.
| Felület | Példaútvonalak | Futtatási felelősség | Miért PHP-n kívül |
|---|---|---|---|
| Frontendűrlapok | /frontend/forms/{formId}/submit, /drafts, /upload-url | Látogatói bemenet validálása, vázlatok és payload-hivatkozások fogadása, további feldolgozás indítása. | A böngésző statikus oldalról küld; a backend felügyeli a validációt, visszaélést és tartósságot. |
| Adminműveletek | /admin/forms, /admin/submissions, /admin/templates, /admin/workflows, /admin/webhook-endpoints | Definíciók, sablonok és munkafolyamatok konfigurálása védett útvonalakon. | Az írások a kiszolgálástól függetlenül Cognito/IAM-védelmet, scope-okat és IP-korlátokat igényelhetnek. |
| Munkafolyamat-végrehajtás | EventBridge által indított diszpécserek beküldésekhez, állapotokhoz, e-mailhez és webhookokhoz | Aszinkron feldolgozás és eseményrögzítés nyitott oldalkérés nélkül. | Az űrlap megbízható munkafolyamat lesz, nem törékeny szinkron WordPress POST. |
Futtatási felületek térképe
A funkcióhatárok kijelölése után használja a mátrixot biztonsági és üzemeltetési ellenőrzőlistaként. Az egyes felületekhez tipikus hitelesítést, fő kockázatot és ajánlott határt rendel.
| Futtatási felület | Tipikus hitelesítés | WP Suite példa | Fő kockázat | Ajánlott határ |
|---|---|---|---|---|
| Névtelen oldalmegtekintés | Nincs | Static Publisher kimenet | Elavult oldalak, listák vagy assetek | Ellenőrzött alapállapot, manifest-tulajdonlás, CloudFront invalidálás és nyilvános cél ellenőrzése. |
| Belépési-/profilfelület | Nyilvános Cognito-kliens | Gatey Authenticator és Account Attribute blokkok | Hibás callback URL-ek vagy tokenfeltételezések | Cognito App Client, callback domain és tokenkezelés. |
| Védett statikus útvonal | Cognito a süti kiadása előtt | Static Site Guardian folyamat | Sütihatókör, lejárat, kulcsrotáció | CloudFront aláírt sütik és aláíró szolgáltatás. |
| Nyilvános űrlap- vagy AI-hívás | NONE + reCAPTCHA/WAF vagy Cognito | AI-Kit frontendútvonalak és Flow-végpontok | Végpontvisszaélés és modell-/beküldési költség | Sebességkorlátok, validáció, reCAPTCHA, WAF és kvóták. |
| Tagi API-hívás | Cognito JWT vagy IAM | Gatey által védett API-hozzáférés | A frontend láthatóságát jogosultságnak tekintik | API Gateway authorizer, scope-ok vagy IAM-aláírások. |
| Admin-/backendművelet | IAM vagy csak admin Cognito scope-ok | AI-Kit adminútvonalak, KB-műveletek | Kiemelt műveletek kiszivárognak nyilvános felhasználóknak | Külön /admin útvonal, szigorúbb hitelesítés és IP-engedélylista. |
API- és gyorsítótár-tervezés
A futtatási szétválasztás a kiszolgálási szabályokat is módosítja. A táblázat konkrét döntésekké alakítja az architektúrát a cache, API-k, CORS, állapot és látható hibakezelés terén.
| Terület | Jó minta | Rossz minta | Miért fontos |
|---|---|---|---|
| Statikus HTML cache | Hosszú élettartamú cache determinisztikus publikálás utáni invalidálással | Mindenhol rövid cache egy dinamikus komponens miatt | Egy dinamikus widget ne kényszerítse vissza az egész oldalt szervermódba. |
| API-útvonalak | Külön /frontend és /admin felület eltérő hitelesítéssel és korlátozással | Egy általános végpont minden műveletre | A nyilvános widgetek és a kiemelt műveletek kockázata eltér. |
| CORS | Pontosan a szükséges statikus domainek és környezetek engedélyezése | Wildcard CORS hitelesített kérésekkel | A statikus webhelyeknek gyakran több hostnevük van; a CORS legyen tudatos. |
| Állapottartó widgetek | Állapot tárolása Cognitóban, DynamoDB-ben, ideiglenes S3-objektumban vagy célbackendben | WordPress-munkamenetet feltételezni export után | Az exportált oldal nyilvános kérésnél nem rendelkezik PHP-munkamenettel. |
| Hibakezelés | Hasznos állapotok: hitelesítés szükséges, próbálja újra, nem érhető el | A statikus oldal csendben hibázik blokkolt API-nál | A frontend válik a felhasználó számára látható futtatási határrá. |
Megvalósítási útvonal
Először válassza külön a kiszolgálást, majd csak a szükséges futtatókörnyezeteket adja hozzá
Az architektúra akkor üzemeltethető egyszerűbben, ha minden dinamikus követelménynek egyértelmű felelőse és hibafolyamata van.
- A WordPress maradjon a szerkesztési forrás — Az oldalakat WordPressben készítse és ellenőrizze, majd a gyorsítótárazható kimenetet a Static Publisherrel publikálja S3-ra és CloudFrontra.
- Az interaktív funkciók szolgáltatáshatárainak kijelölése — Identitáshoz Cognitót, űrlap- és munkafolyamat-állapothoz Flow-t, helyi vagy konfigurált AI-útvonalakhoz AI-Kitet, védett statikus tartalomhoz aláírt hozzáférést, alkalmazásíráshoz külön API-kat használjon.
- Minden futtatókörnyezet önálló védelme — A megfelelő jogosultságot, validációt, CORS-t, WAF-ot, sebességkorlátozást vagy visszaélés elleni védelmet a szolgáltatáshatáron alkalmazza, ne WordPress-munkamenetre vagy rejtett frontendállapotra támaszkodjon.
- Az éles rendszer tesztelése böngészőalkalmazásként — Az éles domainről ellenőrizze az exportált asseteket, callback URL-eket, CORS-t, hitelesített és névtelen állapotokat, API-hibákat és lejárt hozzáférést.
Mikor ez az architektúra adja a megfelelő határt
Jó választás
Többnyire gyorsítótárazható webhelyek kiválasztott élő funkciókkal
- A nyilvános webhely főként tartalom, de a felhasználóknak bejelentkezésre, űrlapokra, beszélgetésekre, AI-ra vagy védett erőforrásokra is szükségük van.
- A WordPress maradjon a megszokott CMS, miközben a PHP és MySQL kimarad minden nyilvános oldalkérésből.
- Az eltérő futásidejű funkciók külön biztonsági, skálázási vagy tulajdonosi határokat igényelnek.
Válasszon másik modellt
Más futtatókörnyezet egyszerűbb lehet, ha
- A legtöbb oldalt renderelés előtt szerveroldalon, felhasználónként személyre kell szabni.
- A külön frontendalkalmazás már termékkövetelmény, így a headless architektúra tudatos választás.
- A hagyományos dinamikus WordPress tisztán megoldja a terhelést, és a futtatási szolgáltatások szétválasztása nem ad hasznos üzemeltetési határt.
Problémaútmutatók
Továbblépés az architektúrából
Hogyan tehetem statikussá a WordPresst dinamikus funkciók elvesztése nélkül?
Kezdje a WordPress statikussá tétele a dinamikus funkciók elvesztése nélkül című útmutatóval. Ez a bejelentkezést, űrlapokat, beszélgetéseket, értékeléseket, AI-t és védett tartalmat külön futtatókörnyezetekhez rendeli.
Hogyan tarthatom meg a WordPresst szerkesztéshez anélkül, hogy nyilvánosan elérhető lenne?
Lásd a WordPress megtartása szerkesztéshez nyilvános elérés nélkül című útmutatót a szerkesztési forrás és a nyilvános kiszolgálás szétválasztásáról; ezután válassza ki az aktív futtatókörnyezeteket.
Hogyan működnek a hosszú űrlapok és ellenőrzési munkafolyamatok statikus publikálás után?
Lásd a Hosszú WordPress-űrlap mentése és későbbi folytatása, az E-mailes és táblázatos jóváhagyások kiváltása WordPress-munkafolyamattal, valamint a WordPress ellenőrzési munkafolyamat űrlapokkal, beszélgetéssel és értékelésekkel útmutatókat a Flow-útvonalakhoz.
Hogyan működhet a bejelentkezés és a védett tartalom PHP-munkamenetek nélkül?
Lásd a Bejelentkezés hozzáadása statikus WordPresshez a PHP-munkamenetek visszaállítása nélkül útmutatót a Cognito-identitáshoz, majd a Statikus WordPress védelme CloudFront aláírt sütikkel architektúrát a kiszolgálási mechanizmushoz.
Induljon a vásárlói problémából
A megőrzendő funkció alapján válassza ki a futtatási határt
Először a problémaútmutatókkal azonosítsa a szükséges interakciót, majd az implementációs és bizalmi határokhoz térjen vissza az architektúraszintre.