WordPress-költöztetés új tárhelyre: ellenőrzött átállás lépésről lépésre

Környezeti követelmények

A PHP, adatbázis és szerverbeállítások eltérése rejtett kompatibilitási hibát okozhat. Hasonlítsd össze az új környezetet a használt sablon és bővítmények követelményeivel.

A környezet összehasonlításakor a PHP-verzión túl a szükséges kiterjesztések, adatbázis, szerverkorlátok és ütemezett futtatás is számíthat. A jelenlegi oldal sajátosságai alapján kérdezz rá a tárhely támogatására. Egy médiát feldolgozó vagy nagy katalógust kezelő rendszer más erőforrást igényelhet, mint egyszerű bemutatkozó honlap. A tesztmásolatot még a domain éles átirányítása előtt indítsd el, a bizalmas tartalmat védve. Az új környezet ne küldjön véletlen éles levelet vagy külső műveletet. A működési próba tartalmazza az adminisztrációt, képfeldolgozást és legfontosabb üzleti kapcsolatot. A tárhelyválasztás így a tényleges rendszer igényein alapul, nem csak egy általános csomagnéven vagy tárhelyméreten. A tesztmásolat hibamentesen elindul az új helyen.

Teljes másolat

A rejtett konfiguráció és feltöltési mappa kimaradhat a kézi másolásból. Kezeld együtt a szükséges fájlokat, adatbázist és hozzáférési beállításokat.

A teljes másolatba a rejtett konfiguráció és szükséges szerverbeállítás is beletartozhat. A fájlok és adatbázis egymáshoz tartozó állapotát kell átvinni, megfelelő jogosultságokkal. A feltöltési könyvtár, egyedi bővítmény és sablon különösen fontos, mert ezek nem feltétlenül állíthatók elő pusztán egy új WordPress telepítésből. Külső tárban tárolt média vagy szolgáltatói kulcs esetén a kapcsolatot is helyre kell állítani. A fájlmásolás eredményét ellenőrizd, ne csak a művelet végét. A képek, letölthető anyagok és adminfelületi szerkesztés mintavétele segít a hiányzó részek felismerésében. A régi tárhelyet addig tartsd meg visszaállítható állapotban, amíg az új rendszer bizonyítottan át nem vette a szükséges működést. A képek, letöltések és adminisztráció egyaránt működnek.

Címek és adatbázis

Kódolt vagy szerializált adatban a kézi szövegcsere hibát okozhat. Használj a WordPress-adatszerkezeteket értő eszközt a szükséges címcseréhez.

Az adatbázisban URL-ek olyan szerkezetben is szerepelhetnek, ahol a puszta szöveghossz megváltoztatása hibás adatot eredményez. A WordPress-költöztetést értő eszköz kezeli ezeket a formátumokat, de a művelet előtt így is kell mentés. A címcsere csak a szükséges részekre vonatkozzon, ne írjon át vakon minden hasonló karakterláncot. Ellenőrizd a médiaútvonalat, menüt, belső linket és szerkesztői beállítást. Ha a domain nem változik, lehet, hogy kisebb címcsere kell, mint fejlesztői aldomainről élesítéskor. A HTTPS és a kanonikus domainváltozat következetessége is számít. A próba végén ne maradjon vegyes régi és új hivatkozás, különösen képek vagy külső integrációk visszatérési címei között. A szerkesztői beállítások és hivatkozások nem sérülnek.

Domain és levelezés

A webes cél módosítása nem feltétlenül igényli a teljes levelezés átállítását. Dokumentáld a DNS-rekordok szerepét, és külön ellenőrizd a webet és leveleket.

A DNS-beállításokban a webes cél és levelezés külön rekordokhoz tartozhat. Ha a teljes zónát másolod vagy névszervert váltasz, az e-mail és egyéb ellenőrző rekord is érintett lehet. Előbb készíts leltárt a meglévő rekordok szerepéről. A webhelyhez tartozó tanúsítvány és domainváltozatok működését az új helyen is ellenőrizni kell. A kimenő levélküldés külön szolgáltatáson keresztül történhet, ezért a webhely elérhetősége nem bizonyítja automatikusan az üzenetek kézbesítését. Küldj tényleges próbaűrlapot és ellenőrizd a beérkezést. A váltás alatt a különböző gyorsítótárak miatt eltérő látogatók eltérő kiszolgálást láthatnak; erre az átállási tervnek fel kell készülnie, különösen aktív adatbevitel esetén. Az átállás után a bejövő és kimenő üzenetek is eljutnak.

Friss adatok

A másolás után tovább élő régi oldalon új tartalom vagy rendelés keletkezhet. Tervezd meg a végső adatszinkronizálást és szükség esetén a rövid szerkesztési szünetet.

A végső másolat időpontja üzleti döntés is. Ha a régi rendszer tovább fogad rendelést, miközben az új másolatot teszteled, a két adatállapot eltér. A végső szinkronizálás módját előre meg kell tervezni, nem utólag észrevenni a hiányzó megrendelést. Egy rövid írási vagy rendelési szünet indokolt lehet, de ezt a működéshez és ügyféltájékoztatáshoz kell igazítani. A kód és adat külön kezelése csökkentheti a fölösleges teljes másolást. A külső fizetési és számlázási állapotot is egyeztetni kell. A költöztetés végén mintával ellenőrizd a legutolsó tartalmat és rendelést. Az adatfolytonosság fontosabb, mint az, hogy a váltás technikailag hány percig tartott a fájlmásoló eszközben. Nem tűnik el a másolat készítése óta létrejött üzleti adat.

Utóellenőrzés

A gyorsítótárak miatt különböző látogatók átmenetileg eltérő környezetet érhetnek el. Figyeld a kiszolgálást, tanúsítványt, űrlapokat és naplókat, a régi rendszert pedig tartsd visszaállíthatónak.

Az utóellenőrzésnél nézd meg a tanúsítványt, átirányításokat, űrlapokat, ütemezett feladatokat és integrációs visszajelzéseket. A gyorsítótár ürítése után is ellenőrizd a friss állapotot, mert a korábbi másolat elrejthet hibát. A szervernapló és alkalmazásnapló segíthet a régi útvonalra vagy hiányzó fájlra mutató kérések megtalálásában. A régi környezet kivezetése előtt legyen bizonyított, hogy az új hely fogadja az aktuális forgalmat és adatot. A mentést, hozzáférési listát és tárhelyleírást frissítsd az új állapot szerint. A költözés akkor zárul le, amikor a működtetési folyamatok is az új helyhez igazodnak, nem pusztán akkor, amikor a böngészőben betöltődik az új szerveren lévő kezdőlap. Az új tárhelyen ellenőrzött, következetes működés látszik.

Szemléltető helyzet és gyakorlati munkalap

Szemléltető példa: egy aktív webáruházat új tárhelyre költöztetnek. Az előzetes másolaton a megjelenést és integrációkat ellenőrzik, majd az éles átálláskor rövid, megtervezett ablakban szinkronizálják az új rendeléseket. Az eredeti tárhelyet csak a sikeres ellenőrzések után vezetik ki.

Gyakori kérdések