A WordPress-karbantartás akkor tekinthető befejezettnek, ha a frissítés után a weboldal fontos funkciói is működnek, és szükség esetén visszaállítható a korábbi állapot. Ehhez a frissítés előtt mentésre, kipróbált tesztkörnyezetre és rövid ellenőrzési listára van szükség. A főoldal megnyitása önmagában nem igazolja, hogy az ajánlatkérő űrlap, a mobilmenü és a háttérfolyamatok is rendben maradtak.
Egy céges oldalon könnyen észrevétlen marad, ha a frissítés után nem jut el az érdeklődő üzenete a megfelelő címzetthez. A látogató esetleg sikeres beküldést lát, a vállalkozás mégsem tud reagálni. Ezért a karbantartás ellenőrzése abból induljon ki, hogy mire használod az oldalt, és melyik működési hiba okozna tényleges üzleti problémát.
Először rögzítsd, mi működik a frissítés előtt
Készíts rövid listát a WordPress, a sablon és a fontos bővítmények jelenlegi változatáról. Jegyezd fel az egyedi fejlesztéseket, a licenchez kötött kiegészítőket és a külső kapcsolatokat is. Egy lejárt licenc például akadályozhatja egy fontos kiegészítő frissítését; ezt jobb a munka megkezdése előtt felismerni.
A kiadási megjegyzésekből derüljön ki, milyen változás készül, érint-e adatbázist vagy megváltozott követelményt. A használt termékek aktuális dokumentációja alapján ellenőrizd, hogy a tárhely PHP-verziója megfelelő-e, és rendelkezésre állnak-e a működéshez szükséges további bővítmények. Az, hogy két kiegészítő külön-külön naprakész, még nem bizonyítja, hogy az adott összeállítás együtt is működik.
Rögzíts néhány kiinduló állapotot: egy fontos szolgáltatásoldal asztali és mobilnézetét, az űrlap visszajelzését és egy szerkesztési próbát. A már korábban is meglévő hibákat különítsd el az új jelenségektől. Így egy régi tördelési gond nem válik tévesen a frissítés következményévé.
A mentés mellé visszaállítási terv is kell
A WordPress hivatalos frissítési útmutatója is mentést javasol a művelet előtt. A teljes visszaállításhoz a fájlok és az adatbázis összeillő példánya szükséges: a bejegyzések és beállítások nem ugyanott találhatók, mint a feltöltött képek vagy a bővítményfájlok. Ezt az adatbázismentés dokumentációja külön is tisztázza.
Ne elégedj meg egy zöld „mentés kész” felirattal. Tudd, hol van a mentés, ki fér hozzá, mi tartozik bele, és mikor készült. Ha az adminfelület sem tölt be, legyen ismert alternatív visszaállítási mód, például a tárhelyszolgáltató erre szolgáló felülete vagy a karbantartó hozzáférése.
A visszaállításnak adatvesztési kockázata is lehet. Ha a mentés óta új űrlapbeküldések, foglalások vagy rendelések érkeztek, egy teljes adatbázis-visszatöltés ezeket felülírhatja. Előre döntsd el, hogyan szünetelteted az új beküldések, foglalások vagy rendelések fogadását, vagy hogyan őrzöd meg a közben keletkező adatokat, és ki mondhatja ki, hogy a javítás helyett visszaállítás szükséges.
A tesztmásolat az éles oldal működését kövesse
A staging, vagyis tesztkörnyezet az oldal elkülönített másolata. Itt próbálható ki a frissítés úgy, hogy a látogatók még a működő oldalt használják. A másolat akkor ad hasznos visszajelzést, ha a fontos tárhelybeállítások, bővítmények és egyedi kódok érdemben megegyeznek az élessel.
A tesztkörnyezet hozzáférését korlátozd, és gondoskodj arról, hogy ne jelenjen meg keresési találatként. A másolt ügyféladatok kezelését is tervezd meg. A levélküldést, számlázást, fizetést és más külső műveleteket tesztüzemre kell állítani vagy megfelelően le kell választani, nehogy a próba valódi értesítést vagy tranzakciót indítson.
Nem szükséges minden egyes apró módosításhoz bonyolult tesztprojekt, de egy sok bővítményből álló vagy üzletileg fontos oldalnál a kipróbálás értékes védőháló. A WordPress és az egyedi weboldal közötti választás során ezért a későbbi fenntartás módját is érdemes tisztázni.
Így legyen követhető maga a WordPress-frissítés
Válassz olyan időpontot, amikor a kisebb forgalom mellett elérhető a beavatkozásért felelős szakember. Egy péntek esti frissítés önmagában nem jó időzítés, ha a hibát hétfőig senki nem tudja kezelni. A biztonsági javítások sürgősségét ugyanakkor külön kell mérlegelni; ne várjanak automatikusan a következő kényelmes időpontra.
A tesztkörnyezetben kipróbált változtatásokat dokumentált sorrendben végezd el az éles oldalon. A frissítéssel egy időben ne válts indokolatlanul tárhelyet vagy sablont, és a tartalom szerkezetét se alakítsd át. Ha sok egymástól független módosítás történik egyszerre, egy hiba okának azonosítása nehezebb lesz.
- Jegyezd fel a munka kezdetét és a frissített összetevőket.
- Várd meg a folyamat végét, és kezeld a megjelenő adatbázis-frissítési felhívást a termék útmutatója szerint.
- Ellenőrizd, hogy nem maradt félbehagyott művelet vagy karbantartási állapot.
- Az érintett gyorsítótárak frissítése után nézd meg a nyilvános eredményt is.
Frissítés után az érdeklődő útját teszteld végig
Nyisd meg az oldalt kijelentkezve, asztali és mobilnézetben. A bejelentkezett admin gyakran eltérő gyorsítótárazást vagy jogosultságot kap, így egy működő adminnézet mellett a látogatók még hibás oldalt láthatnak. Ellenőrizd a fejlécet, a mobilmenüt, a fő szolgáltatásoldalakat és az ajánlatkérő gombok célját.
Az űrlapnál vizsgáld meg a hiányos kitöltést és egy előre egyeztetett tesztbeküldést is. Ne csak a sikerüzenetet nézd: a fogadó oldalon is igazolni kell, hogy az üzenet vagy a rendszerben létrejövő rekord megérkezett. A tesztet jelöld egyértelműen, hogy ne számítson valódi megkeresésnek.
Próbáld ki a spamvédelmet és a kötelező mezőket is. A reCAPTCHA működéséről szóló útmutató segít megkülönböztetni a spamvédelem miatti elutasítást az űrlap egyéb hibáitól. A védelem akkor használható, ha a valódi érdeklődő értelmes visszajelzést kap, és szükség esetén javíthatja a kitöltést.
A szerkesztőben ments egy jelentéktelen próbaváltoztatást a tesztkörnyezetben, és ellenőrizd a fontos időzített feladatokat is. Webshopnál további vásárlási próba szükséges: a WooCommerce frissítési dokumentációja a kosár, pénztár, fizetés és értesítések ellenőrzését is kiemeli. Ezek tesztelését a külső rendszerek tesztmódjával kell összehangolni.
Hiba esetén először csökkentsd a fennakadást
Ha az ajánlatkérési útvonal használhatatlanná vált, először adj meg másik működő kapcsolatfelvételi lehetőséget, vagy jelezd egyértelműen, hogy az érintett funkció átmenetileg nem használható. Írd le, mikor, milyen eszközön és milyen lépésekkel jelentkezett a hiba. A „nem jó az oldal” helyett egy pontosan ismételhető eset gyorsabban vizsgálható.
A naplókat és a böngésző hibaüzeneteit a fejlesztő nézze át, érzékeny adatok közzététele nélkül. Egy nyilvános hibakiírás nem megfelelő hibakezelés. A korábbi bővítményfájl visszamásolása sem mindig elég, ha közben az adatbázis szerkezete is megváltozott; ilyenkor az összeillő állapot visszaállításáról kell dönteni.
Mit kérj a karbantartásról szóló átadásban?
Egy használható átadás tartalmazza a frissített összetevőket, a mentés időpontját, az ellenőrzött funkciókat és a megmaradt korlátokat. Legyen különbség a „főoldal megnyílt” és az „űrlapbeküldés a fogadó oldalon is ellenőrizve” állítás között. A rendszeres felügyelethez nevezd meg a felelőst és a következő ellenőrzés módját is.
Ha a jelenlegi oldalad frissítése kiszámíthatatlan, első lépésként egy rövid műszaki leltárt és funkciólistát érdemes készíteni. A KovaBuild weboldalkészítési és továbbfejlesztési szolgáltatásáról így már konkrét igények mentén egyeztethetünk: mit kell megőrizni, mit kell javítani, és hogyan igazolható az eredmény.