Egy WordPress weboldalnál fontos, hogy a telepített bővítmények és sablonok, és maga a WordPress rendszer is mindig naprakész legyen. Frissíteni általában még akkor is szükséges, ha a weboldal “készen van”, és nem tervezünk több módosítást rajta.
Miért kell frissíteni a WordPress oldalakat?
A WordPress rendszerét folyamatosan fejlesztik, sosincs vége a munkának: bugokat, sérülékenységeket, kompatibilitási problémákat javítanak az új verziók, és persze fejlesztenek a teljesítményen és új funkciókat is hozzáadnak. A kereskedelmi céllal készült bővítményekkel és sablonokkal általában ugyanez a helyzet. Ha biztonságban akarjuk tudni a webhelyet, akkor frissíteni kell.
Fontos megemlíteni, hogy az inaktív sablonokban és bővítményekben is lehetnek sérülékenységek. Ha egy plugint már biztosan nem fogunk használni, akkor azt jobb, ha töröljük – a többi pedig mindig legyen frissítve. A sablonokból csak az éppen aktívat érdemes megtartani, plusz egy alap-sablont (pl. Twenty Twenty-t) az esetleges hibák elhárításához.
A WordPress verziószámai
A WordPress verziószámában az első két szám jelzi a főverziót (pl. 5.0, 5.1), a harmadik pedig az alverziót. Az alverziók csak javításokat tartalmaznak, nincs új funkció bennük és nem törölnek semmit, tehát egy adott WP verzióval elvileg mindig kompatibilisek (pl. 5.1-ről 5.1.1-re vagy 5.1.2-re frissítés esetén nem kell számítani hibára).
WP főverzió általában 4-5 havonta jelenik meg, alverzió pedig amikor szükség van rá.
A WP verziószámoknál az első számnak nincs különösebb jelentősége: a 4.9 ugyanolyan főverzió, mint az 5.0.
A sablonok és bővítmények verziószámozása viszont nem követi a WordPress rendszerét, lényegében minden fejlesztő úgy frissíti a kiegészítőit és úgy számozza a verziókat, ahogy akarja.
Automatikus frissítések
Alapból a WP úgy van beállítva, hogy az alverziókra magától frissül, szóval ha telepítjük az 5.5-öt, akkor utána az 5.5.1, 5.5.2, stb. alverziókat automatikusan telepíteni fogja, amikor azok megjelennek. Külön kóddal be lehet állítani, hogy a főverzióra is frissüljön, vagy akár ki is lehet kapcsolni az összes automatikus frissítést.
A WordPress 5.5-ös verziója óta a sablonoknál és bővítményeknél is felajánlja az automatikus frissítés lehetőségét: külön-külön lehet bekapcsolni mindegyik kiegészítőhőz, és akkor azok azonnal frissítve lesznek, amint megjelenik egy új verzió. Ez alapvetően jó dolog, de vannak kockázatai.
A WordPress frissítések veszélyei
Mivel egy frissítés (legyen az sablon-, bővítmény-, vagy WP-frissítés) könnyen okozhat váratlan hibákat, ezért mindig érdemes egy teljes biztonsági mentést készíteni a frissítések előtt. Vannak olyan backup pluginok, amik ezt képesek elvégezni maguktól az automatikus frissítések előtt (pl. UpdraftPlus).
A frissítés után előjövő hibák sokfélék lehetnek. Például: egy nem működő funkció, egy visszatérő hibaüzenet a weboldalon vagy a hibanaplóban, de egy fatális hiba esetén a teljes weboldal is elérhetetlenné válhat, beleértve az admin felületet. Ilyenkor két lehetőségünk van:
- Visszaállítjuk a biztonsági mentést.
- Megkeressük és javítjuk vagy javíttatjuk a hibákat.
Minden esetben érdemes felkeresni a bővítmény fejlesztőjét, tudatni őt a hibáról. Ha látunk hibaüzenet, akkor azt is osszuk meg. A fejlesztő ajánlhat egy megoldást, vagy javíthatja a hibát egy frissítésben – legrosszabb esetben az üzenetünket ignorálják, de egy próbát megér.
“Kényszerített” biztonsági frissítések
Bizonyos esetekben, pl. ha egy népszerű pluginban súlyos sérülékenységet fedeznek fel, a wordpress.org csapata úgynevezett “kényszerített frissítést” is ki tud küldeni, ami akkor is települni fog, ha az adott kiegészítőnél nincs bekapcsolva az auto-update opció. Külön kóddal ezt is ki lehet kapcsolni, de a felhasználói felületen nincs hozzá semmilyen beállítás.
Ha a wp.org frissítéseket kezelő rendszerét sikerül feltörnie egy támadónak, akkor a web egyharmadának az irányítása a kezében van.
Ezt a funkciót 2014-es bevezetése óta kb. egy tucatszor használták, és időnként vita tárgyát képezi: szabad-e, kell-e a felhasználó beleegyezése nélkül is akár megvédeni a webhelyet a frissen talált sérülékenységtől? Valamint: nem túl nagy felelősség-e ez a wp.org csapatának? Mert ha a frissítések kezelőrendszerét sikerül feltörnie egy támadónak, akkor utána lényegében a web egyharmadának az irányítása a kezében van.
WordPress managed hosting szolgáltatások
Bizonyos tárhelyszolgáltatóknál lehetőség van managed (kezelt) WordPress szolgáltatást vásárolni: ez azt jelenti, hogy a rendszer technikai részével nekünk nem kell foglalkoznunk, a frissítéseket, hibajavításokat, biztonsági mentéseket elvégzik helyettünk, sőt, akár a betöltési sebesség optimalizálását is. Ezek a szolgáltatások lényegesen drágábbak egy “sima” tárhelyszolgáltatásnál, és néha korlátozásokkal is járnak (pl. bizonyos bővítmények kizárása).
Egy pár példa a managed hosting szolgáltatást kínáló cégek közül:
WordPress site manager szolgáltatások
Ha már több WordPress oldalt is kezelünk, érdemes utánanézni a WordPress site-kezelő alkalmazásoknak. Ezekkel egy központi felületen lehet felügyelni és kezelni több WordPress oldalt, és sok más funkció mellett a frissítések is egyszerűen és gyorsan megoldhatók, akár automatikus backup készítéssel együtt.
A WordPress site-kezelő rendszerek közül ezek a legnépszerűbbek:
WordPress statikus HTML generátorok
Egyetlen esetben nem szükséges többet frissíteni az oldalt: ha egy ehhez szükséges eszközzel statikus HTML-t generálunk belőle, és lecseréljük a WordPress-t a statikus fájlokra. Erre többféle megoldás is létezik, pluginok, appok és szolgáltatások vannak erre szakosodva. Például:
- Shifter
- FLATsite
- Simply Static plugin
- WP2Static plugin
Ennek a megoldásnak a fő előnyei a sebesség és a biztonság, valamint az ezekkel járó megbízhatóság és alacsony karbantartási költségek. A HTML oldalakat közvetlenül kiszolgálhatja a szerver, nem kell a WordPress-re várni, hogy legenerálja azokat (megjegyzés: egy cache plugin is képes ugyanerre), és a HTML oldalakat “meghekkelni” sem lehet.
A statikus HTML site-nak viszont több hátránya is van: egyrészt elveszíthetjük a tartalomkezelő rendszer fő funkcióit (többek közt a tartalom egyszerű kezelésének a lehetőségét), másrészt pedig, ezt csak egy sima statikus weboldallal lehet megoldani (pl. egy bemutatkozó oldal, aloldalakkal), semmilyen szerver-oldali számítást igénylő feladatra nem képes a statikus HTML oldal: nem lehet rajta komment-szekció, webshop, felhasználókezelés, de még egy üzenetküldő űrlap sem. Utólag, JavaScriptes trükkökkel és szolgáltatásokkal némelyik feladat ezek közül megoldható, de általában nem olyan minőségben, mint egy rendes szerver-oldali programmal.
WordPress Frissítések GYIK
Hogyan kell kikapcsolni a WordPress automatikus frissítéseit?
Ha minden automatikus frissítést ki akarunk kapcsolni, akkor telepítsük a Disable All WordPress Updates bővítményt, vagy csak adjuk hozzá ezt a kódot a wp-config.php fájlhoz: define( 'AUTOMATIC_UPDATER_DISABLED', true );
Mit frissítsünk először? A sablont, a bővítményeket, vagy a WordPress alapot?
Hogy elkerüljük a hibákat, ilyen sorrendben érdemes elvégezni a frissítést:
1. Sablon(ok)
2. Bővítmények
3. WordPress alap
Mi a teendő, ha nem sikerült frissíteni egy WordPress sablont vagy bővítményt?
Ha a wp-admin felületéről valamiért nem tudjuk frissíteni valamelyik kiegészítőt, akkor frissítsük manuálisan: töltsük le a sablon vagy plugin zip fájlját, csomagoljuk ki, majd a benne lévő mappát töltsük fel FTP-vel a /wp-content/themes/ vagy /wp-content/plugins/ mappába.
Mi a teendő, ha a WordPress frissítés után hibát tapasztalunk?
Ha látunk hibaüzenetet, akkor azt jegyezzük fel, majd állítsuk vissza biztonsági másolatot (ha készítettünk frissítés előtt). Ha nincs másolatunk, akkor kapcsoljuk ki a hibát okozó kiegészítőt. A WP Rollback plugin segítségével visszaállíthatjuk a kiegészítő előző verzióját, ha az elérhető a wp.org tárhelyén. Juttassuk el a hibaüzenetet és/vagy a hiba leírását a kiegészítő fejlesztőjének, aki felajánlhat egy megoldást, vagy javíthatja a hibát egy frissítésben.
Mi a teendő, ha a WordPress frissítés után nem elérhető a wp-admin?
Kapcsoljuk ki az utoljára frissített sablont vagy bővítményt manuálisan: egy FTP kliens segítségével nevezzük át a mappáját, ami megtalálható a /wp-content/themes/ vagy /wp-content/plugins/ könyvtárban.
