Static Publisher + WordPress
Tartsa meg a WordPresst szerkesztésre, nyilvános elérhetőség nélkül
A szerkesztők továbbra is használhatják a WordPresst, a Gutenberget, az előnézeteket és a közzétételi munkafolyamatot, miközben a látogatók nyilvánosan elérhető WordPress/PHP-futtatókörnyezet helyett az S3-ról és a CloudFrontról kapják a renderelt fájlokat.
Röviden Használja a WordPresst privát szerzői rétegként, renderelje a webhelyet a Static Publisherrel, majd az S3-ról és a CloudFrontról szolgálja ki a nyilvános eredményt. A WordPress marad a tartalomkezelő rendszer, de nem kell a nyilvános kérések útvonalában lennie.
A működési határ problémája
A csapatok gyakran a WordPressben szeretnének szerkeszteni, de nem azzal akarják kiszolgálni a nyilvános oldalakat
A tartalomkezelő rendszernek és a nyilvános futtatókörnyezetnek nem kell ugyanannak a rendszernek lennie. Szétválasztásuk megváltoztatja, mely összetevőknek kell elérhetőnek lenniük egy átlagos látogatói kérés során.
Kitettség
A nyilvános webhely örökli a WordPress-futtatókörnyezet felületét
Ha minden oldalmegtekintés eléri a WordPresst, a nyilvános kiszolgálási útvonal része lesz a PHP, az adatbázis, a wp-login, a bővítménykód és a teljes rendszer üzemeltetési függősége is.
Forgalom
A névtelen forgalom továbbra is az eredeti rendszer kapacitásától függ
A gyorsítótárazás segít, de egy hagyományos felépítéshez továbbra is szükség van a nyilvános kiszolgálási architektúra részeként megtervezett és üzemeltetett WordPress-eredetre.
Migrációs kockázat
A WordPress elhagyása gyakran a szerkesztői munkafolyamat újraépítésével jár
Egy headless újraépítés eltávolíthatja a WordPresst az oldalkiszolgálásból, de új frontendalkalmazást, előnézeti modellt és olyan tartalmi munkafolyamatot is bevezethet, amelynek lecserélését a szerkesztők nem kérték.
Határkijelölési döntés Tartsa meg a WordPresst ott, ahol a legerősebb – a szerzői és tartalomkezelési feladatoknál –, és csak akkor helyezze át a nyilvános oldalkiszolgálást, ha a szétválasztás konkrét üzemeltetési előnyt hoz.
Közzétételi útvonal
Privát WordPress-szerkesztés, renderelt csomag és nyilvános statikus kiszolgálás
A Static Publisher a WordPresst forrásként, a renderelt webhelyet pedig telepíthető csomagként kezeli. A kiválasztott dinamikus képességek különálló böngésző–API interakcióként maradhatnak meg.
Privát / staging WordPress
|
v
A szerkesztők a Gutenberget és a szokásos WordPress-folyamatokat használják
|
v
Külső Static Publisher futtató
| bejárás / renderelés / átírás / ellenőrzés
v
S3-eredet + CloudFront-disztribúció
|
v
A látogató statikus HTML-t és erőforrásokat kap
|
+--> opcionális Gatey-identitás
+--> opcionális Flow-interakciók
+--> opcionális AI-Kit-keresés / AI
+--> konfigurált API-k
Funkcionális határ A statikus közzététel eltávolítja a WordPresst a nyilvános oldalrenderelésből. Nem helyettesíti automatikusan az űrlapokat, hitelesítést, hozzászólásokat, munkafolyamatokat, keresést vagy AI-funkciókat; ha a webhely használja ezeket, külön futtatási útvonalra van szükségük.
Megvalósítás
Helyezze át az oldalkiszolgálást a tartalomkezelő rendszer újraépítése nélkül
Először a nyilvános kiszolgálási határt alakítsa át, majd csak azokat a futásidejű szolgáltatásokat adja hozzá, amelyekre a statikus webhelynek ténylegesen szüksége van.
- Tartsa meg a WordPresst szerzői eredetként — A nyilvános webhely forrásaként használja a meglévő WordPress-tartalommodellt, Gutenberg-blokkokat, előnézeteket és szerkesztői munkafolyamatot.
- Konfigurálja a Static Publishert — Állítsa be az eredetet, a nyilvános célt, az URL-átírásokat, az S3-bucketet, a CloudFront-disztribúciót és a környezet telepítési profilját.
- Renderelje és ellenőrizze a nyilvános csomagot — Először teljes közzétételt futtasson, tekintse át a létrehozott webhelyet, ellenőrizze a belső hivatkozásokat és erőforrásokat, majd igazolja a nyilvános cél működését az inkrementális vagy tartalomszinkronizálási munkafolyamatok használata előtt.
- Külön adja hozzá a dinamikus képességeket — A Gateyt, a Flow-t, az AI-Kitet vagy más API-kat csak azokhoz a funkciókhoz használja, amelyeknek a statikussá alakítás után is futásidejű állapotra vagy hitelesített műveletekre van szükségük.
Mikor megfelelő a privát WordPress és a nyilvános statikus kiszolgálás
Jó választás
Használja ezt a modellt, ha a WordPress tartalomkezelő rendszerként értékes, nyilvános futtatókörnyezetként viszont nem szükséges
- A legtöbb nyilvános oldalmegtekintés névtelen és gyorsítótárazható, például marketing-, dokumentációs, szerkesztőségi vagy ügynökségi webhelyeken.
- A szerkesztők továbbra is a WordPresst használnák, miközben csökkentenék a nyilvános függést a PHP- és MySQL-alapú oldalrendereléstől.
- A projekt a fennmaradó dinamikus funkciókat böngészőoldali identitásra, API-kra, munkafolyamatokra vagy AI-szolgáltatásokra tudja szétválasztani.
Maradjon dinamikus a WordPress
A hagyományos WordPress-futtatókörnyezet egyszerűbb lehet, ha
- A legtöbb nyilvános oldal minden kérésnél szerveroldali személyre szabást vagy adatbázis-állapotot igényel.
- A webhely erősen támaszkodik olyan futásidejű funkciókra, amelyek nem választhatók le egyértelműen a WordPress kéréskezeléséről.
- A csapat nem kíván statikus közzétételi és telepítési munkafolyamatot üzemeltetni.
Vásárlói kérdések
Gyakori kérdések a privát WordPressről és a statikus kiszolgálásról
Hogyan használhatom a WordPresst nyilvános elérhetőség nélkül?
Szerkesztéshez tartsa a WordPresst privát vagy staging eredeten, majd tegye közzé a renderelt kimenetet az S3-ra és a CloudFrontra. A látogatók a statikus webhelyet kapják, nem a WordPress-futtatókörnyezethez csatlakoznak.
Lehet privát a WordPress, miközben a webhely nyilvános?
Igen. A WordPress megmaradhat tartalomkezelő és szerzői környezetként, miközben a nyilvános webhely külön telepített statikus csomagként működik.
A statikus WordPress-webhelyek elveszítik az összes dinamikus funkciót?
Nem. A statikus oldalkiszolgálás és a dinamikus képességek külön döntések. A bejelentkezés, űrlapok, munkafolyamatok, keresés és AI szükség szerint böngészőoldali komponenseket és konfigurált API-kat használhat.
Ez ugyanaz, mint a headless WordPress?
Nem. A headless felépítés általában külön frontendalkalmazást vezet be. A Static Publisher a meglévő WordPress-frontendet rendereli, így a webhely megtarthatja a WordPress-sablonokat, blokkokat és szerkesztői munkafolyamatot.
WP Suite Static Publisher
A WordPress maradjon tartalomkezelő rendszer, ne a nyilvános kérések útvonala
Tegye közzé a renderelt webhelyet az S3-on és a CloudFronton, miközben a szerkesztők továbbra is a WordPressben dolgoznak.