Nemrégiben a WordPress Core CMS-t frissítették a 4.7-os verzióra, amely a “Vaughan” fantázianevet viseli, tisztelgés gyanánt a legendás jazz énekesnő, Sarah “Sassy” Vaughan előtt. A készítők ebben a verzióban egy teljesen új alapértelmezett témával, a 2017-el kedveskedtek nekünk, amely leginkább az üzleti oldalak felépítését célozza meg és szinte mindent testre szabhatunk benne. Ha éppen verzióváltás előtt állsz, vagy az a típusú ember vagy, aki retteg már a WordPress frissítésének gondolatától is, ez a cikk neked való.
Az írás azt a feladatot tűzte ki célul, hogy segítsen megérteni, mit is jelent a WordPress frissítés, hogyan viszonyul egymáshoz a pluginek és a témák frissítése, s legfőképpen, hogyan frissítsd WordPress oldaladat anélkül, hogy összeomlasztanád.
A WordPress Core frissítés hátteréről
A Nyitott Forráskódú WordPress projekt valószínűleg a legnagyobb és legkiterjedtebb nyitott forráskódú projektek egyike. A nyitott forráskódú projektek közül ez rendelkezik a legnagyobb nemzetközi szakembergárdával. Emberek ezrei működnek közre a kód írásában és a világ minden tájáról szerepelnek új közreműködők az új verziókban.
Némelyek csodálkoznak, miért frissítik a WordPres Core-t olyan gyakran. A valóságban ez a gyakoriság évente 3-4 alkalom. Minden ezen kívüli csiszolás azt jelenti, hogy a kódban történő javítások valódi értékkel bírnak. Az aktuális hibákat megoldják, javított kódokat implementálnak és fontos biztonsági frissítéseket alkalmaznak. Ha meglátod az új frissítés értesítést, akkor azt gondolhatod, hogy milyen remek, a világ minden tájáról származó fejlesztőktől kaptam megint ingyenes kódokat azért, hogy a weboldalam még jobbá tehessem.
A múltban előfordult, hogy ha frissítetted az oldaladat csak bajod származott belőle. Sok WordPress felhasználóval megtörtént. Nagy általánosságban azonban a múltban sem ez volt a tendencia, mert nem maga a WordPress projekt okozott problémákat, hanem a harmadik féltől származó bővítmények és témák.
Alapvetően elmondható, ha az oldaladat csakis a WordPress Core funkcióiból építed fel és a beépített WordPress témát használod, bármikor frissítheted anélkül, hogy bármiféle negatív következménye lenne.
A WordPress Core fejlesztők következetes módszertant követnek. Folyamatosan tesztelik a magot önmagával szemben. Ezt hívják “visszafelé való kompatibilitásnak” és ez az egyik legfontosabb WordPress funkció, amely különbözik minden más CMS-étől. A visszafelé való kompatibilitás azt biztosítja, hogy minden WordPress verziót úgy lehet frissíteni, hogy ne veszítse el lényeges funkcióit vagy tartalmát.
Ez más szavakkal annyit tesz, ha problémáid vannak a WordPress frissítéssel, az nem a Core miatt van, hanem sokkal inkább a harmadik féltől származó pluginek és/vagy témák miatt, amelyeket az oldaladon használsz.
Bontsuk ki még jobban. MI magunk is szoktunk bővítményeket írni és kedveljük a harmadik féltől származó plugineket és témákat, mivel a WordPress élményt még inkább teljessé teszik. Ha azt mondom, hogy a bővítmények és a témák okoznak problémát, akkor nem az összes pluginre és témára gondolok. Fontos megérteni, hogy nem lehet minden egyes plugint, amelyet hozzá akarsz adni az oldaladhoz, letesztelni a többi, az oldaladon már fent lévő pluginnel. Szó szerint lehetetlen kívánalom a fejlesztőktől, hogy minden egyes olyan bővítmény minden egyes funkcióját ismerjék, amelyet használni kívánsz. Azt mondom tehát, hogy az olyan pluginek és témák, amelyek mögött rendszeres támogatás áll és jól vannak megírva, semmiféle problémát nem okoznak. Például Bob Dunn, az ismert szakíró, saját oldalán írta le tapasztalatait. Több mint száz plugint frissített a WordPress 4.0-ás frissítéssel egyetemben. Nem futott bele hibába.
Most azt mondhatod magadnak: “De ki használ WordPress Core-t pluginek és témák nélkül?”
Igazad van. Senki nem tesz ilyet, akinek profi weboldala van. Munkatársaink weblapjain is vannak egyedi témák és bővítményeket is használnak. A kérdés akkor úgy hangzik, hogyan frissítsük eszközfüggetlenül WordPress oldalunkat tekintetbe véve azokat a plugineket és témákat, amelyekben megbízunk?
Az általunk előnyben részesített folyamat
Többféle megoldás létezik arra nézve, hogy biztonságosan frissítsük a WordPress-t. Amit mi előnyben részesítünk, a következő:
-Készíts mentést az adatbázisról és a wp-content mappáról,
-Deaktiváld a plugineket,
-Frissítsd a plugineket és a témákat,
-Frissítsd a WordPress Core-t,
-Aktiváld újra a bővítményeket egyenként és keress hibákat,
-Amikor az összes plugint újra aktiváltad (vagy úgy hagytad bizonyos hibák miatt), készen vagy mindennel.
Sajnos ez nem egy ideális módszer. Ha mindezt megcsinálod egy futásidőben lévő oldallal, az nagyon rondán fog kinézni egy darabig. A kérdés az, hogyan lehet ezt úgy kivitelezni, hogy az oldaladra futásidőben érkező látogatóknak ne legyen rossz élményük.
Az elkövetkezőkben bemutatunk négy általános haladó módszert weboldalad biztonságos frissítésére. Ha jól csinálod a pluginek és a témák soha nem okoznak többé problémát.
Az abszolút minimalista módszer
Ehhez a módszerhez a következő eszközök szükségesek:
-Menteni kell tudni az oldalt vagy a tárhelyszolgáltatón keresztül vagy egy olyan plugin kell hozzá mint a BackupBuddy,
-Rendelkezned kell vagy egy éles fejlesztői oldallal, amely a futó oldalad másolata vagy egy helyi fejlesztői környezettel mint a Desktop Server, a Pressmatic, xampp vagy más effélék.
Az alapkoncepció a következő: egyszerűen tedd fel az összes frissítést először a fejlesztői környezetedre és keress ott bármilyen hibát. Ezután, ha már tudod, hogy a témáid és a beépülő moduljaid mennyire támogatják az új WordPress verziót, ismételd meg az egész frissítési folyamatot az éles oldalon.
Ennek a módszernek az első lépése (virtuálisan az összes módszernek az első lépése), hogy létrehozz egy pontos másolatot az oldaladról vagy helyileg vagy egy futásidejű fejlesztői környezetben. Mi azt javasoljuk minden WordPress felhasználónak, hogy a Desktop Servert használva kezdjen el tanulni a fejlesztői környezetekről. Ez egy nagyszerű eszköz ahhoz, hogy az oldalon dolgozz vele akár egy helyi desktop PC-n akár laptopon és megtanuld, hogyan kell másolatot készíteni egy élő oldalról.
A legegyszerűbb módja, hogy másolatot készíts oldaladról a Desktop Servert használva, ha felteszed a “Duplicator” nevű plugint. A Duplicator pontosan azt teszi, ami a nevében van: megduplázza a weboldaladat. A WordPress telepítést egy ZIP archívumba tömöríti, beleértve az adatbázist is.
A Desktop Server rendkívül jól együttműködik a Duplicator ZIP archívumaival. Használd a Desktop Server “importálás” eszközét, hogy az oldaladat helyileg lemásold. A teljes leírást itt olvashatod el.
A másik lehetőség, amint már említettük, egy futásidejű fejlesztői oldal. A legtöbb felhasználó, akik az ilyen oldalakat előnyben részesítik, tipikusan oldaluk al-doménjeként installálják azokat, például így: fejlesztoi.pelda.com. A fent említett Duplicatornak itt is hasznát veheted, ha lemásolod az oldaladat egy aldoménre, már ha jártas vagy egy új MySQL adatbázis létrehozásában és ezen adatbázis kiimportálásában a Duplicator ZIP fájljából. Minden más esetben azt javasoljuk, hogy egyszerűen töltsd fel a teljes oldaladat FTP-n és használd a Migrate DB Pro eszközt az adatbázis importálására.
Ha az oldaladat lemásoltad vagy helyileg vagy egy aldoménre, futtasd a frissítéseket. Készíts feljegyzést minden lehetséges problémáról és az olyan bővítményekről, amelyeket nem lehet frissíteni, ezután pedig egyszerűen futtasd a frissítéseket az élő oldaladon.
Az abszolút minimalista módszer előnyei és hátrányai
Ezen módszer legnagyobb előnye, hogy nem kell meglegyen a tudásod és a képességed, hogy a fejlesztői környezetedet ráhúzd az élő oldaladra. Azért nevezzük ezt “abszolút minimalista módszernek”, mert olyan csekély számú lépést tartalmaz, amelyet bármelyik WordPress felhasználó meg tud tenni. Ez csak egy lépésre van az úgynevezett “cowboy kódolástól”, amely nem más, minthogy futásidőben kódolj az élő oldaladon, ahol bármilyen apró probléma is felmerül, akkor a látogatóid élőben fogják látni.
A módszer szerencsétlen hátulütője, hogy alapvetően kétszer végzed el a munkát. Habár, amikor második alkalommal frissítesz, már képes leszel egy kicsit gyorsabban csinálni, mert pontosan tudni fogod, melyek azok a pluginek, amelyeket nem tudsz frissíteni vagy más probléma merült fel a fejlesztői oldalon végzett frissítési folyamat során.
A másik hátulütője a folyamatnak, hogy habár az összes fájlt és az adatbázist is lemásoltad, a szerverkörnyezeted nem lesz pontosan azonos. Hogy egy példával érzékeltessük ezt: lehetséges, hogy a Desktop Server más PHP verziót használ, mint amit te, vagy HTTPS-t használsz az élő oldaladon, de ez már nem igaz az aldoménre. Ezek a részletek azt sugallhatják, hogy minden rendben van helyileg, de ha a frissítést az élő oldaladra alkalmazod, problémákba ütközöl, amelyeket nem tudsz megismételni a fejlesztői környezetedben.
Az egy kattintásos munka módszer
Ez a módszer csak azoknak a felhasználóknak elérhető, akinek a tárhelyszolgáltatója elérhetővé tette ezt a funkciót. Némely szolgáltatónak van egy kattintásos munka módszere, amelyet a menedzselt WordPress szolgáltatásnál tesz elérhetővé. Ez arról szól, hogy rákattinthatsz egy gombra, amelyen az a felirat áll, hogy “Nyomd meg a munkapéldányhoz”. Ha megteszed, akkor a szolgáltatód lemásolja a weboldaladat, beleértve az adatbázist is, egy egyedi munka másolatot tartalmazó URL-re.
Ha ez kész, minden frissítést felrakhatsz, amelyekre szükséged van. Ezután ahelyett hogy feljegyzéseket készítenél és újra meg kellene az egész folyamatot ismételned, használhatod azt az eszközt, amelyet úgy hívnak, hogy “Nyomj a munkapéldányra az élő oldalhoz”. Azoknak, akik nem akarnak vacakolni a helyi fejlesztői környezetekkel és adatbázisokat másolgatni, a futásidejű munkapéldány eszközök (live staging tools) olyanok mint valami mágikus aranypor a mennyekből.
Ennek a módszernek a legnagyobb előnye, hogy csak egyszer kell a frissítéseket alkalmaznod. Másodszor, semmit sem kell tudnod a migrációról. Ezek a dolgok szinte bármely felhasználónak értékesek lehetnek.
A módszernek azonban van hátránya is. A legnagyobb az, hogy nem támogatja a “verziókat”. Alapvetően, ahogyan a beépülő moduloknak is van verziószáma, úgy a weboldaladnak is van. Miért van ez így? Azért, hogy nyomon követhessék, ha valamilyen változást hajtanak végre és képesek legyenek visszacsinálni vagy éppen felfelé frissíteni mindenféle verzióra az oldalt. Ez egyérteleműen haladóbb témakör, de nem kevésbé fontos, mert nagyon jól nyomon követhető vele, ahogyan a WordPress fejlődik.
Ami átvezet bennünket az utolsó módszerhez.
A helyi fájloktól az ideiglenes tárolón át az élő rendszerig
Gondolj az általad megalkotott legkomplexebb weboldalra. Talán létrehoztál egy egyedi témát vagy nagyon összetett gyerek témát. Lehetséges, hogy rendelkezel egy egyedi funkciókkal felvértezett pluginnel, amely kiterjeszti a weblap és beépülő moduljaid funkcióit. Ilyen sok mozgásban lévő résszel, nagyon nehéz valóban jó áttekintést kapni mindazon dolgokról, amelyek megváltoznak, ha a WordPress frissítést futtatod.
Ezt a módszert úgy alkották meg, hogy minden olyasminek a szigorú ellenőrzését valósítsa meg, ami megváltozott az oldaladon. Beállítások széles köre létezik ehhez a módszerhez, amely olyan felhasználói menedzsment szkripteket tartalmaz, mint a Composer vagy a Git almodulok. A fejlesztők szeretnek “kreatívok” lenni ezen a helyen.
Röviden, ez magában foglalja egy olyan ideiglenes tároló használatát, mint a Github (vagy Bitbucket vagy Beeanstalk), hogy lekövethesd a kód változását azért, hogy legyen egy folyamatos pillanatképed weboldalad összes fájljáról. Ezután, ha minden – verziószám szerint is – rendben van, kiteheted élő munkapéldány oldalként, felülvizsgálatra. Jóváhagyás után kimehet élőben.
Az adatbázis változások tipikusan olyanok, amiket közvetlenül munkapéldányba tesznek ki, de verziószám szerint is lehetséges ez az ideiglenes tárolón keresztül (habár ezt sok fejlesztő feleslegesnek tartja). Erre a munkára a Navicat-et tudnánk ajánlani.
Ez az a módszer, amelyet a legtöbb profi fejlesztő használ, főleg nagy vállalati weboldalaknál vagy webáruházak esetén, ahol kitenni élőben egy hibáktól hemzsegő kódot, egyszerűen nem opció.
A módszer előnyei és hátrányai
A legnagyobb előnye, hogy a kódod felett részletes ellenőrzést biztosít. Ezzel az ellenőrzéssel akármit kitehetsz, legyen az kicsi vagy nagy változtatás. Ráadásul könnyedén vissza is csinálhatod a változtatásokat.
A negatív oldala viszont az, hogy gyakorlatilag haladó felhasználónak kell lenned, hogy meglegyen a megfelelő képzettséged és a szükséges háttérismereted ahhoz, hogy minden simán menjen. Magunk is tapasztaltuk több alkalommal is, hogy könnyedén meg lehet csúszni ezt a módszert alkalmazva.
Zárszó
A cikk lényege az volt, hogy feltárja: a WordPress frissítésére a harmadik féltől származó pluginek vagy témák jelentik a veszélyt, ezek miatt vannak nem működő oldalak. Ha frissíted a WordPress-t, azt ne az élő oldaladon tedd. Akár az egy klikkelős módszert, akár a munkapéldány módszert használod is, nagyon fontos, hogy jól csináld. Nem csak azért, hogy elkerüld a stresszt, hanem főként azért, hogy távol tartsd az oldaladra látogatókat azoktól a kellemetlen élményektől, amelyeket a helytelen frissítésből származó negatív hatások okoznának az élő weboldaladon.