# A PHP jövője

> A PHP jövője igazolt tervek alapján: támogatási idők, a PHP 8.6 tervezett időpontja, elfogadott RFC-k a PHP 9.0-hoz, és mit jelent ez a tervezésnek.

Forrás: https://phpsos.de/hu/php/zukunft-von-php/  
Állapot: 2026. 10. 25.  
Szolgáltató: PHP SOS, PHP-vészhelyzeti segítség és szerverbiztonság. Azonnali segítség WhatsAppon: https://wa.me/491736494914?text=%C3%9Cdv%C3%B6zl%C3%B6m%2C%20PHP%20SOS%21%20Seg%C3%ADts%C3%A9gre%20van%20sz%C3%BCks%C3%A9g%C3%BCnk%20a%20PHP-szerver%C3%BCnkkel.%20C%C3%A9g%3A%20%E2%80%A6%20Weboldal%3A%20%E2%80%A6

**Röviden:** A PHP jövője lényeges részeiben rögzített és nyilvánosan olvasható. Minden verzió négy év támogatást kap, ebből kettőt csak biztonsági javításokkal, mindig december 31-ig. A PHP 8.6 a tervezés szerint 2026. november 19-re van előirányozva, és többek között biztonságosabb munkamenet-alapértékeket hoz. A PHP 9.0-hoz vannak elfogadott módosítási javaslatok, de nincs bejelentett időpont. A vállalatok számára ez tervezhető frissítéseket jelent meglepetések helyett, amíg támogatott verziókat használnak.

## Hogyan döntenek a PHP jövőjéről?

Az új funkciók és szabályok a PHP-ban RFC-k (Request for Comments) útján keletkeznek. Egy javaslatot közzétesznek a PHP-wikiben, megvitatják a levelezőlistán, majd szavaznak róla. Az új munkamenet-alapértékekhez például az RFC szerint kétharmados többség kellett. Csak egy elfogadott és megvalósított RFC igazolt tervezés; a vitában lévő javaslatok ötletek, nem ígéretek.

A döntéshozók számára ez előny: aki tudni akarja, mi jön, elolvashatja a wikiben lévő listát, ahelyett hogy pletykákra hagyatkozna. Ezen az oldalon ezért csak elfogadott vagy megvalósított RFC-ket és hivatalos időpontokat nevezünk meg.

## Rögzített támogatási idők: verziónként négy év

2024-ben a PHP-projekt RFC-vel módosította a kiadási ciklust. Azóta érvényes: két év aktív támogatás hiba- és biztonsági javításokkal, utána két évig csak kritikus biztonsági problémákra. A határidők egységesen december 31-én járnak le. A Release Candidate-ek már nem tartalmazhatnak új funkciókat.

| Verzió | Megjelent | Aktív támogatás eddig | Biztonsági javítások eddig |
|---|---|---|---|
| 8.2 | 2022. 12. 08. | 2024. 12. 31. | 2026. 12. 31. |
| 8.3 | 2023. 11. 23. | 2025. 12. 31. | 2027. 12. 31. |
| 8.4 | 2024. 11. 21. | 2026. 12. 31. | 2028. 12. 31. |
| 8.5 | 2025. 11. 20. | 2027. 12. 31. | 2029. 12. 31. |
| 8.6 | tervezett 2026. 11. 19. | a szabály szerint várhatóan 2028. 12. 31. | a szabály szerint várhatóan 2030. 12. 31. |

A 8.2-től 8.5-ig terjedő értékek a php.net-ről származnak, a 8.6-ra vonatkozókat az érvényes szabályból vezettük le; kötelezővé csak akkor válnak, ha a php.net közzéteszi őket. Hogy ez mit jelent a régebbi verziókra, azt a [PHP-verziók és kiadási ciklus](https://phpsos.de/hu/php/release-zyklus/) és a [PHP életciklus vége: az elavult verziók kockázatai](https://phpsos.de/hu/ratgeber/php-end-of-life-risiken/) oldal írja le.

## PHP 8.6: ami eldőlt

A PHP-wiki ütemterve szerint a PHP 8.6.0 megjelenése 2026. november 19-re van előirányozva. 2026. október 21-én megjelent a negyedik Release Candidate, amely a php.net közlése szerint már tartalmazza a két PHP2Shell-rés javításait; a korábbi 8.6-os tesztverziókat le kell cserélni. A következő Release Candidate-et 2026. november 5-re jelentették be. A tesztverziók nem valók éles üzembe.

Válogatás azokból az RFC-kből, amelyeket a wiki a PHP 8.6-hoz megvalósítottként vezet:

1. **Biztonságos munkamenet-alapértékek:** a `session.use_strict_mode` és a `session.cookie_httponly` alapértelmezés szerint bekapcsol, a `session.cookie_samesite` pedig `Lax` értékre áll.
2. **Függvényargumentumok a hibaüzenetekben:** kiegészítő adatok, amelyek segítenek a hibakeresésben.
3. **A szűrőláncok korlátozása:** felső határ a láncolt szűrők számára.
4. **Új nyelvi eszközök:** többek között a `clamp()`, a részleges függvényalkalmazás és alapértékek a readonly tulajdonságokhoz.
5. **Kivezetés:** a `__construct()` és a `__destruct()` visszatérési értékei elavultnak minősülnek.

Hogy mi érkezett már a PHP 8.0-tól 8.5-ig, azt a [PHP 8.0-tól 8.5-ig: a legfontosabb újdonságok](https://phpsos.de/hu/php/php-8-neuerungen/) foglalja össze.

## PHP 9.0: elfogadott javaslatok, időpont nélkül

Több RFC kifejezetten a PHP 9.0-hoz ír elő változásokat, és elfogadott, de még nincs megvalósítva. Idetartozik: hiba figyelmeztetés helyett a nem definiált változóknál és tulajdonságoknál, a `${}` írásmód eltávolítása a karakterláncokban, a munkamenet-azonosítók GET-en és POST-on át való továbbításának eltávolítása, és az implicit nullázható paramétertípusok vége. A PHP 9.0 megjelenési időpontja a php.net-en nincs bejelentve.

A tervezéshez ez azt jelenti: az olyan kódot, amely ma elavult funkciókról figyelmeztetéseket állít elő, most érdemes megtisztítani. Akkor a későbbi ugrás nem lesz nagyprojekt.

A wikiben emellett sok javaslat áll vita alatt, például egy közös binárisról a parancssorhoz és az FPM-hez, vagy párhuzamosság a motorban. Hogy megvalósulnak-e, nyitott.

## Ki viszi a PHP-t

A PHP-t önkéntesek és fizetett fejlesztők gondozzák. Minden verzióhoz van egy kiadásmenedzser-csapat; a PHP 8.6-hoz a wiki Daniel Scherzert, Matteo Beccatit és Joe Fergusont nevezi meg. A PHP Foundation a feladatát a nyelv hosszú távú virágzásának biztosításaként írja le, és saját bemutatása szerint részmunkaidős és teljes munkaidős fejlesztők csapatát bízza meg karbantartásra, biztonságra és új funkciókra.

Az infrastruktúrát is korszerűsítik: a PHP 8.5 óta az OPcache fixen be van építve, és RFC-vel elhatározták, hogy a bővítményekhez a PIE-t ajánlják, a PECL-t pedig elavultként jelölik.

## Mit jelent a PHP jövője az Ön biztonsága számára

A PHP2Shell megmutatta, milyen fontosak a támogatási idők. A 8.2-től 8.5-ig 2026. október 21-én hivatalos javítások érkeztek; a 8.1-hez és a régebbiekhez már csak minimális forrás-backportok. A PHP 8.2 2026. december 31-én véget ér. Aki ma tervez, három dolgot rögzítsen:

- Minden használt verziónak ismert támogatási vége van a naptárban.
- A következő támogatott verzióra való váltás ezen időpont előtt, időben kerüljön sorra.
- Az új alapértékek, mint a biztonságos munkamenet-beállítások a 8.6-ban, üdvözlendők, de nem helyettesítik a tudatos konfigurációt.

## Hogyan segít konkrétan a PHP SOS?

A [Migráció támogatott PHP-verzióra](https://phpsos.de/hu/leistungen/php-migration-legacy/) során így járunk el:

- **Állomány és határidők:** Felmérjük az összes PHP-verziót, és beírjuk a támogatási végüket az Ön tervébe.
- **A frissíthetőség ellenőrzése:** Megmutatjuk, mely alkalmazások és bővítmények akadályoznak egy új verziót.
- **Az átállás elvégzése:** Teszt, átállítás, újraindítás és ellenőrzés, verzióról verzióra.
- **Előrelátás:** Követjük az RFC-ket és a kiadási időpontokat, és jelezzük, ha egy változás az Ön rendszereit érinti.


## Gyakori kérdések

**Meddig támogatnak egy PHP-verziót?**  
Egy 2024-ben elfogadott RFC óta négy évig: két év aktív támogatás hibajavításokkal, utána két évig csak biztonsági javításokkal. A határidők mindig december 31-én járnak le.

**Mikor jelenik meg a PHP 8.6?**  
A PHP-wikiben lévő tervezés szerint a megjelenés 2026. november 19-re van előirányozva. 2026. október 21-én megjelent a 4. Release Candidate, a következőt 2026. november 5-re jelentették be. Az időpontok a wiki szerint eltolódhatnak.

**Mikor jön a PHP 9.0?**  
A php.net-en nincs bejelentett időpont. Vannak elfogadott RFC-k, amelyek a PHP 9.0-hoz változásokat írnak elő, például szigorúbb hibákat a nem definiált változóknál. Hogy mikor jelenik meg ez a verzió, nyitott.

**Biztonságos befektetés a PHP a következő évekre?**  
Igazolt, hogy van rögzített kiadási terv, aktív RFC-eljárás és olyan alapítvány, amely fizeti a fejlesztőket a karbantartásért és a biztonságért. A jövőre vonatkozó garancia egyetlen technikánál sincs; a döntő, hogy támogatott verziókat használjon.

## Források

- [php.net: támogatott verziók](https://www.php.net/supported-versions.php)
- [PHP RFC: Release cycle update](https://wiki.php.net/rfc/release_cycle_update)
- [PHP-RFC-k (áttekintés)](https://wiki.php.net/rfc)
- [PHP RFC: Secure Session Configuration Defaults](https://wiki.php.net/rfc/session_security_defaults)