2013. március 9. 
[wordpress-video]
A minap a következő feladattal néztem szembe:
Adott volt egy WordPress 2.9.2-es rendszer, amelyen volt egy User Access Manager (klikkre eljuthatsz a róla készült 33 perces videóhoz) 0.9.1.3-es verziójával működtetett tagsági rendszer.
Feladat:
Mindkettőt frissíteni úgy, hogy tökéletesen működjön minden.
A feladat nem volt egyszerű, több okból sem:
- A WordPress már a 3.5.1-es (+23 verzió) verziónál jár, míg a tagsági rendszer már az 1.2.2-nél (+14 verzió). Ekkora verziókülönbségnél fokozottan kell figyelni a kompatibilitásra, hiszen korántsem garantált az, hogy ami 2-3 éve működött egy bizonyos párosításban, az most is működni fog.
- A tagsági rendszer nem állhatott le, legfőképpen nem omolhatott össze, mert az azt eredményezte volna, hogy tagság nélkül is meg tudták volna nézni a látogatók a zárt tartalmakat.
Melyek voltak a megoldáshoz vezető lépések?
- Teljes biztonsági mentés a weboldalról. Erre azért van szükség, hogyha bármi balul sülne el, vissza tudjuk állítani az eredeti verziót. Valamint a következő pont miatt is.
- A biztonsági mentésből egy tesztoldal létrehozása egy másik domain alatt, másik adatbázissal. Így elértük, hogy van egy – az eredetivel mindenben megegyező – tesztfelületünk, azaz bármilyen kockázat nélkül tudunk kísérletezni.
- Először a WordPress-t frissítettem 2.9.2-ről 3.5.1-re. Ez gond nélkül ment.
- Utána frissítettem a tagsági rendszert kiszolgáló bővítményt, ám itt beütött a krach: a tagsági rendszer leállt, minden tartalom nyilvánossá vált. Milyen jó, hogy nem az éles oldalon csináltam!
- Összehasonlítottam az eredeti weboldalhoz tartozó adatbázisban a tagsági rendszer tábláit, a teszt oldal azonos részeivel, és a következőt láttam: Nem ugyanolyan a táblaszerkezet a két helyen! Ezért az összeomlás. A régi beállításokat nem tudta kezelni a bővítmény a frissítés után, mivel azok már teljesen máshogy (kevesebb táblában is) tárolódtak az adatbázisban. Innentől lesz bonyolult a megoldás.
- Feltettem egy bővítményt, amely azt a célt szolgálja, hogy csak bejelentkezett felhasználók láthassák a weboldalt. Erre a tesztoldalon nem lett volna szükség, ám így ténylegesen tudtam szimulálni az eredeti oldalon szükséges lépéseket. Erre azért lesz szükség, hogy a tagsági rendszer kikapcsolása miatt “külsősök” ne férhessenek hozzá a védett tartalmakhoz. Így ideiglenesen csak a regisztrált tagok látják a tartalmakat, igaz ők jogkör nélkül mindent.
- Töröltem az összes, a bővítményhez tartozó táblát az adatbázisból.
- Töröltem magát a tagsági rendszeres bővítményt is.
- Újratelepítettem a bővítmény legfrissebb verzióját.
- Újra létrehoztam a különféle jogköröket, felhasználói csoportokat.
- A felhasználókat egyesével be kellett sorolni az őket megillető jogosultsági szintekbe.
- Mivel eredetileg úgy voltak kialakítva a jogkörök, hogy egy-egy kategóriába tartozó bejegyzések megtekintése volt egy-egy jogkör meglétéhez kötve, ezért ezeket a kategóriákat ismét össze kellett kötni a tagsági rendszerrel.
- Itt felmerült egy újabb gond: a kategóriáknál van egy alapértelmezett kategória, amelyet nem lehet törölni, csak átnevezni. Az egyik jogkör úgy volt kialakítva, hogy ehhez a kategóriához tartozó bejegyzéseket lehetett megtekinteni vele. Itt egy olyan érdekes hiba jött elő, hogyha beállítottam, hogy ezt a kategóriát csak azzal a bizonyos jogkörrel rendelkező felhasználók nézhetik meg, akkor az összes oldal is zárolva lett, holott ez nem volt célom. Ezt a problémát úgy hárítottam el, hogy ezt a kategóriát újra létrehoztam, majd ezt az újonnan létrehozott kategóriát soroltam be az egyik jogkör alá. Természetesen a régi kategóriából át kellett sorolni a tartalmakat az újonnan létrehozott alá.
- Miután minden működött, a fenti lépéseket el lehetett végezni az éles weboldalon is!
Tanulság: biztonsági mentés nélkül még egy bővítményt se frissíts!!!
Kategória: 
Címkék: 
Ha nem emlékszel rá, hogy mit, akkor tovább tart a hiba okának megkeresése. Bár azért nagyon sok esetben a hiba jellegéből, és a rutinomból kifolyólag gyorsan megtalálom a hibát.
