WordPress

A WordPress nyílt forráskódú tartalomkezelő rendszer, amely PHP-n és MySQL vagy MariaDB adatbázison fut, GPLv2 licenc alatt. Szerveroldali alkalmazás: a kiszolgálón PHP-t és adatbázist kell futtatni, a projekt dokumentációja szerint PHP 8.3 vagy újabb, MariaDB 10.11 vagy MySQL 8.0 vagy újabb, valamint HTTPS támogatás ajánlott, webszervernek pedig az Apache vagy az nginx.

Egy telepítés néhány jól elkülöníthető részből áll: magfájlok, a wp-content könyvtár, a wp-config.php és az adatbázis. A megjelenést a téma adja, a funkcionalitást a bővítmények, a tartalom szerkesztése pedig a blokkszerkesztőben történik, amely maga is a REST API-ra épül.

Felépítés: mag, téma, bővítmény

A téma kétféle lehet: klasszikus téma PHP, JavaScript és CSS alapokon, vagy blokk téma, amely főként HTML-ből és egy témakonfigurációs fájlból áll, és a teljes oldal a szerkesztőben alakítható. A bővítmények hookokon és szűrőkön keresztül kapcsolódnak a maghoz, ezért egy bővítmény nem csak funkciót ad: a saját kódjával a támadási felületet is növeli.

• A bővítményeket és a témákat érdemes a WordPress.org könyvtárából vagy ismert forrásból beszerezni; a dokumentáció szerint a nem megbízható forrásból származó csomagok kompromittálhatják az oldalt.
• A rövid kódok és a blokkok futásidőben, PHP-ban állnak össze, ezért a kimenet mindig a telepítéstől és az aktív bővítményektől függ.
• A Docker alapú üzemeltetésnél ugyanez a réteg jelenik meg konténerben, de az adatbázis és a feltöltött fájlok itt is külön kezelendők.

A REST API

A REST API JSON objektumokként teszi elérhetővé az oldal adatait: végpontokat ad a bejegyzésekhez, oldalakhoz, taxonómiákhoz és a többi beépített tartalomtípushoz. A jogosultsági szabályok ugyanazok, mint a webhelyen: ami nyilvános, az jellemzően a REST API-n is nyilvános, a privát vagy jelszóval védett tartalomhoz viszont hitelesítés kell. Bármely nyelv használhatja, amely HTTP kérést tud küldeni és JSON-t tud értelmezni, a listavégpontok pedig lapozhatók, így nagyobb állomány is kiolvasható.

• A saját migrációnk így zajlott: 31 bejegyzést vittünk ki a REST API-n keresztül a régi telepítésből.
• Ugyanez a réteg szolgálja ki a blokkszerkesztőt és a modern admin felületeket, tehát nem külön kiegészítés, hanem a mag része.
• A kiolvasott JSON nem tartalmazza a megjelenítést: a sablonokat, a rövid kódokat és a bővítmények mezőit az új oldalnak kell újra feloldania.

Migráció statikus buildre

• Tartalom: a bejegyzéseken és oldalakon túl a kategóriák, a címkék és a médiatár fájljai is átkerülnek, a belső hivatkozásokat pedig az új útvonalakra kell igazítani.
• Átirányítások: minden régi URL-hez tartoznia kell egy állandó átirányításnak az új címre, különben a keresőkben felhalmozódott hivatkozások elvesznek.
• Bővítményfüggőség: a rövid kódok és az egyedi bejegyzéstípusok a statikus oldalon nem futnak le, ezeket fordítási időben kell helyettesíteni.
• Üzemeltetés: a WordPress telepítés PHP-t, adatbázist, verziófrissítéseket és mentéseket igényel; a statikus build ezt a réteget kiveszi az éles kiszolgálásból, és az Astro mellett a kiszolgálás nginx alá kerül.

Karbantartás és biztonság

A dokumentáció egyértelműen fogalmaz: a WordPress biztonsága szempontjából az a legfontosabb, hogy maga a WordPress, valamint az összes telepített bővítmény és téma naprakész legyen.

• A kisebb és biztonsági kiadásokat a WordPress 3.7 óta a legtöbb telepítés automatikusan, a háttérben telepíti, a nagyobb kiadásokhoz viszont jellemzően egy kattintás kell.
• A kézi frissítés előtt az adatbázis és az összes fájl mentése kötelező lépés, a bővítményeket pedig előtte ki kell kapcsolni; a wp-config.php, a wp-content és a testreszabott .htaccess nem törölhető.
• A kiszolgáló és a hálózat a szolgáltató felelőssége, az alkalmazás, a bővítmények és a jogosultságok viszont az üzemeltetőé, és ezt a határt érdemes tisztázni.
• A megerősítés a kockázat csökkentéséről szól: a hozzáférések szűkítése, a rendszeres mentés és a telepítés állapotának ismerete együtt adnak kiszámítható működést.

Tovább olvasás

• WordPress dokumentáció
• REST API Handbook
• Hardening WordPress

A CyberElectrónál a WordPress nem elméleti eszköz: erről a platformról költöztünk statikus buildre, és a REST API-n kiolvasott tartalmat visszük tovább.