Hogyan frissítsd a WordPress-t anélkül, hogy tönkretennéd az oldalad: 6 lépéses staging munkafolyamat

Meglátod a piros „Frissítés érhető el” jelvényt, és összeszorul a gyomrod. Ez jogos reakció: egy közvetlenül az élő oldaladra kényszerített frissítés valóban tönkretehet egy oldalt, a kapcsolatfelvételi űrlapodat vagy a fizetést — pontosan azon a napon, amikor egy ügyfél próbál rád találni. A legtöbb tulajdonos két dolog közül csinál egyet: vakon frissít és imádkozik, vagy hónapokig egyáltalán nem frissít, és nyitott sebezhetőségeken ül.

Van egy harmadik út, amelyet a komoly ügynökségek használnak: egy megismételhető folyamat, amely az összes kockázatot az oldalad egy másolatára helyezi át a valódi helyett. Nem bonyolult, és nem kell fejlesztőnek lenned. Ha egyszer beállítottad, a frissítés unalmas tízperces rutinná válik szerencsejáték helyett. Íme a pontos 6 lépés.

Miért tesznek tönkre az egyszerű frissítések valójában oldalakat

A WordPress-oldal olyan alkatrészek halmaza, amelyeknek össze kell illeszkedniük: a WordPress-mag, a sablonod és több tucat bővítmény, amelyeket mind különböző szerzők írtak. Ha csak az egyiket frissíted, előfordulhat, hogy újabb PHP-verziót követel, vagy csendben összeütközik egy régóta nem karbantartott bővítménnyel.

Egy leállt oldal leggyakoribb okai a következők:

• egy frissen frissített bővítmény összeütközik a sablonnal vagy egy másik bővítménnyel
• a frissítéshez olyan PHP-verzió kell, amelyet a tárhelyed nem futtat
• egy szerzője által elhagyott bővítmény már nem kompatibilis az új maggal
• valami elromlik a telepítés közben, és furcsa állapotban hagyja az adatbázist

Nem a te hibád, és nem azt jelenti, hogy kerülnöd kellene a frissítéseket. Csak azt jelenti, hogy nem az élő oldaladon akarod felfedezni az ütközést.

1. és 2. lépés: készíts teljes biztonsági mentést, majd indíts egy staging környezetet

Mindenekelőtt egy teljes biztonsági mentés: fájlok és adatbázis. A „teljes” a kulcsszó — egy kizárólag tartalmat mentő exportálás nem ment meg, ha a beállítások vagy a sablon elromlanak. Tárold a mentést az oldalon kívül (helyi letöltés vagy felhő), ne csak ugyanazon a szerveren.

Ezután indíts egy staging környezetet: az oldal azonos másolatát, külön címen, az ügyfelek számára láthatatlanul. Itt tesztelhetsz aggodalom nélkül. Szinte minden jó WordPress-tárhelyen van egy „Staging létrehozása” gomb a vezérlőpulton; ha a tiéden nincs, egy klónozó bővítmény vagy a megfelelő tárhely megoldja.

A staging a különbség „elrontottam egy másolatot” és „elrontottam az üzletet” között. Ne hagyd ki.

3. és 4. lépés: frissíts sorrendben, majd teszteld a pénzt hozó folyamatokat

A stagingen tudatosan frissíts, ne egyszerre mindent. Egy jól működő sorrend:

• először a WordPress-mag, ha van új verzió
• utána a sablon
• végül a bővítmények, lehetőleg egyesével (vagy kis csoportokban)

A kis lépésekben történő frissítés azt jelenti, hogy ha valami elromlik, azonnal tudod, ki a ludas. Nyomj rá a „mindent frissít” gombra, és omlik össze az oldal — utána már csak találgatsz.

Minden csoport után teszteld azokat a folyamatokat, amelyek ténylegesen pénzt hoznak, ne csak a kezdőlapot:

• a kapcsolatfelvételi űrlap — küldj egy tesztüzenetet, és győződj meg róla, hogy megérkezik
• a foglalás vagy a kosár és a fizetés, ha árulsz valamit
• a fontos oldalaidat mobilon, ne csak asztali gépen
• a sebesség, és hogy megjelenik-e bármilyen látható hiba

Ha a stagingen minden működik, nyugodtan léphetsz tovább.

5. és 6. lépés: publikálj az élő oldalra, és figyeld visszaállítási tervvel

Amikor a staging tiszta, vidd át a változtatást az éles oldalra. A legegyszerűbb, legbiztonságosabb mód, ha ugyanazokat a frissítéseket ugyanabban a sorrendben megismétled közvetlenül az élő oldalon — már tudod, hogy működik. Sok tárhely kínál „staging átküldése az élőbe” funkciót is, de légy óvatos: felülírhatja a közben létrejött rendeléseket vagy tartalmat, ezért ellenőrizd kétszer.

Válassz egy alacsony forgalmú időszakot (kora reggel, ne péntek délben), és ideális esetben néhány perc karbantartási mód.

A 6. lépés, amelyet az emberek elfelejtenek: a publikálás után figyelj. Töltsd újra a kulcsfontosságú oldalakat, teszteld újra az űrlapot, figyeld a hibákat. És mindig tartsd készenlétben a B tervet — az 1. lépésből származó biztonsági mentést. Ha valami félresikerül, visszaállítod a mentést, és az oldal visszatér a korábbi állapotába, ahelyett hogy nyomás alatt kellene javítanod.

Néhány szabály, amely a legtöbb bajtól megkímél

A folyamaton túl néhány szokás hozza meg a hosszú távú különbséget:

• Fusd át egy nagyobb frissítés changelogját, mielőtt alkalmazod — a komoly szerzők figyelmeztetnek, ha jelentős változás van.
• Ne tarts meg olyan bővítményeket, amelyekre már nincs szükséged. Minden extra bővítmény egy újabb alkatrész, ami elromolhat. Töröld a nem használtakat.
• Óvakodj az elhagyott bővítményektől, amelyeket régóta nem frissítettek; ezek a leggyakoribb forrásai mind a meghibásodásnak, mind a biztonsági kockázatnak.
• Soha ne hagyj egy üzleti oldalt automatikus biztonsági mentés nélkül, bármilyen ritkán is frissítesz.

Ha mindez soknak tűnik, az normális — pontosan ezért léteznek az ügynökségek. Az MPO Web Studiónál távolról dolgozunk az egész országban, és el tudjuk intézni helyetted a karbantartást és a frissítéseket, stagingdel és biztonsági mentésekkel, hogy soha többé ne feszülten nyisd meg a vezérlőpultot. Egyetlen WhatsApp-üzenet, és őszintén elmondjuk, mit jelent mindez, felfújt ígéretek nélkül.