PHP verze na hostingu: proč už neprovozovat staré PHP

Verze PHP je jedno z těch nastavení, které se jednou zapne a nikdo se k němu deset let nevrátí. Web přece jede. Problém je, že „jede" a „dostává bezpečnostní záplaty" jsou dvě různé věci — a mezi nimi bývá i několik let rozdíl.

Ukážu ti, jak vypadá životní cyklus PHP, co se přesně stane ve chvíli, kdy tvoje větev doslouží, a jak se dostat na novější verzi bez toho, abys v pátek večer řešil bílou stránku. Termíny beru přímo z php.net, ne z toho, co si kdo pamatuje.

Životní cyklus PHP: dva roky oprav, dva roky bezpečnosti

Vydávání PHP má pevný rytmus. Nová hlavní verze vychází zhruba jednou ročně, na konci listopadu, a pak má dvě fáze podpory:

1. Aktivní podpora (zhruba 2 roky) — opravují se běžné chyby i bezpečnostní díry.
2. Bezpečnostní podpora (další 2 roky) — vycházejí už jen opravy bezpečnostních problémů.

Po čtyřech letech od vydání větev končí. Od té chvíle na ni nevyjde žádná oprava, ani kdyby se v ní našla kritická zranitelnost. Takhle vypadá stav větví PHP podle oficiálního přehledu na php.net:

Zdroj: php.net — Supported Versions a php.net — Unsupported Branches.

Z tabulky vypadne jedna věc, kterou je dobré si uvědomit hned: PHP 8.2 doslouží 31. prosince 2026. Pokud na něm dnes běžíš, nemáš problém — ale máš termín.

Co znamená EOL v praxi

EOL (End of Life) neznamená, že web zítra přestane fungovat. Znamená něco horšího: od té chvíle roste riziko tiše a ty o něm nevíš.

Konkrétně:

• Nové zranitelnosti se neopravují. Když se v interpreteru najde díra, nová verze vyjde jen pro podporované větve. Tvoje ne.
• Knihovny a frameworky tě přestanou podporovat. Composer začne odmítat instalaci novějších balíčků, protože vyžadují vyšší php v composer.json. Nemůžeš aktualizovat ani závislosti, které opravy dostávají.
• CMS a pluginy zvyšují minimální požadavky. Dřív nebo později dojde na aktualizaci, kterou na staré verzi prostě nenainstaluješ.
• Přicházíš o výkon. Každá větev PHP 8.x přinesla optimalizace v OPcache a JIT. Rozdíl mezi PHP 7.4 a aktuální větví se u typického CMS pohybuje v desítkách procent doby zpracování požadavku.
• Neprojdeš auditem. Pokud tvůj web zpracovává platby nebo pracuješ pro klienta s bezpečnostními požadavky, „běžíme na neaktualizovaném interpreteru" je nález, který se špatně vysvětluje.

Poskytovatelé to řeší různě. Někteří starou verzi po EOL prostě odpojí, jiní ji nechají běžet s vlastními záplatami z distribuce (typicky u Debianu nebo RHEL). Druhá varianta je lepší než nic, ale nepokrývá všechno a rozhodně to není důvod zůstat.

Kolik webů na starém PHP pořád běží

Nejsi v tom sám a to je vlastně to znepokojivé. Podle veřejných statistik WordPress.org (stav k červenci 2026) běží na PHP 7.4 zhruba 18 % instalací a když přičteme všechny ještě starší větve, dostaneme se přes 24 %. Přidej k tomu PHP 8.0 (asi 4 %) a PHP 8.1 (asi 12 %), které už také skončily, a vyjde ti, že zhruba 40 % webů na WordPressu jede na verzi PHP bez bezpečnostních oprav (zdroj: WordPress.org — Statistics).

Nejrozšířenější jsou dnes PHP 8.2 a 8.3 (dohromady kolem 49 %), PHP 8.4 má necelých 8 %. Jinými slovy: většina webů už na osmičkové řadě je, ale ta pomalejší polovina uvízla na verzi, kterou nikdo neopravuje.

Dopad na WordPress a další aplikace

WordPress dnes oficiálně doporučuje PHP 8.3 nebo novější, k tomu MariaDB 10.11+ nebo MySQL 8.0+ a HTTPS označuje za nutnost u každé instalace (zdroj: Požadavky WordPressu). Starší verze podle stejné stránky pořád fungují, ale nemají oficiální podporu a můžou web vystavit bezpečnostním rizikům.

V praxi to vypadá takhle. Samotné jádro WordPressu bývá s novým PHP kompatibilní rychle. Problémy dělají pluginy a šablony — hlavně ty, které se roky neaktualizovaly, a vlastní úpravy ve functions.php. Typické chyby po přechodu na PHP 8:

• Předávání null do funkcí, které očekávají řetězec — v PHP 8.1 a novějším to hlásí deprecated, ve výsledku máš log plný varování
• Změněná pravidla porovnávání řetězce s číslem ("abc" == 0 už není true)
• Odstraněné funkce — create_function(), staré mysql_* volání, each()
• Přísnější práce s argumenty — chybějící parametr už není varování, ale fatální chyba

U vlastních aplikací (Laravel, Symfony, staré zakázkové systémy) je to podobné, jen nemáš komunitu, která to za tebe otestovala. Tam se vyplatí projít kód statickou analýzou dřív, než sáhneš na přepínač.

Jak přejít na novější PHP bez rozbití webu

Postup, který funguje a nevyžaduje odvahu:

1. Zjisti, kde jsi. Nahraj si na web soubor s <?php phpinfo(); nebo se podívej do administrace hostingu. U WordPressu ti verzi ukáže rovnou přehled v sekci Nástroje → Zdraví webu.
2. Aktualizuj všechno ostatní dřív. Jádro CMS, pluginy, šablonu, závislosti v Composeru. Většina nekompatibilit zmizí právě tímhle krokem.
3. Vyřaď mrtvý kód. Plugin, který má poslední aktualizaci z roku 2019, není potřeba opravovat — je potřeba ho vyhodit.
4. Přepni na staging. Většina slušných hostingů dnes umí testovací kopii webu na jedno kliknutí. Pokud ne, udělej si kopii na subdoméně.
5. Zapni hlášení chyb a proklikej web. Na stagingu nastav display_errors na zapnuto a projdi administraci, formuláře, objednávkový proces, export faktur. Sleduj error log — deprecated hlášky ještě nejsou fatální, ale ukazují, kde to bude bolet příště.
6. Skákej po jedné větvi. Z PHP 7.4 nepřecházej rovnou na 8.4. Zastav se na 8.0 nebo 8.1, ať víš, která změna co rozbila.
7. Přepni produkci a měj plán návratu. Přepnutí verze je u většiny hostingů otázka jednoho výběru v panelu a jde vrátit zpět během minuty. Udělej to v době slabého provozu a půl hodiny sleduj log.

Když to celé spojíš se stěhováním na jiný hosting, jde postup zkombinovat — jen si pak dej pozor, ať neměníš dvě věci naráz. Doporučený sled kroků najdeš v checklistu migrace bez výpadku.

Za pozornost stojí i to, že vyšší PHP obvykle znamená jiné výchozí limity. Pokud po přechodu narazíš na chyby při importu nebo generování PDF, podívej se na memory_limit a max_execution_time — obojí se dá na většině hostingů nastavit.

Co má umět dobrý hosting

Tohle je krátký seznam, podle kterého se dá poskytovatel posoudit během pěti minut:

• Nabízí aktuální větve PHP — v roce 2026 minimálně 8.3 a 8.4, ideálně i 8.5
• Umožňuje přepnout verzi samoobslužně, bez tiketu na podporu a bez čekání
• Dovoluje jinou verzi pro každou doménu nebo adresář — hodí se, když spravuješ víc webů
• Umí návrat na předchozí verzi jedním kliknutím
• Má staging prostředí nebo alespoň snadné klonování webu
• Dá se u něj upravit memory_limit, max_execution_time a upload_max_filesize
• Nechává zapnutou OPcache a umí object cache (Redis, Memcached)
• Informuje dopředu, kdy starou větev odstaví, a nemění verzi bez varování

Parametry jednotlivých poskytovatelů včetně podporovaných verzí PHP si můžeš profiltrovat v kategorii webhosting. Pokud řešíš konkrétně WordPress, kde na verzi PHP záleží nejvíc kvůli pluginům, koukni do kategorie WordPress hosting.

FAQ

Jakou verzi PHP mám mít v roce 2026?

Nejbezpečnější volba je poslední větev v aktivní podpoře, tedy PHP 8.4 nebo 8.5. Pokud tě brzdí kompatibilita pluginů, PHP 8.3 je rozumný kompromis — bezpečnostní opravy dostává do konce roku 2027. WordPress sám doporučuje 8.3 a novější.

Je PHP 8.2 ještě v pořádku?

Do konce roku 2026 ano, dostává bezpečnostní opravy. Potom už ne. Ber to jako termín, ne jako důvod k panice — máš čas si přechod naplánovat a otestovat.

Rozbije se mi web, když přepnu na novější PHP?

U aktualizovaného WordPressu s udržovanými pluginy obvykle ne. Riziko roste s počtem let, které web strávil bez aktualizací, a s množstvím vlastního kódu. Proto se to testuje na stagingu a proto se dá verze vrátit zpět.

Zrychlí novější PHP můj web?

Zpravidla ano, u dynamických stránek měřitelně. Netýká se to ale statického obsahu ani frontendu — pokud tě brzdí velké obrázky a JavaScript, novější PHP na tom nic nezmění. Rozdělení vlivu jsem rozebíral v článku Core Web Vitals a hosting.

Co když plugin, který nutně potřebuju, novější PHP nepodporuje?

Pak máš tři možnosti a všechny tři jsou lepší než zůstat na EOL verzi: najít náhradu, zaplatit úpravu pluginu, nebo tuhle konkrétní funkci oddělit na samostatný izolovaný web. Zůstat kvůli jednomu pluginu na neopravované verzi PHP je nejdražší varianta ze všech.

Musím přejít hned, když větev skončí?

Neexistuje žádný spínač, který by web v den EOL vypnul. Ale od toho dne se každá nově objevená zranitelnost týká i tebe a nikdo ji neopraví. Rozumný interval na přechod je půl roku před koncem podpory.

Závěr

PHP má předvídatelný kalendář: dva roky oprav, dva roky bezpečnostních záplat, konec. Termíny jsou veřejné roky dopředu, takže přechod na novější verzi není krizové řízení, ale položka v plánu údržby. Nejnákladnější je varianta, kdy se na verzi PHP nikdo nedívá — dokud web nepřestane přijímat aktualizace nebo neprojde bezpečnostní kontrolou.

Zkontroluj si dnes, na čem běžíš. Pokud je to cokoliv pod 8.2, začni s aktualizacemi pluginů a přechod si naplánuj. A pokud tvůj hosting aktuální větve PHP vůbec nenabízí nebo je přidává s ročním zpožděním, je to samo o sobě dobrý důvod porovnat si nabídku v kategorii webhosting.