PHP 8.5 újdonságai, és hogyan frissíts a tárhelyeden

11 perc olvasás

A PHP 8.5 2025. november 20-án jelent meg, és ma ez a PHP legújabb stabil ága. Hozott néhány olyan nyelvi újítást, amelyre a fejlesztők évek óta vártak (a pipe operátor, a clone with, a beépített URI-kezelés), és elavulttá tett pár régi megoldást, amely a régebbi bővítményekben és sablonokban még előfordul. A jó hír: nem kell programozónak lenned ahhoz, hogy kihasználd. Az NVMe SSD-s webtárhelyünkön a PHP 8.3, 8.4 és 8.5 közül választhatsz, a cPanel tárhelyen pedig a CloudLinux PHP Selectorral a PHP 5.1-től a 8.5-ig bármelyik verzióra átállhatsz, egy kattintással és bármikor visszaállíthatóan.

Ebben a cikkben röviden végigvesszük, mi új a PHP 8.5-ben, meddig kapnak javítást az egyes PHP-ágak, és hogyan ellenőrizd a weboldalad kompatibilitását, mielőtt átállsz. A végén azt is megmutatjuk, mit tegyél, ha a váltás után valami nem működik.

Meddig támogatottak a PHP-verziók?

A PHP minden ága két évig kap aktív támogatást (hibajavításokat és biztonsági javításokat), utána további két évig csak biztonsági javításokat. Ha egy ág ennek a végére ér, a PHP fejlesztői többé nem javítják, akkor sem, ha súlyos sebezhetőséget találnak benne. A php.net hivatalos adatai:

PHP-ág Megjelenés Aktív támogatás vége Biztonsági javítások vége
8.1 2021. november 25. 2023. november 25. 2025. december 31. (lejárt)
8.2 2022. december 8. 2024. december 31. 2026. december 31.
8.3 2023. november 23. 2025. december 31. 2027. december 31.
8.4 2024. november 21. 2026. december 31. 2028. december 31.
8.5 2025. november 20. 2027. december 31. 2029. december 31.

A PHP 8.2 tehát az év végén kiesik a támogatásból, a részletekről és a teendőkről a PHP 8.2 támogatásának végéről szóló cikkünkben olvashatsz. Hogy ez a gyakorlatban mit jelent, azt az októberi PHP2Shell sebezhetőség is megmutatta: a php.net csak a támogatott ágakra adott ki javított verziót.

A PHP 8.5 legfontosabb újdonságai

Pipe operátor (|>)

A pipe operátor egy értéket balról jobbra visz végig függvények során: minden lépés az előző eredményét kapja meg. Így nem kell sem egymásba ágyazott függvényhívásokat olvasni belülről kifelé, sem ideiglenes változókat gyártani.

$title = ' PHP 8.5 Released ';

$slug = $title
    |> trim(...)
    |> (fn($str) => str_replace(' ', '-', $str))
    |> (fn($str) => str_replace('.', '', $str))
    |> strtolower(...);

// "php-85-released"

A jobb oldalon bármilyen egyparaméteres hívható érték állhat. Az arrow function-öket zárójelbe kell tenni, ahogy a példában is látszik.

Clone with

A clone() mostantól egy tömböt is kaphat a módosítandó tulajdonságokkal. Ez főleg a readonly osztályoknál jön jól, ahol eddig körülményes volt egy objektum másolatát egy-két eltérő értékkel előállítani (az úgynevezett „with-er” minta):

public function withAlpha(int $alpha): self
{
    return clone($this, [
        'alpha' => $alpha,
    ]);
}

Beépített URI bővítmény

Az új, mindig elérhető URI bővítmény a webcímeket szabványosan dolgozza fel, az RFC 3986 és a böngészők által használt WHATWG URL szabvány szerint is. Eddig erre a parse_url() volt, amely több szélsőséges esetben a böngészőtől eltérően értelmezte a címet, és ez biztonsági hibákhoz is vezethetett.

use Uri\Rfc3986\Uri;

$uri = new Uri('https://php.net/releases/8.5/en.php');
echo $uri->getHost(); // "php.net"

#[\NoDiscard] attribútum

Ha egy függvényt ezzel az attribútummal jelölsz meg, a PHP figyelmeztet, amikor valaki a visszatérési értékét nem használja fel. Ez azoknál a függvényeknél hasznos, ahol a visszatérési érték elhagyása szinte biztosan hiba (például ha az eredmény jelzi, sikerült-e a művelet). Ha szándékosan dobod el az értéket, a (void) típuskényszerítéssel jelezheted.

array_first() és array_last()

Két régóta hiányzó függvény: visszaadják egy tömb első, illetve utolsó elemét, üres tömbnél pedig null-t. Eddig erre a reset(), az end() vagy az array_key_first() kerülőútjait kellett használni.

$lastEvent = array_last($events);

Closure-ök konstans kifejezésekben

Statikus closure-ök és first-class callable-ök (például strlen(...)) mostantól konstans kifejezésekben is szerepelhetnek: attribútumok paramétereiben, tulajdonságok és paraméterek alapértékében, konstansokban. A keretrendszerek ezzel például a jogosultság-ellenőrzést közvetlenül egy attribútumban adhatják meg.

Backtrace a fatális hibáknál

A fatális hibák (például a túllépett maximális futási idő) üzenete mostantól tartalmazza a hívási láncot (backtrace), így a hibanaplóból kiderül, melyik kódrészlet vezetett a hibához. Ezt az új fatal_error_backtraces INI beállítás szabályozza. Egy lassú WordPress-bővítmény okozta „Maximum execution time exceeded” hibánál ez sok találgatástól kímél meg.

További újdonságok röviden

  • Closure::getCurrent(): egyszerűbb rekurzió névtelen függvényekben.
  • Az attribútumok konstansokra is alkalmazhatók, a #[\Override] tulajdonságokra, a #[\Deprecated] traitekre és konstansokra is.
  • Aszimmetrikus láthatóság statikus tulajdonságoknál, és final jelölés a konstruktorban promotált tulajdonságoknál.
  • Tartós cURL share handle-ök (curl_share_init_persistent()): a DNS-feloldás és a kapcsolatok több kérésen át újrahasznosíthatók.
  • A setcookie() és a setrawcookie() támogatja a partitioned kulcsot.
  • Új get_error_handler() és get_exception_handler() függvény.
  • Új max_memory_limit INI beállítás, amely felső határt szab annak, mekkorára emelhető a memory_limit futás közben.
  • A php --ini=diff parancs kiírja, mely beállítások térnek el az alapértelmezéstől.
  • Az OPcache mostantól mindig a PHP része, nem külön betöltendő bővítmény (az opcache.enable beállítás továbbra is érvényes).

Mi lett elavult a PHP 8.5-ben?

Az elavult (deprecated) funkciók egyelőre működnek, de használatukkor a PHP E_DEPRECATED figyelmeztetést ír a naplóba, egy későbbi főverzióban pedig megszűnhetnek. A régebbi bővítményekben és sablonokban ezek fordulhatnak elő leggyakrabban:

  • A backtick operátor: a `ls -la` alak a shell_exec() rövidítéseként elavult, helyette a shell_exec('ls -la') használandó.
  • Nem kanonikus típuskényszerítések: a (boolean), (integer), (double) és (binary) helyett (bool), (int), (float) és (string) írandó.
  • null tömbindexként: a $a[null] és a null átadása az array_key_exists()-nek elavult, helyette üres sztring használandó.
  • Pontosvesszővel lezárt case: a switch ágait kettősponttal kell lezárni.
  • __sleep() és __wakeup(): „puha” elavulás, figyelmeztetés nélkül; az új kódban a __serialize() és az __unserialize() ajánlott.
  • Felesleges „bezáró” függvények: a curl_close(), az imagedestroy(), a finfo_close() és a xml_parser_free() elavult, mert az erőforrások már objektumok, és maguktól felszabadulnak.

Néhány változás figyelmeztetést is ad: például ha egy lebegőpontos szám nem fér el egészként, és mégis int típusra alakítják, vagy ha egy nem tömb értéket bontanak szét a [] vagy a list() szerkezettel. A disable_classes INI beállítás megszűnt. A teljes listát a php.net migrációs útmutatója tartalmazza.

Mit jelent mindez a weboldaladnak?

Ha WordPresst, Joomlát, PrestaShopot vagy egy keretrendszerre épülő alkalmazást futtatsz, a nyelvi újdonságokat nem neked kell használnod: a fejlesztők fokozatosan építik be őket. A kérdés az, hogy a ma használt kód (a mag, a bővítmények és a sablon) fut-e hibátlanul PHP 8.5-ön.

A WordPress mag a 6.9-es verzió óta támogatja a PHP 8.5-öt (akkor még béta jelzéssel, amelyet azóta elhagytak). A bővítményeknél és a sablonoknál viszont vegyes a kép: a jól karbantartottak többnyire gyorsan követik az új verziókat, a régóta nem frissített, egyedi vagy elhagyott bővítmények okozhatnak gondot. Arról, hogy melyik PHP verzió a legjobb a WordPresshez, külön cikkben részletesebben is írtunk.

Frissítés előtt: így ellenőrizd a kompatibilitást

  1. Készíts mentést. A fájlokról és az adatbázisról is. A webtárhelyen a Web Starter csomagtól automatikus mentés is készül, de egy saját másolat a váltás előtt sem árt: exportáld az adatbázist a phpMyAdminban, és töltsd le a fájlokat FTP-n. A cPanel tárhelyen a teljes fiókról is készíthetsz mentést (lépések itt), WordPressnél egy mentő bővítmény is megteszi.
  2. Frissíts mindent a jelenlegi PHP-verzión. Előbb a WordPress magot, a bővítményeket és a sablont, és csak utána a PHP-t. Ha egyszerre változtatsz mindent, nehéz kideríteni, mi okozta a hibát.
  3. Nézd meg a bővítmények adatlapját. A WordPress.org-on minden bővítménynél látszik a minimális PHP-verzió és az utolsó frissítés dátuma. Egy két éve nem frissített bővítménynél érdemes alternatívát keresni.
  4. Futtass statikus ellenőrzést, ha egyedi kódod van. A PHPCompatibility szabálykészlet a PHP_CodeSniffer segítségével megkeresi a kódban az elavult vagy megszűnt függvényeket. A PHP 8.5 szabályai a 10-es fejlesztői ágban vannak (a régi 9.3.5-ös kiadás csak a PHP 7.x változásait ismeri). A saját gépeden futtasd, a projekt könyvtárában:

    composer require --dev phpcompatibility/php-compatibility:"^10.0.0@dev"
    vendor/bin/phpcs -p wp-content/themes/sajat-sablon --standard=PHPCompatibility --runtime-set testVersion 8.5
    
  5. Próbáld ki egy tesztpéldányon. A legbiztosabb, ha az oldal egy másolatán (staging) állsz át először. A cPanel tárhelyen a WP Toolkit pár kattintással készít ilyet (a WP Toolkites staging lépései), a módszerekről pedig a WordPress staging cikkünk szól bővebben.
  6. Kapcsold be a hibanaplót. WordPressnél a wp-config.php fájlban így irányíthatod a hibákat és figyelmeztetéseket a wp-content/debug.log fájlba úgy, hogy a látogatók ne lássák őket:

    define( 'WP_DEBUG', true );
    define( 'WP_DEBUG_LOG', true );
    define( 'WP_DEBUG_DISPLAY', false );
    

    A tesztelés után állítsd vissza a WP_DEBUG értékét false-ra, és töröld a naplófájlt.

A váltás után kattints végig az oldal legfontosabb részein: a főoldalon, egy bejegyzésen, a kapcsolati űrlapon, webáruháznál a kosáron és a fizetésen, valamint az adminfelületen. Utána nézd át a hibanaplót: a deprecated figyelmeztetések még nem okoznak hibát, de jelzik, melyik bővítményt kell majd frissíteni vagy lecserélni.

PHP-verzió váltása a webtárhelyen (KeyHelp)

A webtárhelyünk kezelőfelülete a magyar nyelvű KeyHelp (az alapjait első lépések útmutatónk mutatja be). Itt a PHP-verziót domainenként állíthatod be:

  1. Lépj be a KeyHelp felületre, és nyisd meg a Domainok menüpontot.
  2. A domain sorában kattints a ceruza ikonra, majd az Értelmező fülre.
  3. A PHP értelmező listában válaszd ki a kívánt verziót (8.3, 8.4 vagy 8.5). Ha az aldomainekre (például a www-re) is ugyanezt szeretnéd, pipáld be a PHP értelmező alkalmazása az összes aldomainre opciót, majd mentsd a módosítást.
  4. Töltsd újra az oldalt, és ellenőrizd a működését.

Mivel a webtárhelyen csak támogatott PHP-ágak futnak, itt a kérdés nem az, hogy biztonságos-e a verzió, hanem hogy a weboldalad melyikkel működik a legjobban. Ha nem találod a beállítást, vagy bizonytalan vagy, írj nekünk, és segítünk.

PHP-verzió váltása cPanel tárhelyen (CloudLinux PHP Selector)

A cPanel tárhelyen a CloudLinux PHP Selector (a cPanelben Select PHP Version) a teljes tárhelyfiók PHP-verzióját állítja. A lépéseket képekkel az alapértelmezett PHP verzió átállításáról szóló tudásbázis cikk mutatja be, röviden:

  1. A cPanel Szoftver csoportjában nyisd meg a Select PHP Version menüpontot.
  2. A Current PHP version listában válaszd ki a 8.5-öt (vagy a kívánt verziót), és erősítsd meg a Set as current gombbal.
  3. Ellenőrizd a bővítményeket. A PHP Selectorban a bővítmények (például az imagick, az intl vagy az ioncube_loader) verziónként külön kapcsolhatók, így egy új verzióra váltva nézd meg, hogy az oldaladnak szükséges modulok be vannak-e kapcsolva. A részleteket a PHP bővítmények kezeléséről szóló cikkben találod.

Ha a tárhelyeden több oldal fut, és csak az egyiknek kell más verzió, könyvtáranként eltérő PHP-verziót is beállíthatsz egy .htaccess sorral (könyvtáranként eltérő PHP verzió beállítása). Egy régi alkalmazásnak a cPanel tárhelyen a régebbi verziók is rendelkezésre állnak; hogy ezek mennyire biztonságosak, azt a HardenedPHP-ról szóló cikkünk írja le.

Ha a váltás után valami nem működik

A PHP-verzió váltása mindkét tárhelytípuson azonnal érvénybe lép, és ugyanígy azonnal vissza is állítható. Ha az oldal fehér képernyőt vagy „500 Internal Server Error” hibát mutat, az első lépés mindig ez: állítsd vissza az előző verziót, hogy a látogatók újra működő oldalt lássanak. Utána nyugodtan kideríthető, mi okozta a hibát.

  • Nézd meg a hibanaplót. A fatális hiba üzenete megmondja a fájl nevét és a sor számát, a PHP 8.5-ben már a teljes hívási lánccal együtt. Ha az útvonal a wp-content/plugins/ egy alkönyvtárára mutat, megvan a bűnös bővítmény.
  • „Call to undefined function”: többnyire egy bővítmény (modul) hiányzik az új verzióból, cPanelben kapcsold be a PHP Selectorban.
  • Egy bővítmény okozza a hibát: frissítsd, vagy ha nincs újabb verziója, kapcsold ki. Ha az adminfelület sem tölt be, nevezd át a bővítmény könyvtárát a fájlkezelőben vagy FTP-n, így a WordPress kikapcsolja.
  • Deprecated üzenetek az oldalon: ez nem hiba, csak a hibák kijelzése van bekapcsolva. Éles oldalon kapcsold ki a kijelzést (display_errors = Off), a naplózás maradhat.

A hibakeresés általános lépéseit az 500-as hiba javításáról szóló cikkünk és a WordPress fehér képernyőről szóló útmutató is összefoglalja.

Melyik verziót válaszd most?

  • PHP 8.5, ha a weboldalad minden része támogatja: ez kapja a leghosszabb ideig javításokat, 2029 végéig.
  • PHP 8.4 jó, biztonságos alapértelmezés, ha egy-két bővítményed még nem követte a 8.5-öt: 2026 végéig aktív támogatást, 2028 végéig biztonsági javításokat kap.
  • PHP 8.3 csak átmenetileg, ha egy fontos bővítményed az újabbakkal nem működik: 2027 végéig kap biztonsági javítást.
  • PHP 8.2 és régebbi: csak akkor, ha másképp nem megoldható, és tervezd meg mielőbb a váltást.

Ha még a frissítés értelmén gondolkodsz, arról, miért fontos a PHP frissítése a sebesség és a biztonság szempontjából, külön cikkben írtunk részletesebben.

Gyakori kérdések

Gyorsabb lesz az oldalam PHP 8.5-tel?

A PHP 8.5 nem hoz akkora teljesítményugrást, mint annak idején a PHP 7 vagy a 8.0. Egy 7.4-es vagy 8.0-s verzióról érkezve azonban a sebesség és a memóriahasználat is érezhetően javulhat, és ami legalább ilyen fontos: a támogatott verzió biztonsági javításokat kap.

Át kell írni a weboldalam kódját?

Kész rendszernél (WordPress, webáruház-motor) általában nem: elég, ha a magot, a bővítményeket és a sablont naprakészen tartod. Egyedi fejlesztésnél futtass egy PHPCompatibility ellenőrzést, és nézd át a hibanaplóban a deprecated figyelmeztetéseket.

Honnan tudom, milyen PHP-verzió fut most az oldalamon?

WordPressben az Eszközök menü Webhely egészség (Site Health) oldalán, az Információ fül Szerver részében látszik. cPanelben a Select PHP Version oldal tetején, KeyHelpben a Domainok listájának PHP verzió oszlopában (a verziószámra kattintva a teljes phpinfo is megnyílik). Egyedi oldalnál egy phpinfo() hívást tartalmazó fájl is megmutatja; ezt az ellenőrzés után töröld.

Visszaállhatok, ha valami nem működik?

Igen, a verzióváltás bármikor visszafordítható, és azonnal érvénybe lép. Ezért érdemes forgalmasabb időszakon kívül váltani, és a váltás után rögtön végigkattintani az oldalt.

Mi a helyzet a VPS-sel?

Saját szerveren a PHP-t neked kell telepítened és frissítened, a disztribúció csomagjaiból vagy egy külső csomagtárolóból. Ha nem szeretnél ezzel foglalkozni, a fenti tárhelyeken mi gondoskodunk a PHP-verziók frissítéséről és a biztonsági javításokról.

Vissza a blogra