WooCommerce 11.1 és a PHP 7.4 vége: frissíts, mielőtt a webshop megáll

A WooCommerce 11.1 szeptember elején érkezett meg a webshopokba, a legfeltűnőbb újdonsága pedig az, hogy a termékváltozatokhoz (például egy pulóver színeihez) mostantól minden boltban saját képgaléria tartozhat, külön fizetős bővítmény nélkül. Néhány nappal később, 2026. szeptember 8-án a WooCommerce fejlesztői blogján megjelent egy javaslat is, amely a legtöbb magyar webshop tulajdonosának fontosabb lehet bármelyik új funkciónál: a 2027 januárjára tervezett 11.5-ös verziótól a WooCommerce legalább PHP 8.1-et követelne meg, így a PHP 7.4-en és 8.0-n futó boltok onnantól nem kapnák meg az újabb kiadásokat.

A cím szándékosan sarkos, ezért tegyük rögtön tisztába: januárban egyetlen webshop sem fog egyik pillanatról a másikra elsötétülni. A régi PHP-n ragadt bolt egyszerűen lemarad a frissítésekről, a valódi leállás pedig hónapokkal később, egy kapkodva elvégzett kényszerfrissítés közben szokott bekövetkezni, jellemzően éppen a legrosszabb pillanatban. Az alábbiakban 2026. szeptember 22-i állapot szerint sorra vesszük, mit hoz a WooCommerce 11.1, mit tartalmaz pontosan a PHP-javaslat, melyik PHP-verzióra érdemes váltani, hogyan tesztelj staging környezetben, mit kérdezz a tárhelyszolgáltatótól és nagyjából mennyibe kerül mindez egy kis- vagy középvállalkozásnak.

Röviden

• A WooCommerce 11.1 a fejlesztői blog 2026. szeptember 3-i kiadási jegyzete szerint minden boltban alapértelmezetten bekapcsolja a variációs képgalériát, amelyet nem lehet kikapcsolni, a korábbi fizetős Additional Variation Images bővítményt pedig automatikusan kikapcsolja.
• A WooCommerce csapata 2026. szeptember 8-án javasolta, hogy a 2027 januárjára tervezett 11.5-ös verziótól a minimális PHP-verzió 8.1 legyen, vagyis a PHP 7.4 és 8.0 támogatása megszűnjön; a döntés a visszajelzések után válik véglegessé.
• A PHP 7.4 a php.net szerint 2022. november 28. óta, a PHP 8.0 2023. november 26. óta nem kap biztonsági javítást, sőt a WooCommerce által javasolt új minimum, a PHP 8.1 is 2025. december 31-én kifutott.
• A 2026 őszén legésszerűbb célverzió a PHP 8.3 (biztonsági javítások 2027. december 31-ig) vagy a PHP 8.4 (2028. december 31-ig), a WooCommerce is legalább a PHP 8.3-at ajánlja.
• A váltást egy staging környezetben, vagyis az éles bolt zárt másolatán érdemes kipróbálni, teljes tesztvásárlással, számlázással és szállítási címkével együtt, még a 2026. november 27-i Black Friday előtt.
• Saját becslésünk szerint egy egyszerű webshop PHP-váltása 4 és 6 fejlesztői óra, egy évek óta gazdátlan, egyedi kódokkal teletűzdelt bolté viszont akár 25 és 50 óra között is lehet.

Mi újat hoz a WooCommerce 11.1?

A WooCommerce 11.1 legfontosabb újdonsága, hogy a variációs képgaléria minden boltban alapértelmezetten bekapcsol, így minden termékváltozathoz saját képsor tartozhat. Emellett érkezett egy alapból kikapcsolt elállási űrlap az uniós szabályhoz, egy béta állapotú videótámogatás a termékgalériában, valamint a fejlesztői blog szerint 30 és 42% közötti gyorsulás a Store API- és REST-kéréseknél.

A WooCommerce az Automattic által fejlesztett, nyílt forráskódú webshopbővítmény a WordPresshez, amely a termékkezeléstől a kosáron és a pénztáron át a rendeléskezelésig mindent a WordPress adminfelületére hoz. A 11.1-es kiadási jegyzet szerint ebben a verzióban 77 közreműködő 561 módosítása (pull requestje) került be, a kiadás visszafelé kompatibilis, a telepítés után viszont adatbázis-frissítést kér. Ez utóbbi a gyakorlatban egy értesítés az adminfelület tetején, amelyet nem érdemes napokig ott hagyni, mert a variációs galériák bekapcsolása is ezen keresztül történik.

Variációs képgaléria minden boltban

A variáció a WooCommerce-ben egy változó termék egy konkrét kombinációja, például egy vászontáska homokszínű, nagy méretű kivitele. Eddig minden variációhoz csak egyetlen kép tartozhatott, így ha valaki színenként több fotót akart mutatni (elölnézet, hátulnézet, részlet, modellen), akkor vagy a WooCommerce saját, fizetős Additional Variation Images bővítményét vette meg, vagy egy harmadik féltől származó galériabővítményt telepített. A funkció a 10.9-es verzióban kísérleti, kapcsolható lehetőségként már bekerült a WooCommerce magjába, a 11.1-től azonban mindenkinél él.

A WooCommerce fejlesztői blogjának 2026. szeptember 1-jei összefoglalója szerint a kísérleti kapcsoló megszűnt, a 11.1.0-1 jelű adatbázis-frissítés pedig azoknál a boltoknál is bekapcsolja a galériát, amelyek korábban tudatosan kikapcsolták. Kikapcsolási lehetőség nincs, de ettől senkinek nem kell megijednie: ha egy variációhoz nem töltesz fel galériát, a termékoldal ugyanúgy néz ki, mint korábban. A vásárló oldalán a LearnWoo 2026. szeptember 18-i útmutatója szerint úgy működik a dolog, hogy a variáció kiválasztásakor a teljes galéria átvált az adott változat saját képeire, a választás törlésekor pedig visszaáll a szülőtermék fotóira.

Hogy ez mennyit ér, azt egy képzeletbeli győri divatwebshop példáján könnyű belátni. Tegyük fel, hogy a bolt egy vászontáskát hat színben árul és színenként öt fotót szeretne mutatni. Korábban vagy egyetlen képet kapott minden szín, vagy a vásárlónak végig kellett görgetnie mind a harminc képet a közös galériában, hogy megtalálja a neki tetsző színt hátulról is. A variációs galériával a vásárló rákattint a mustársárgára és csak a mustársárga táska öt képét látja, ami kevesebb bizonytalanságot, jó eséllyel kevesebb „nem ilyen színre számítottam” visszaküldést jelent. A konverzióra gyakorolt hatásra nincs általános, független adat, ezt a saját boltodban érdemes mérni.

Elállási űrlap az uniós szabályhoz

A 11.1 egy csendesebb, de jogilag érdekes funkciót is hozott. Az Európai Unió 2023/2673-as irányelve a fogyasztói jogokról szóló irányelvet egy új, 11a. cikkel egészítette ki, amely az online kötött távollévő szerződéseknél elállási funkciót (a köznyelvben elállási gombot) ír elő, a Greenberg Traurig ügyvédi iroda 2026. májusi összefoglalója szerint 2026. június 19-i alkalmazási határidővel. A WooCommerce 11.1 Order Withdrawal nevű funkciója ehhez ad eszközt: bekapcsolás után a vásárló a fiókjában egy külön oldalon (alapértelmezés szerint a /my-account/withdraw-order címen) jelezheti, hogy eláll a rendeléstől.

A funkció alapból ki van kapcsolva, a WooCommerce.com összefoglalója szerint a WooCommerce > Settings > Advanced > Features menüpontban lehet bekapcsolni (magyar adminfelületen nagyjából a Beállítások, Haladó, Funkciók útvonalon), a címét pedig a Page Setup résznél lehet módosítani. Lényeges korlát, hogy a rendszer nem mondja le automatikusan a rendelést, nem módosítja az állapotát és nem indít visszatérítést, csak naplózza a kérést és értesíti a kereskedőt, a döntés és a pénz visszautalása tehát továbbra is kézi feladat. A funkció hasznos kiindulópont, de a megfelelőséget nem pótolja: az uniós szabály magyar átültetését, az ÁSZF szövegét és azt, hogy a vendégként vásárlók hogyan érik el a funkciót, érdemes jogásszal átnézetni.

Videó a galériában és a kevésbé látványos javítások

Béta állapotban megjelent a termékgalériába tölthető videó is, egyelőre csak a saját médiatárba feltöltött fájlokkal, szintén a Features menüpont alatt, Product gallery videos néven. Élesben futó boltnál ezt tesztkörnyezetben próbáld ki először, mert egy nagy videófájl a termékoldal betöltési idejét is megnövelheti.

A kiadási jegyzet szerint a csak virtuális termékeket tartalmazó rendeléseknél az admin összesítője már nem mutat felesleges szállítási címet, a blokkszerkesztő eszközei egységes csomagban töltődnek be, a rendelési tételek törlésének logikája pedig úgy változott, hogy a lecserélt tételek ne vesszenek el véletlenül. A legnagyobb számot a teljesítmény hozta: a Store API- és REST-kérések 30 és 42% közötti mértékben gyorsultak, mert a blokkok regisztrációja kimarad azoknál a kéréseknél, amelyek nem jelenítenek meg semmit. Ez főleg a blokkalapú kosár és pénztár, illetve a külső rendszerekkel (számlázóval, raktárkezelővel, ERP-vel) kommunikáló boltok számára jó hír.

Hogyan állítsd be a variációs képgalériát lépésről lépésre?

A variációs képgalériát a termék szerkesztőoldalán, a Termékadatok panel Variációk fülén töltheted fel, variációnként egy Variation gallery mezőben. A frissítés után a funkció magától él, neked csak a képeket kell hozzárendelni a változatokhoz, majd a boltban ellenőrizni, hogy a galéria váltása a sablonoddal is jól működik.

A LearnWoo 2026. szeptember 18-i útmutatója alapján a beállítás menete a következő (az angol felirat mellett zárójelben a magyar adminban várható megnevezés áll):

• Ellenőrizd a WooCommerce > Status (Állapot) oldalon, hogy a bolt legalább a 11.1.0-s verzión fut, illetve hogy az adatbázis-frissítés is lefutott.
• Nyisd meg szerkesztésre a változó terméket, majd görgess le a Product data (Termékadatok) panelhez.
• Kattints a Variations (Variációk) fülre, majd nyisd le azt a variációt, amelyhez galériát szeretnél, például a „mustársárga, nagy” kombinációt.
• A Variation gallery mező mellett kattints a Manage gombra, válaszd ki a képeket a médiatárból vagy tölts fel újakat.
• Húzással rendezd sorba a képeket, mert az első kép lesz a variáció fő képe mindenhol, ahol a változat megjelenik.
• Mentsd el a variációkat a Save changes (Változtatások mentése) gombbal, majd frissítsd a terméket is.
• Nyisd meg a termékoldalt a boltban, válaszd ki a variációt és nézd meg, átvált-e a galéria, végül töröld a választást és ellenőrizd, hogy visszaállnak-e a szülőtermék képei.

Néhány gyakorlati tanács sok munkát spórol meg. A méretvariációkhoz ritkán kell külön galéria, hiszen egy M-es és egy L-es pulóver fotón ugyanúgy néz ki, ezért elég a színekhez vagy mintákhoz képsort rendelni. A képek arányát pedig tartsd egységesen, mert ha az egyik szín fotói négyzetesek, a másiké álló formátumúak, a galéria váltáskor ugrálni fog, ami mobilon kifejezetten zavaró. Tömörítsd is a képeket feltöltés előtt, mert a sok új, tömörítetlen fotó a termékoldal betöltését is lassíthatja.

Mi lesz a régi galériabővítménnyel?

Ha eddig a WooCommerce saját, fizetős Additional Variation Images bővítményét használtad, a 11.1-re frissítéskor a rendszer automatikusan kikapcsolja, hogy ne ütközzön a maggal. A fejlesztői blog szerint az Action Scheduler (a WooCommerce háttérfeladat-ütemezője) egy feladatban átmásolja a régi galériaadatokat az új helyükre, a művelet nem írja felül a már kitöltött új mezőt, a régi adatok pedig megmaradnak a visszafelé kompatibilitás miatt. A lefutást a WooCommerce > Status > Scheduled Actions oldalon ellenőrizheted, a kivezetett bővítményt pedig ne kapcsold vissza.

Harmadik féltől származó galériabővítménynél más a helyzet. A LearnWoo összefoglalója szerint a mag csak a hivatalos bővítmény adatait migrálja, a többi bővítmény a saját adatmezőiben tárolta a képeket, ezért azok nem kerülnek át maguktól. A GetWooPlugins Additional Variation Images Gallery bővítménye az 1.3.33-as verziótól saját migrációs eszközt kínál, a RadiusTheme Variation Images Gallery bővítménye pedig a 2.4.5-ös verziótól automatikusan átköltözteti az adatokat. Ha a galériát a téma egyik beépített modulja kezelte, a LearnWoo azt javasolja, hogy kapcsold ki a témafunkciót és építsd újra a galériákat natívan. A nagyítást, a lightboxot vagy a csúszkát ezután is adhatja egy bővítmény, csak az adatok helye változik meg.

Mire figyeljen a fejlesztő?

Egyedi sablonnál vagy saját kódnál a fejlesztő feladata, hogy kivegye a régi, kísérleti funkciókapcsolóra épülő feltételeket, mert a 11.1 ezt a beállítást törli, így az arra hivatkozó kód váratlanul viselkedhet. A galériák a WC_Product_Variation::get_gallery_image_ids() metóduson és a REST API gallery_image_ids mezőjén keresztül érhetők el, ami a termékinformációs rendszerből (PIM) vagy ERP-ből tömegesen feltöltött katalógusoknál jó hír, mert a variációs képek is automatizáltan szinkronizálhatók. A klasszikus témák sablonfelülírásai a LearnWoo szerint továbbra is működnek, de ha a témád saját galériaszkriptet használ, a variáció kiválasztását és a visszaállítást külön teszteld.

Mikor szűnik meg a PHP 7.4 és 8.0 támogatása a WooCommerce-ben?

A WooCommerce fejlesztői blogján 2026. szeptember 8-án megjelent javaslat szerint a 2027 januárjára tervezett 11.5-ös verziótól a minimális PHP-verzió 8.1 lesz, így a PHP 7.4 és 8.0 támogatása ezzel a kiadással szűnik meg. Ez egyelőre javaslat, a csapat a visszajelzések és a használati adatok alapján erősíti meg a pontos céldátumot.

A PHP az a szerveroldali programozási nyelv, amelyen a WordPress, a WooCommerce és minden bővítményük fut, a tárhelyen beállított PHP-verzió tehát meghatározza, milyen kódot képes a szerver egyáltalán végrehajtani. A javaslatot Brian Coords tette közzé, az indoklása pedig egyszerű: a PHP 8.1-es minimum mellett a WooCommerce kódja végre használhatja a PHP 8 olyan nyelvi elemeit (például a union típusokat, az attribútumokat és a nullbiztos operátort), amelyekkel modernebb és biztonságosabb lehet, egyre több külső függőség eleve legalább PHP 8.1-et igényel, a régi verziókkal való kompatibilitás fenntartása pedig rengeteg tesztelési munkát és elavult kódot jelent. A javaslat azt is rögzíti, hogy a WooCommerce hivatalos ajánlása legalább PHP 8.3.

Hány boltot érint a változás?

A javaslat szerint a WooCommerce-hez önkéntesen adatot küldő boltok körülbelül 7%-a fut még PHP 7.4-en és körülbelül 2%-a PHP 8.0-n, a nemrég frissített telepítések között pedig az együttes arány 6% közelében van és folyamatosan csökken. Ezek önkéntes, reprezentatívnak tekintett minták, nem a teljes piac. A teljes WordPress-ökoszisztémában ennél rosszabb a kép: a WordPress core csapatának 2026. január 9-i közleménye szerint a monitorozott WordPress-oldalak 22,20%-a futott PHP 7.4-en és 5,69%-a PHP 8.0-n, vagyis az oldalak több mint negyede olyan PHP-n üzemelt, amely már évek óta nem kap biztonsági javítást.

Magyar webshopokra vonatkozó nyilvános statisztika nincs, tapasztalatunk szerint azonban a régebben indult, egyszer beállított és azóta „csak működő” boltok között gyakori, hogy a tárhely PHP-verzióját évek óta senki nem nézte meg. Ez a két adatsor közötti különbség lényege is: a rendszeresen karbantartott boltok jó eséllyel már újabb PHP-n vannak, a lemaradók pedig pont azok, amelyekkel senki nem foglalkozik, tehát ők fognak a januári változás után a legkésőbb értesülni arról, hogy valami nincs rendben.

Összefüggés a WordPress PHP-követelményeivel

A WooCommerce lépése nem előzmény nélküli. A WordPress 7.0 megjelenésével a WordPress minimális PHP-verziója 7.4.0 lett, a PHP 7.2-n és 7.3-on futó oldalak pedig a 6.9-es ágon maradtak, erről részletesebben a WordPress 7.1.1 biztonsági frissítéséről szóló cikkünkben írtunk. A WordPress továbbra is a PHP 8.3-at ajánlja, a WooCommerce tehát most egy lépéssel a WordPress előtt jár, ami egy webshopnál azt jelenti, hogy a PHP-verziót már nem a WordPress, hanem a WooCommerce igénye fogja meghatározni.

Mi történik a webshoppal, ha PHP 7.4-en marad?

A PHP 7.4-en maradó webshop 2027 januárjában nem áll le, de a javaslat szerint a WordPress nem fogja felajánlani neki a WooCommerce 11.5-öt, így a bolt a meglévő verzióján marad és csak annak az ágnak a javítókiadásait kapja meg. A valódi kockázat az, ami ezután jön: a bővítmények sorra elhagyják a régi PHP-t.

A javaslat úgy fogalmaz, hogy az érintett bolt tovább futtatja a meglévő WooCommerce-verzióját és megkapja az adott ág pontkiadásait. Hogy ezek meddig érkeznek, azt a szöveg nem részletezi, arra pedig nem érdemes építeni, hogy egy régi ág évekig kap majd javításokat. Közben a PHP 7.4 maga a php.net szerint 2022. november 28. óta nem kap semmilyen javítást, 2026 szeptemberében tehát nagyjából három év és tíz hónapja fut foltozatlanul, a PHP 8.0 pedig 2023. november 26. óta, közel három éve van ugyanebben a helyzetben.

A „megállás” forgatókönyve ritkán látványos, inkább lassú lemorzsolódás. Egy magyar webshop tipikusan tíz-harminc bővítményre támaszkodik: fizetési átjáróra (például Barion vagy SimplePay), számlázó-összekötőre (Számlázz.hu vagy Billingo), csomagpont-választóra (Foxpost, Packeta, GLS, MPL), hírlevél-szinkronra, szűrőre, SEO-bővítményre. Ezek fejlesztői a saját minimumkövetelményeiket sokszor a WooCommerce-éhez igazítják, így 2027 folyamán várhatóan egyre több frissítés nem fog települni a régi PHP-s boltokra. Ez addig nem fáj, amíg egy nap meg nem jelenik egy biztonsági javítás vagy egy kötelező változtatás (például egy fizetési szolgáltató API-váltása), amelyet a boltod már nem tud fogadni.

Ekkor jön a rossz döntés két lehetséges változata: vagy sérülékeny, elavult bővítménnyel üzemelsz tovább, vagy egy délután alatt próbálod meg átugrani a PHP 7.4-ről a 8.3-ra, közben a WooCommerce több főverzióját is, tesztelés nélkül. Ez utóbbi az a pont, ahol a bolt ténylegesen megáll: fehér képernyő, kritikus hibát jelző WordPress-üzenet, nem működő pénztár, mindez pedig jó eséllyel egy forgalmas héten, mert a kényszerhelyzetek ritkán jönnek jókor. Ugyanez a PHP-váltás nyugodt tempóban, staging környezetben, két hónap mozgástérrel egy jól tervezhető karbantartási feladat.

A biztonsági oldal

Egy támogatás nélküli PHP-verzió azt jelenti, hogy ha holnap kiderül egy hiba magában a PHP-ban, arra a php.net nem ad ki javítást. Egyes tárhelyszolgáltatók saját, visszaportolt biztonsági javításokkal még futtatják a régi verziókat, ez azonban átmeneti mankó, amely a bővítmények kompatibilitási gondjain semmit nem segít. Egy webshopnál ráadásul személyes adatok, szállítási címek, rendelési előzmények és sokszor jelszavak is ott vannak az adatbázisban, így egy feltört bolt nemcsak kiesett bevételt, hanem adatvédelmi incidenst, a GDPR szerinti bejelentési kötelezettséget és a vásárlói bizalom elvesztését is jelentheti.

Melyik PHP-verzióra érdemes váltani 2026 őszén?

2026 őszén a PHP 8.3 vagy a PHP 8.4 a legésszerűbb célverzió egy WooCommerce-webshopnak. A PHP 8.3 a php.net szerint 2027. december 31-ig, a 8.4 2028. december 31-ig kap biztonsági javításokat, így mindkettővel legalább egy teljes évre megoldod a kérdést, a WooCommerce hivatalos ajánlása is legalább a PHP 8.3.

A php.net hivatalos támogatási szabálya szerint minden PHP-ág a megjelenésétől számítva két évig aktív támogatást kap, ilyenkor a jelentett hibákat és a biztonsági problémákat is javítják, majd további két évig már csak a kritikus biztonsági hibákat. Ezután az ág eléri az élettartama végét (end of life), onnantól semmilyen javítás nem érkezik hozzá. Az alábbi táblázat a php.net támogatott verziókat és kifutott verziókat listázó oldalai alapján készült.

A táblázat legfurcsább sora a PHP 8.1: a WooCommerce által javasolt új minimum a php.net szerint már 2025. december 31-én kifutott, vagyis a 11.5 olyan verzión is futni fog, amely maga sem kap biztonsági javítást. Ebből az a tanulság, hogy a WooCommerce minimuma kompatibilitási alsó határ, nem ajánlott célállapot. Ha most PHP 7.4-ről a 8.1-re lépsz csak azért, hogy a januári frissítés átmenjen, akkor egy éven belül újra végig kell csinálnod ugyanezt a tesztelési kört, ezért egy lépésben érdemes a 8.3-ig vagy a 8.4-ig menni.

A 8.3 és a 8.4 közötti választás a bővítményeiden múlik. A PHP 8.3 már elég régóta kint van ahhoz, hogy a népszerű WooCommerce-bővítmények többsége jó eséllyel támogassa, ezért ez a biztonságosabb választás egy sok bővítménnyel futó boltnak. A PHP 8.4 egy évvel hosszabb támogatást ad, így ha a staging teszt hibátlan, nincs ok kihagyni. A 2025 novemberében megjelent PHP 8.5-öt egy webshop éles környezetében csak akkor érdemes választani, ha a bővítményeid fejlesztői kifejezetten jelzik a támogatását, a staging tesztek pedig szintén tiszták.

Így nézed meg, milyen PHP-n fut most a boltod

A WooCommerce adminfelületén a WooCommerce > Status (Állapot) > System status oldal Server environment (Szerverkörnyezet) blokkjában a PHP version sor megmutatja a jelenlegi verziót, ha pedig túl régi, a WooCommerce ezt jelzi is. Ugyanez a WordPress Eszközök > Webhely egészsége > Információ > Szerver részében is látszik, a Webhely egészsége oldal pedig figyelmeztet, ha a PHP-verzió elavult. A System status oldal alján érdemes megnézni a sablonfelülírások listáját is: ha a témád elavult WooCommerce-sablonokat tartalmaz, azt a rendszer külön megjelöli, ezek a sablonok pedig a PHP-váltás előtt amúgy is frissítésre szorulnak.

Milyen hibák jönnek elő leggyakrabban a PHP 8-ra váltáskor?

A PHP 8-ra váltáskor a hibák döntő része nem a WordPressből vagy a WooCommerce-ből, hanem régi bővítményekből, elavult témákból és a functions.php fájlba évekkel ezelőtt bemásolt egyedi kódrészletekből jön. A tipikus tünet a teljes leállást okozó végzetes hiba (fatal error) vagy a naplót elárasztó elavulási figyelmeztetések sora.

A PHP 7.4-ről a 8.x-re lépés azért nagyobb falat egy átlagos frissítésnél, mert a PHP 8.0 több, régóta elavultnak jelölt dolgot véglegesen kivett a nyelvből, sok korábban csak figyelmeztetést adó helyzetből pedig hibát csinált. A leggyakoribb problémák verziónként:

• PHP 8.0: eltűnt például a create_function() és az each() függvény, így az ezeket használó régi kód végzetes hibával áll le. A beépített függvények szigorúbban kezelik a rossz típusú paramétert, a szám és a szöveg összehasonlítása is másképp működik, ami egy régi árkalkulátorban vagy szűrőben rejtett logikai hibát okozhat.
• PHP 8.1: elavulási figyelmeztetést ad a rendszer, ha egy kód null értéket ad át olyan beépített függvénynek, amely szöveget vagy számot vár. Ez önmagában nem állítja le az oldalt, de a régi bővítmények tömegesen produkálják.
• PHP 8.2: elavulttá váltak a dinamikus tulajdonságok (amikor egy objektumra deklarálatlan tulajdonságot írnak), valamint a ${változó} formájú szövegbe ágyazás, továbbá az utf8_encode() és az utf8_decode() függvény. A régebbi bővítmények jelentős része legalább az egyiket használta.
• PHP 8.4: elavult lett az implicit módon nullázható paramétertípus, ami a régebbi kódbázisokban sok figyelmeztetést okoz, működési hibát ritkábban.

Az elavulási figyelmeztetés (deprecation notice) nem hiba, hanem előrejelzés: azt jelzi, hogy a kód ma még fut, de egy későbbi PHP-verzióban már nem fog. Éles webshopon ezek soha ne jelenjenek meg a látogatónak (a tárhelyen a hibák kijelzését ki kell kapcsolni), a naplóban viszont hasznosak, mert megmutatják, melyik bővítmény lesz a következő problémaforrás.

Vegyünk egy képzeletbeli szegedi cipőwebshopot, ahol egy szabadúszó fejlesztő 2019-ben írt egy egyedi szállításidíj-számítót a téma functions.php fájljába, a kód pedig a create_function() függvényt használja. PHP 7.4-en ez évek óta csendben működik, PHP 8.0 vagy újabb alatt viszont az első oldalbetöltéskor végzetes hibát okoz, amitől a teljes bolt elérhetetlenné válik. A WordPress ilyenkor helyreállítási módba vált és e-mailt küld az adminisztrátornak egy belépési linkkel, ami hasznos mentőöv, de éles boltban ezt a helyzetet nem az ügyfeleknek kellene felfedezniük. Stagingen ugyanez a hiba tíz perc alatt kiderül, a javítás pedig általában néhány sor átírása.

Tesztelés staging környezetben: mit nézz át?

A staging környezet az éles webshop pontos, a nyilvánosság elől elzárt másolata, ahol kockázat nélkül lehet PHP-t váltani, bővítményt frissíteni és vásárlást szimulálni. Egy WooCommerce-boltnál a teljes vásárlási folyamatot végig kell nézni rajta, a termékoldaltól a fizetésen és a számlán át a szállítási címkéig, mielőtt bármi élesbe kerül.

Sok tárhelycsomag egy kattintással készít staging példányt, ha a tiéd nem, egy külön aldomainen vagy egy olcsó, különálló tárhelyen is felállítható. A legfontosabb, hogy a másolat ugyanazt a PHP-konfigurációt, ugyanazokat a bővítményeket és lehetőleg friss adatbázist kapjon, különben a teszt keveset ér. A folyamat nálunk bevált sorrendje a következő:

• Készíts teljes mentést az éles boltról (fájlok és adatbázis külön), majd ellenőrizd, hogy a mentés valóban visszaállítható, ne csak elkészüljön.
• Hozd létre a staging másolatot, tiltsd le rajta a keresőrobotokat, állíts be jelszavas védelmet, végül kapcsold ki a vásárlóknak szóló e-mailek kiküldését.
• Kapcsold teszt üzemmódba vagy válaszd le a fizetési átjárót, a számlázó-összekötőt és a futárszolgálati integrációkat, hogy a stagingről ne menjen ki éles számla, éles NAV-adatküldés vagy valódi csomagfeladás.
• Állítsd át a staging PHP-verzióját a célverzióra (8.3 vagy 8.4), majd kapcsold be a WordPress hibanaplózását úgy, hogy a hibák fájlba kerüljenek, ne a képernyőre.
• Frissítsd a stagingen a WordPresst, a WooCommerce-t, a témát és a bővítményeket, aztán futtasd le a WooCommerce által kért adatbázis-frissítést.
• Menj végig az alábbi ellenőrzőlistán, közben pedig figyeld a hibanaplót és a WooCommerce > Status > Logs oldalt.
• A hibát okozó bővítményeket frissítsd, cseréld le vagy javíttasd ki, az egyedi kódot pedig írasd át, majd ismételd meg a tesztet.
• Ütemezd az éles váltást egy alacsony forgalmú időszakra (például kedd reggel hétre), a váltás után pedig 48 óráig figyeld a naplókat, a rendeléseket és a fizetési visszaigazolásokat.

A harmadik lépést sokan kihagyják, pedig itt lehet a legnagyobbat hibázni. Ha a staging másolaton élesben marad a számlázó-összekötő, egy tesztrendelés valódi számlát állíthat ki és valódi adatot küldhet a NAV Online Számla rendszerébe, ha pedig a vásárlói e-mailek nincsenek letiltva, a régi rendelések újrafeldolgozása akár ügyfelek százainak postafiókjában okozhat zavart. Több hazai fizetési szolgáltató (például a Barion és a SimplePay) is kínál tesztkörnyezetet, ezt érdemes használni.

A táblázat első ránézésre soknak tűnik, de egy tíz-húsz bővítménnyel futó boltnál rutinnal két-három óra alatt végigmehető. Érdemes a teszteredményeket egy egyszerű táblázatban rögzíteni (mi működött, mi nem, mit javítottunk), mert a januári WooCommerce-frissítésnél és a következő PHP-váltásnál ugyanez a lista újrahasznosítható.

Hosting-kérdések: PHP-verzió, cache, biztonság

Egy WooCommerce-bolt szempontjából a tárhelynek három dologban kell jól teljesítenie: választható, támogatott PHP-verziókat kell kínálnia, rendesen beállított gyorsítótárazást kell adnia, amely nem rontja el a kosarat, végül naprakész biztonsági hátteret és ellenőrizhető mentéseket kell biztosítania. Ha ebből bármelyik hiányzik, a PHP-váltás előtt érdemes rendezni.

PHP-verzió és váltási lehetőség

A legtöbb tárhelyvezérlőben (cPanel, Plesk, DirectAdmin) a PHP-verzió webhelyenként állítható, régebbi, olcsó csomagoknál viszont előfordul, hogy a szolgáltató csak egy-két régi verziót kínál. Ilyenkor az első lépés nem a bolt, hanem a tárhely frissítése vagy cseréje. A váltás előtt ezeket kérdezd meg írásban a szolgáltatótól:

• Elérhető-e a PHP 8.3 és a 8.4 a csomagomban, illetve webhelyenként külön állítható-e?
• Van-e staging funkció, amely ugyanazzal a PHP-konfigurációval fut, mint az éles oldal?
• Mekkora a PHP memóriakorlátja (memory_limit) és a maximális futási idő, növelhető-e a WooCommerce igényei szerint?
• Milyen PHP-bővítmények érhetők el (például intl, gd vagy imagick, zip), illetve megmaradnak-e a verzióváltás után?
• Mikor tervezi a szolgáltató a régi PHP-verziók kivezetését a kínálatából?

Cache: gyors legyen, de ne rontsa el a kosarat

A gyorsítótár (cache) három szinten segít egy webshopon. Az OPcache a PHP beépített gyorsítója, amely a lefordított kódot a memóriában tartja, ennek bekapcsolt állapota ma alapkövetelmény. Az objektum-gyorsítótár (például Redis vagy Memcached) az adatbázis-lekérdezések eredményét tárolja, ami egy sok termékkel és sok rendeléssel dolgozó boltnál érezhetően csökkenti a szerver terhelését. A harmadik az oldal-gyorsítótár, amely kész HTML-oldalakat szolgál ki. Ennél a szintnél fordul elő a leggyakoribb webshophiba: a kosár, a pénztár és a Fiókom oldalak soha nem kerülhetnek oldal-gyorsítótárba, különben a vásárló más kosarát vagy elavult végösszeget láthat. Ha bekapcsolod a 11.1 elállási űrlapját, az a Fiókom oldal alatt fut, tehát ugyanez a kivétel vonatkozik rá. PHP-váltás után minden gyorsítótárat üríts, mert a régi verzióval generált tartalom furcsa hibákat okozhat.

Biztonság: mentés, tűzfal, elkülönítés

A biztonsági oldalon a napi automatikus mentés a minimum, de csak akkor ér valamit, ha a helyreállítást legalább negyedévente ténylegesen ki is próbálod. Webalkalmazás-tűzfal (WAF), rendszeres kártevőkeresés, a tárhelyfiókok egymástól elkülönített futtatása, érvényes TLS-tanúsítvány, SFTP vagy SSH alapú hozzáférés FTP helyett, valamint kétfaktoros belépés az adminba és a tárhelyvezérlőbe mind olyan elvárás, amelyet egy 2026-os tárhelytől számon lehet kérni. Ha a szolgáltató a régi PHP-verziókat kiterjesztett, visszaportolt javításokkal tartja életben, azt tekintsd átmeneti türelmi időnek, ne tartós megoldásnak.

Mennyibe kerül a PHP-váltás egy KKV-webshopnak?

Saját becslésünk szerint egy egyszerű, kevés bővítménnyel futó WooCommerce-bolt PHP-váltása 4 és 6 fejlesztői óra, egy közepes, egyedi témával és több integrációval dolgozó boltté 10 és 16 óra, egy évek óta karbantartatlan, elhagyott bővítményekkel teli rendszeré akár 25 és 50 óra között. Az alábbi számítás 10 000 Ft-os óradíjjal készült.

A becslés tipikus munkafolyamatból indul ki: mentés, staging, PHP-váltás, frissítések, tesztelés az ellenőrzőlista szerint, hibajavítás, éles átállás és utókövetés. Az óraszámot leginkább a bővítmények állapota és az egyedi kód mennyisége határozza meg, a termékek száma sokkal kevésbé.

Ehhez jöhet egy-két fizetős bővítmény licence, ha egy elhagyott bővítményt le kell cserélni, illetve a tárhelycsomag emelése, ha a jelenlegi nem kínál modern PHP-t. Ezek ára bővítményenként és szolgáltatónként nagyon eltér, ezért itt nem adunk általános számot.

Érdemes a másik oldalt is kiszámolni. Tegyük fel, hogy egy képzeletbeli debreceni lakástextil-webshop éves árbevétele 36 millió Ft, ez naptári napra vetítve átlagosan körülbelül 100 000 Ft (36 000 000 / 365 ≈ 98 600). Ha a bolt egy kapkodva elvégzett novemberi kényszerfrissítés miatt két napig nem tud rendelést fogadni, ezek a napok pedig a Black Friday környéki, mondjuk az átlag háromszorosát hozó forgalmas napok közé esnek, a kiesés nagyságrendileg 600 000 Ft, a bizalomvesztésről nem is beszélve. A tervezett váltás a legtöbb boltnál ennek a töredékébe kerül, ráadásul a teszt során előkerülő elavult bővítmények cseréje a biztonságot is javítja.

Ütemterv 2027 januárjáig: mikor mit csinálj?

A 2026 végi naptárban négy fix pont van, amelyhez a webshop karbantartását érdemes igazítani: a 2026. november 27-i Black Friday, a WordPress 7.2 december 8. és 10. közé tervezett megjelenése, a PHP 8.2 biztonsági támogatásának vége 2026. december 31-én, végül a WooCommerce 11.5, amelyet a javaslat 2027 januárjára tervez.

Ebből egy egyszerű szabály következik: a PHP-váltást érdemes november közepéig lezárni, mert utána a forgalmas időszakban már csak biztonsági javításokat telepít egy óvatos webshop. A karácsonyi szezon utáni első hetekre marad a WooCommerce 11.5 és a WordPress 7.2, amelyekről a részleteket addigra a megjelenési jegyzetekből már pontosan tudni lehet. A WordPress 7.2 újdonságairól külön cikkben írunk, itt csak az időzítés számít.

Kinek sürgős a váltás és ki várhat még vele?

Azonnal lépnie annak kell, akinek a webshopja PHP 7.4-en, 8.0-n vagy 8.1-en fut, mert ezek a verziók már egyáltalán nem kapnak biztonsági javítást. A PHP 8.2-n futó boltoknak az év végéig van idejük, a 8.3-on és 8.4-en lévőknek pedig elég a szokásos, rendszeres frissítési rutin a januári WooCommerce 11.5-höz.

A helyzet megítélésében a PHP-verzió mellett legalább ilyen fontos, hogy a bolt karbantartott-e. Ha a webshopod évek óta nem kapott frissítést, a WooCommerce-verziója is több főverzióval le van maradva, ráadásul nem tudod pontosan, ki és mit módosított benne, akkor a PHP-váltás előtt egy rövid technikai átvilágítás a jó első lépés, mert ilyenkor a PHP csak a jéghegy csúcsa. Ha viszont a bolt rendszeresen frissül és csak a tárhely PHP-verzióját felejtette el valaki átállítani, a feladat jó eséllyel egy délelőttnyi munka a stagingen és egy nyugodt éles váltás.

Van egy harmadik csoport is: azok, akik eleve a WooCommerce lecserélésén gondolkodnak, például egy SaaS-alapú webshopplatformra. Nekik sem érdemes a PHP-váltást emiatt halogatni, mert egy platformváltás hónapokig tarthat, addig pedig a jelenlegi boltnak biztonságosan kell üzemelnie. Egy ilyen döntést nyugodtan, tények alapján érdemes meghozni, nem egy januári hibaüzenet nyomására.

Miben segít a Convergo?

Ha nem tudod pontosan, milyen PHP-n fut a webshopod, vagy tudod, csak nem mersz hozzányúlni, egy rövid átvilágítással kezdjük: megnézzük a PHP- és WooCommerce-verziót, a bővítmények állapotát és az egyedi kódot, majd írásban megmondjuk, mekkora a feladat. A PHP-váltást stagingen teszteljük, a hibákat programozás és egyedi fejlesztés keretében javítjuk, a folyamatos frissítést pedig a support, üzemeltetés és tárhely szolgáltatásunk Support csomagja fedi le havi 30 000 Ft-ért, amely 3 fejlesztői órát tartalmaz. Ha a boltod ennél nagyobb átalakításra szorul, a webshop és online értékesítés csapatunk segít dönteni a továbblépésről. Az első lépés egy ingyenes egyeztetés.