Egy működő WordPress oldalon a sablon átírása vagy egy nagyobb bővítmény-frissítés mindig kockázat. A kérdés nem az, hogy hozzányúlj-e, hanem az, hogy hol nyúlj hozzá. Három hely jön szóba, az éles oldal, egy staging másolat a tárhelyen, és egy helyi példány a saját gépeden. A három nem egymás helyettesítője, mindegyik más feladatra való, és a legtöbb elvesztegetett óra abból származik, hogy valaki a rosszat választja.
Mikor éri meg a helyi másolat, és mikor elég a staging?
Helyi másolat akkor éri meg, ha a munka lényege a hibakeresés, tehát sokszor kell gyorsan újrapróbálni, visszalépni és naplót olvasni. Staging akkor elég, ha a munka lényege a bemutatás és a jóváhagyás, tehát valakinek meg kell néznie a kész állapotot egy olyan környezetben, ami az éleshez nagyon közel áll.
A gyakorlatban ez a három tipikus helyzet dönti el:
- Sablonmódosítás. Ha egyetlen szín vagy szövegrész változik, a gyerek-sablon és a staging bőven elég. Ha a sablon szerkezetébe nyúlsz (template fájlok, hook-ok, egyedi blokk), a helyi példány gyorsabb, mert nincs feltöltés-várakozás minden mentésnél.
- Bővítmény-frissítés próbája. Nagy verzióugrásnál, például egy webshop-motor fő verziójánál a helyi példány azért jobb, mert nyugodtan elronthatod. Fél perc alatt visszaállsz az előző állapotra, és senki nem látja.
- Hibakeresés. Fehér képernyő, végtelen átirányítás, végzetes PHP-hiba. Ez a helyi környezet igazi terepe, mert bekapcsolhatod a teljes hibanaplózást, lépésenkénti hibakeresőt köthetsz rá, és nem kell attól tartanod, hogy a látogató is látja a hibaüzenetet.
Szakmai feltételezés, hogy egy kisebb oldalon a munkák nagyobbik felére a staging elegendő, és a helyi környezet akkor hozza vissza a felépítésébe fektetett időt, ha rendszeresen fejlesztesz ugyanazon az oldalon. Egyszeri apró javításhoz felesleges nekiállni.
Mit kell tudnia a gépeden futó környezetnek?
Annyit, hogy a PHP-verzió, az adatbázis-motor és a webszerver nagyjából egyezzen az élessel. Nem az eszköz neve számít, hanem a verziószámok.
Hivatalosan igazolt, hogy a WordPress dokumentációja megadja az ajánlott futtatókörnyezetet, PHP és MySQL vagy MariaDB minimum- és ajánlott verzióval, HTTPS-sel együtt. Ezt érdemes kiindulásnak venni, de a te oldalad szempontjából mégsem ez a mérvadó, hanem az, amit a tárhelyed ténylegesen futtat. Ezt a WordPress adminban az Eszközök menü Oldal állapota fülén, az Információ lapon olvasod ki.
Ha a gépeden PHP 8.3 fut, az élesen pedig 7.4, akkor a helyi teszt szinte semmit nem mond arról, hogy élesben mi fog történni. Saját tapasztalat, hogy a bővítmény-frissítés utáni hibák jó része pontosan verzió-eltérésből jön, és ilyenkor a helyi környezet nemhogy segít, hanem félrevezet.
Eszközből több használható van, a Local, a DevKinsta, a Docker-alapú összeállítások vagy a klasszikus MAMP és XAMPP. A választás inkább ízlés kérdése. Ami tényleg számít, az a verzió-egyezés, és hogy a WP-CLI elérhető legyen benne, mert az adatbázis-műveleteket azzal fogod elvégezni.
Hogyan készíted el a másolatot lépésről lépésre?
Három dolgot kell átvinned, a fájlokat, az adatbázist és a beállításokat. A sorrend nem mindegy, mert rossz sorrendnél olyan oldal lesz a gépeden, ami még mindig az éles adatbázisra és az éles URL-ekre mutat.
- Mentés az éles oldalról. A
wp-contentmappa és az adatbázis kell. Parancssorból ez két lépés,wp db export eles.sql, majd a wp-content tömörítése. Ha nincs SSH-hozzáférésed, egy migrációs bővítmény vagy a tárhely saját mentése is megteszi. - Tiszta WordPress a gépeden. Telepíts üres WordPress-t a helyi környezetbe, lehetőleg ugyanazzal a verzióval, ami élesben fut. Erre jön rá a wp-content tartalma.
- Adatbázis betöltése.
wp db import eles.sql. Ezen a ponton a helyi oldal még az éles címeket tartalmazza, tehát ha megnyitod a böngészőben, átdob az éles oldalra. - URL-átírás. Erre való a
wp search-replace, mert a szerializált PHP-tömböket is helyesen kezeli. Kézi SQL-es kereséssel-cserével a szerializált mezők hossz-adata elromlik, és a widget- vagy oldalépítő-beállítások elszállnak.
Az URL-csere parancsa ennyi.
wp search-replace 'https://ugyfeloldal.hu' 'http://ugyfeloldal.test' --all-tables --precise --report-changes-only
Érdemes előbb --dry-run kapcsolóval megnézni, hány sort érintene. Ha nagyságrendekkel több találat jön, mint vártad, valószínűleg egy naplózó tábla is benne van, amit nyugodtan kihagyhatsz a cseréből. Ha a domain több alakban szerepel az adatbázisban (www-vel és anélkül, http és https változatban), mindegyiket külön kell lefuttatni.
Mit kell átállítanod, hogy a másolat ne szóljon ki a világba?
Mindent, ami pénzt mozgat, levelet küld vagy külső rendszerbe ír. A helyi példány az éles oldal összes kulcsát és hozzáférési tokenjét megörökli, és alapesetben boldogan használja is őket.
A minimum, amit a betöltés után azonnal el kell intézned:
- A
wp-config.php-ban aWP_DEBUGés aWP_DEBUG_LOGlegyen igaz, aWP_DEBUG_DISPLAYviszont hamis, így a hibák a naplófájlba kerülnek, nem az oldal tetejére. - Vágd el a levélküldést, vagy irányítsd át egy helyi elfogóra (Mailpit, MailHog). Enélkül a tesztrendelésed valódi visszaigazolót küldhet egy valódi vásárlónak.
- Kapcsold ki a fizetési átjárót, a foglalási rendszert, a CRM-szinkront, a hírlevél-integrációt és minden bővítményt, ami kifelé hív.
- Kapcsold ki a gyorsítótárazó és a biztonsági bővítményeket. Helyben nem adnak semmit, viszont önmagukban is okoznak hibát.
- Ha bármilyen alagutat nyitsz a géped felé (ngrok, Cloudflare Tunnel), a Beállítások alatt kapcsold be a keresőmotorok elleni tiltást.
Saját tapasztalat, hogy a legkellemetlenebb baleset nem a törölt adatbázis, hanem az elküldött levél. Adatbázist vissza lehet tölteni, egy kiment visszaigazolót nem lehet visszaszívni.
Mit nem lehet helyi környezetben hitelesen tesztelni?
Mindent, ami a hálózattól, a külső szolgáltatóktól vagy a valódi forgalomtól függ. A helyi példány a kódról mond igazat, a működési körülményekről nem.
- CDN és gyorsítótár-rétegek. A tárhely oldali cache, a fordított proxy és a CDN élesben komolyan átrendezi, mit lát a látogató. Helyben ezek nincsenek, tehát a gyorsítótár-ürítési hibák sem jönnek elő.
- Valós válaszidő. A gépeden nincs hálózati késleltetés, nincs osztott tárhely és nincs terhelés. Amit itt mérsz, az a saját géped teljesítménye.
- Fizetési átjáró. A legtöbb szolgáltató sandbox-ot kínál, de a valódi átirányítás, a 3D Secure lépés és a banki visszahívás csak nyilvános, HTTPS-en elérhető címen működik rendesen.
- E-mail kézbesítés. Az, hogy a levél elmegy, helyben sem derül ki igazán. Az pedig, hogy megérkezik-e a beérkezőbe, SPF, DKIM és DMARC kérdése, ami az éles domainhez tartozik.
- Keresőmotorok és AI-botok viselkedése. Az indexelés, a strukturált adat felismerése és a válaszmotorok forrásválasztása kizárólag a nyilvánosan elérhető oldalon értelmezhető.
- Adatbázis-méretből fakadó lassulás. Ha a helyi másolat csonkolt adatbázissal fut, a lassú lekérdezés egyszerűen nem mutatkozik meg.
Miért nem mérőeszköz a helyi másolat?
Mert a mérés tárgya nem a kód, hanem a felhasználói élmény, az pedig csak éles körülmények között keletkezik. A helyi példány a hibakeresés eszköze, ezt érdemes tudatosan elfogadni, és nem próbálni többet kihozni belőle.
Hivatalosan igazolt, hogy a Core Web Vitals mezős adata valódi felhasználók böngészőjéből származik, a Chrome felhasználói élmény jelentés gyűjti. Ilyen adat egy zárt, helyi címen futó oldalon elvileg sem keletkezik. A laborvizsgálat (Lighthouse) helyben lefut ugyan, de a kapott szám a géped sebességét és a hiányzó hálózatot tükrözi, nem az oldalét.
Ebből következik egy egyszerű munkamódszer. A helyi példányon eldöntöd, hogy a változtatás működik-e, az élesen pedig azt méred, hogy használ-e. A kettő összekeverése az a hiba, ami után valaki azt hiszi, gyorsított az oldalon, közben csak egy gyorsabb gépen nézte meg. A javítás segítheti a sebességet, de ezt csak az éles mérés mutatja meg, biztos eredményt előre semmi nem ígér.
Hogyan vezeted vissza a munkát az éles oldalra?
Úgy, hogy csak a saját munkádat viszed vissza, az adatokat nem. A leggyakoribb kár abból lesz, hogy valaki a teljes helyi adatbázist tölti fel élesre, és ezzel letörli a közben beérkezett rendeléseket, kommenteket, űrlapos érdeklődéseket.
- Készíts teljes mentést az éles oldalról (fájl és adatbázis), és győződj meg róla, hogy a mentés vissza is tölthető. A nem ellenőrzött mentés nem mentés.
- Válaszd szét, mi kód és mi adat. Sablonfájl, egyedi bővítmény, CSS, funkció kódja átvihető. Bejegyzés, rendelés, felhasználó, űrlapbeküldés nem.
- A kódot lehetőleg verziókövetéssel vidd vissza, ne kézi feltöltéssel. Így pontosan látod, mi változott, és van mihez visszalépni.
- Ha beállítást is át kell vinned (például egy új egyedi mezőcsoportot), inkább exportáld és importáld azt a részt, mint hogy az egész adatbázist mozgasd.
- Éles frissítés után ürítsd ki a gyorsítótárat minden rétegben, a bővítményben, a tárhelyen és a CDN-en is.
- Nézd végig azt a néhány oldalt, ami tényleg pénzt hoz, a nyitóoldalt, a kapcsolati űrlapot, a kosarat és a pénztárat, mobilon és asztali gépen is.
- Küldj egy valódi tesztüzenetet az űrlapról, és nézd meg, megérkezik-e. Webshopnál egy kis összegű valódi tranzakció a legbiztosabb próba, utána visszavonva.
- Nyisd meg a hibanaplót és a Site Health oldalt, majd nézz rá a keresőkonzolra a következő napokban, nem jött-e új lefedettségi hiba.
- Írd le egy mondatban, mi változott és mikor. Ha egy hét múlva furcsaság jön elő, ez a mondat spórolja meg a legtöbb időt.
Milyen hibák viszik el a legtöbb időt?
Négy visszatérő van. Az első az elfelejtett URL-átírás a szerializált mezőkben, aminek a tünete az, hogy az oldalépítővel szerkesztett aloldalak üresen jönnek be. A második a verzió-eltérés, amitől a helyi teszt hamis biztonságot ad. A harmadik az éles adatbázis visszatöltése a helyi fölé, ami adatvesztéssel jár. A negyedik a fájljogosultságok és a wp-content/uploads mappa kihagyása, amitől a képek helyén törött hivatkozás marad.
Mindegyik ellen ugyanaz véd. Mentés a művelet előtt, egy rövid ellenőrzőlista a művelet után, és az a szabály, hogy adat mindig az élestől a helyi felé mozog, kód pedig a helyitől az éles felé.
Források és további olvasnivalók
- WordPress.org, Requirements (ajánlott futtatókörnyezet)
- WordPress Developer Resources, Debugging in WordPress
- WP-CLI Handbook (db, search-replace parancsok)
- Google Search Central dokumentáció (indexelés, strukturált adat)
- Chrome UX Report dokumentáció (Core Web Vitals mezős adat)
- web.dev, Core Web Vitals
- MDN Web Docs (HTTP, HTTPS alapok)
- PHP Manual (verziók közti változások, migrációs útmutatók)
- Helyi példány akkor éri meg, ha sokszor kell újrapróbálni és visszalépni, staging akkor elég, ha valaki csak megnézi a kész állapotot.
- Az URL-átírást szerializált adatot is kezelő eszközzel (WP-CLI search-replace) végezd, kézi SQL-cserével az oldalépítő-beállítások elromolhatnak.
- A helyi másolaton azonnal vágd el a levélküldést, a fizetési átjárót és minden külső integrációt, mert az éles kulcsokat megörökli.
- CDN, valós válaszidő, fizetési átjáró és levélkézbesítés helyben nem tesztelhető hitelesen.
- Az élesre visszavezetés mindig mentéssel kezdődik és nem a fájlmásolással ér véget, hanem az utólagos ellenőrzéssel.
Gyakori kérdések
Elég a staging, vagy tényleg kell helyi környezet?
Ha csak megnézni és jóváhagyni kell egy kész állapotot, a staging elég. Ha sokszor kell próbálkozni, visszalépni és hibanaplót olvasni, a helyi példány gyorsabb, mert nincs feltöltés-várakozás és bármit elronthatsz következmény nélkül.
Miért nem cserélhetem le az URL-eket egyszerű SQL-parancsból?
Mert a WordPress sok beállítást szerializált PHP-tömbként tárol, amiben benne van a szöveg hossza is. Egy sima SQL-es csere a hosszat nem írja át, így az adat olvashatatlanná válik. A WP-CLI search-replace ezt helyesen kezeli.
Visszatölthetem a helyi adatbázist az éles oldalra?
Általában nem érdemes. Amíg helyben dolgoztál, élesben érkezhettek rendelések, kommentek, űrlapbeküldések, és ezeket felülírnád. Kódot vigyél vissza, adatot ne, a szükséges beállításokat pedig célzott exporttal és importtal mozgasd.
Mérhetem a helyi példányon az oldal sebességét?
Laborvizsgálatot futtathatsz rajta, de a kapott szám a géped teljesítményét mutatja, nem az oldalét. Hálózat, tárhely, CDN és valódi forgalom nélkül a mérés nem hasonlítható az éleshez. A sebesség megítélése éles mérést kíván.
Mire kell figyelni, ha webshop másolatán dolgozom?
A legfontosabb a levélküldés és a fizetési átjáró elvágása, mert a másolat az éles kulcsokat örökli. Emellett a készlet- és számlázási integrációkat is kapcsold ki, különben egy teszt-tranzakció valódi rendszerbe ír.
Mennyire kell egyeznie a PHP-verziónak az élessel?
A fő verziónak mindenképpen. PHP 7-es és PHP 8-as ág között annyi eltérés van, hogy egy helyben hibátlanul futó bővítmény élesen végzetes hibát dobhat, és fordítva. A tárhelyen futó verziót a Site Health Információ lapján nézheted meg.
Források és további olvasnivalók
Ezen az oldalon a hivatalosan igazolt információt elsődleges forrásokból építjük fel; a saját tapasztalatot és a szakmai becslést mindig külön jelöljük a szövegben.