A WordPress frissítésekről

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:

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.


A Szerzőről
Piller Balázs senior webfejlesztő, SEO specialista, és a WordPress szakértője. Számos sikeres projektben vett részt vezető fejlesztőként. Az általa írt kód jelenleg több mint 1 000 000 webhelyen fut.

Vélemény, hozzászólás?

Az e-mail-címet nem tesszük közzé. A kötelező mezőket * karakterrel jelöltük