Négy WP-CLI deploy-csapda, ami némán tör el
A hibaüzenettel járó hiba a jó eset: ott legalább tudod, hogy baj van. Ez a négy nem szól — a parancs sikerrel lefut, és utána valami mégsem stimmel.
Mind a négy egy-egy elvesztegetett délutánból származik. Nem különlegesek: WordPress-oldalak átköltöztetésénél előbb-utóbb bárki beleszalad. Ami közös bennük, az az, hogy a kimenet zöld, a visszatérési érték nulla, a napló üres — és az eredmény mégis hibás.
- 01 parancs lefut
- 02 kilépési kód: 0
- 03 az eredmény mégis hibás
a hiba csak a látogatónál derül ki
Egy — az escape-elt URL, amit a keresés nem talál meg
A költöztetés kötelező lépése a domaincsere az adatbázisban. Erre való a
wp search-replace, ami a sorosított adatokat is helyesen
kezeli — ezért is szokás rá hagyatkozni.
Csakhogy a szerkesztővel épített oldalak a felépítésüket JSON-ként tárolják egy meta mezőben. JSON-ban a perjel escape-elhető, és a szerkesztő él is ezzel: a webcímek nem a megszokott alakban szerepelnek, hanem escape-elt perjelekkel. A keresés ezért nem talál rájuk — miközben a lap többi részén hibátlanul cserél.
Az eredmény az, hogy az oldal nagyrészt működik. A szövegek jók, a menü jó, csak épp a szerkesztővel beillesztett képek és videók mutatnak a régi címre. Ez az a hiba, ami a legkönnyebben átcsúszik egy ellenőrzésen, mert az ember a lap tetejét nézi meg, nem a hatodik szekciót.
A javítás egyszerű, ha az ember tud róla: ugyanazt a cserét le kell futtatni escape-elt alakra is. Érdemes mellé venni az urlencode-olt és a kétszer kódolt változatot is — ezek átirányításokban és beágyazott hivatkozásokban bukkannak fel.
Kettő — a jogosultság, ami átutazik a tömörítésen
Ez a legalattomosabb a négy közül, mert minden ellenőrzés átengedi.
A tar nem csak a fájlokat viszi át, hanem a
jogosultságaikat is. Ha a fejlesztői gépen egy kép
szűkre állított jogokkal került a projektbe — tipikusan mert letöltésből
másolták be —, akkor a szerveren pontosan ugyanolyan szűk marad. A
webkiszolgáló felhasználója nem tudja olvasni.
Ami ilyenkor történik, az kifejezetten megtévesztő. A fájl ott van a helyén. A tartalma bájtra azonos. Az ellenőrző összeg egyezik. A „mi hiányzik” típusú összehasonlítás üres listát ad. A lap HTTP 200-at válaszol. Egyedül a látogató lát törött képet.
Az scp sem menti meg a helyzetet: meglévő fájl
felülírásakor megtartja a korábbi jogosultságot. Kicsomagolás után tehát
külön be kell állítani az olvashatóságot a célgépen — és érdemes a
forrásnál is javítani, különben minden következő átvitel újratermeli.
Az ellenőrzése egyetlen sor: számold meg a webgyökérben azokat a fájlokat, amelyekre nincs olvasási jog a többi felhasználónak. Nullát kell adnia. Ez az a fajta ellenőrzés, ami egy elkapott hibából születik — erről szól az ellenőrző szkriptről írt darab.
Három — az adatbázis-export, ami üres fájlt ad
A wp db export nem PHP-ból menti az adatbázist, hanem
meghívja a mysqldump programot. Ez a különbség adja a
csapdát.
Ha az adatbázis nem a szokásos hálózati porton, hanem socketen érhető el — helyi fejlesztői környezetekben ez gyakori —, akkor a PHP oldali kapcsolódási beállítás nem hat a külső programra. Az nem találja meg a kiszolgálót, és üres fájllal fejeződik be.
A veszélyes az, hogy ez nem ad hibát. A parancs lefut, a fájl létrejön, a méret nulla vagy pár száz bájt. Aki ezt automatizált lépésként futtatja, az a következő pillanatban egy üres adatbázist tölt fel a célgépre.
Ezért van egy szabály, amit azóta kivétel nélkül betartok: a dump épségét mindig ellenőrizni kell, mielőtt bármit felülírnék vele. Két dolgot nézek: szerepel-e a fájl végén a befejezést jelző sor, és annyi tábla-létrehozó utasítás van-e benne, ahány tábla az élő adatbázisban. A fájlméret önmagában semmit nem bizonyít.
Négy — a rendezési szabály, amit a régebbi kiszolgáló nem ismer
Az utolsó a legártalmatlanabb, mert legalább hangosan elszáll. Az újabb MySQL-verziók alapértelmezett rendezési szabálya nem létezik a régebbi kiszolgálókon és a MariaDB több változatában. Ha a fejlesztői gép újabb, mint a célkiszolgáló, az importálás elszáll egy ismeretlen collationre panaszkodva.
A megoldás a dumpban lecserélni a rendezési szabályt egy régebb óta létező, széles körben támogatott változatra. Érdemes ezt a folyamat részévé tenni, nem eseti javításként kezelni: a fejlesztői környezet előbb-utóbb úgyis megelőzi a szervert.
Ami mind a négyből következik
Nem az a tanulság, hogy ezt a négyet meg kell jegyezni. Hanem az, hogy a deploy-szkriptet az első futtatás előtt kell teljesre megírni — az utólagos toldozgatás ugyanis pont ezeknél a néma hibáknál nem működik. Ha a hiba nem jelez, akkor nincs az a pillanat, amikor az ember rájön, hogy még hiányzik egy lépés.
A gyakorlati következmény: a szkript végén legyen fájlszintű összehasonlítás a két oldal között — tartalom és jogosultság —, és legyen füstteszt, ami a lapból kiszedett tényleges hivatkozásokat kéri le, nem kitalált fájlneveket. Az oldal HTTP 200-a nem bizonyíték; azt a törött kép is megadja.
Kérdések a témáról
Miért nem találja meg a wp search-replace az Elementor URL-jeit?
Mert az Elementor a szerkesztő adatait JSON-ként tárolja, és a JSON-ban a perjelek escape-elve szerepelnek. A keresett minta így nem a szokásos alakban van jelen, hanem escape-elt perjelekkel — a sima keresés emiatt nem talál rá. A megoldás ugyanazt a cserét lefuttatni az escape-elt alakra is.
Hogyan lehet, hogy egy fájl feltöltődött, mégsem jelenik meg?
Ha a jogosultsága nem engedi a webkiszolgálónak az olvasást. A tar megőrzi a helyi jogosultságokat, tehát egy szűkre állított helyi fájl a szerveren olvashatatlan marad. A fájl ott van, a tartalma helyes, az ellenőrző összeg egyezik — a látogató mégis törött képet lát.
Miért lesz nulla bájtos a wp db export?
Mert a parancs a mysqldump binárist hívja, és annak a kapcsolódási beállítása nem ugyanaz, mint a PHP-é. Ha az adatbázis socketen érhető el, a PHP oldali beállítás nem segít a külső programon: a dump üres fájllal, hibaüzenet nélkül fejeződik be.
Mi a legfontosabb ellenőrzés egy adatbázis-átvitel után?
A dump épsége, mielőtt bármit felülírnál vele: szerepel-e a végén a befejezést jelző sor, és annyi CREATE TABLE van-e benne, ahány tábla az élő adatbázisban. A fájlméret önmagában nem bizonyíték semmire.