Ha egy külső rendszerből — mondjuk egy AI-tartalomgenerátorból — akarsz cikket küldeni a WordPress oldaladra, két út áll előtted: vagy a beépített REST API-n keresztül publikálsz, vagy telepítesz egy fogadó plugint. Mindkettő működik, de sebességben, biztonságban és karbantartási teherben másképp viselkedik. Rossz választással hónapokra bevállalsz egy felesleges karbantartási kört, jó választással pedig el is felejtheted az egészet. Nézzük, mikor melyik éri meg.
REST API: nincs telepítés, nincs plusz kód
A REST API 2016 óta, a WordPress 4.7-tel a rendszer része, az alkalmazásjelszó (Application Password) pedig az 5.5 óta beépített. Vagyis semmit nem kell telepítened: generálsz egy jelszót a felhasználói profilban, és HTTPS-en keresztül máris küldhetsz tartalmat a /wp-json/wp/v2/posts végpontra. A támadási felület nem nő, mert nem került új kód az oldalra — ez biztonsági szempontból a legnagyobb érv.
Az ára az, hogy a logika a küldő oldalon él: a hibakezelést, az újrapróbálkozást és a képfeltöltést neked kell megoldanod. Utóbbi két lépés — előbb a média-végpontra megy a fájl, aztán kapcsolod a cikkhez. Sebességre viszont nincs panasz: egy publikálás tipikusan egyetlen POST-kérés, átlagos tárhelyen néhány száz milliszekundum alatt megvan, képpel együtt is bőven egy másodperc alatt.
Plugin: kényelem, cserébe karbantartás
Egy fogadó plugin saját végponttal dolgozik: egy lépésben átveszi a cikket, a képet és a metaadatokat, ráadásul az oldalon belül naplóz — hibakeresésnél ez aranyat ér. Cserébe minden WordPress-frissítésnél ellenőrizned kell a kompatibilitást, és minden plusz plugin egy újabb potenciális rés — a WPScan adatbázisában a sérülékenységek túlnyomó többsége pluginból, nem a WordPress magjából származik. Ökölszabályként így döntenénk:
- Sima cikk-publikálás: REST API alkalmazásjelszóval — kezdd ezzel.
- Egyedi mezők, saját blokk-logika: plugin, de tartsd minimálisan karcsún.
- Sok oldal egyszerre: plugin csak központi frissítési tervvel — különben maradj az API-nál.
