Problemy z PHP w WordPress – wersje, błędy, kompatybilność 2026

WordPress 6.6+ oficjalnie wspiera PHP od wersji 7.4 wzwyż, ale to nie znaczy, że powinieneś jej używać. PHP 7.4 skończyło support 28 listopada 2022, PHP 8.0 – 26 listopada 2023, PHP 8.1 – 31 grudnia 2025. To oznacza zero łatek bezpieczeństwa, a luki w PHP są natychmiast wykorzystywane przez automatyczne skanery przeszukujące internet w poszukiwaniu podatnych instalacji.

W kwietniu 2026 mamy trzy w pełni wspierane wersje: PHP 8.2 (security fixes do 31.12.2026), PHP 8.3 (active support do 23.11.2026, security do 31.12.2027) i PHP 8.4 wydane w listopadzie 2024 (active do 31.12.2026, security do 31.12.2028). Najbezpieczniejszy wybór dla większości sklepów i blogów to PHP 8.3 – kombinacja świeżości i sprawdzonej kompatybilności z popularnymi wtyczkami.

Praktyka pokazuje, że około 28% stron WordPress w Polsce wciąż siedzi na PHP 7.4 lub starszych. To ogromny problem bezpieczeństwa, często łączony z problemami z hostingiem WordPress, które pogłębiają sytuację – stary hosting zwykle blokuje wybór nowszej wersji PHP w panelu.

Dobry hosting daje wybór wersji jednym kliknięciem. CyberFolks standardowo oferuje PHP 8.3 z OPcache i Memcached w cenie podstawowego pakietu – nie musisz nic konfigurować ręcznie.

Biała strona albo komunikat o krytycznym błędzie to klasyk po podbiciu wersji PHP. WordPress przesyła wtedy maila na adres administratora z linkiem do trybu recovery (/wp-login.php?action=enterrecoverymode). Jeśli mail nie dotarł, musisz wejść w diagnostykę ręcznie.

Włącz tryb debug w wp-config.php (przez FTP, FileZilla albo SFTP w panelu hostingu):

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

Logi pojawią się w /wp-content/debug.log. Otwórz plik i szukaj linii zaczynających się od PHP Fatal error. Standardowy format wygląda tak:

`PHP Fatal error: Uncaught Error: Call to undefined function get_field() in /wp-content/plugins/moja-wtyczka/inc/template.php:42`

Odczyt: brak funkcji get_field() (czyli nieaktywne ACF), w pliku wtyczki moja-wtyczka, linia 42. Rozwiązanie: aktywuj ACF lub zaktualizuj wtyczkę do wersji zgodnej z aktualnym PHP.

Lista najczęstszych błędów po przejściu na PHP 8.x:

• Cannot use self as parameter type – stary kod używa self przed PHP 7.4
• Implicit conversion from float to int – PHP 8.1 wymusza explicit cast
• Call to undefined method – usunięto deprecated method w nowej wersji
• Allowed memory size exhausted – nie zwiększono memory_limit po migracji
• Maximum execution time exceeded – długie zapytania bez timeout

Jeśli nie masz dostępu do FTP, większość paneli (CloudPanel, cPanel, DirectAdmin) ma File Manager z opcją edycji wp-config.php przez przeglądarkę. To samo rozwiązanie pomaga też przy problemach z aktualizacjami WordPress, które często idą w parze z błędami PHP.

Parse error różni się od fatal error tym, że PHP nawet nie zaczyna wykonywać kodu – po prostu nie potrafi go zrozumieć. Komunikat wygląda tak:

`Parse error: syntax error, unexpected token ';', expecting ']' in /wp-content/themes/moj-motyw/functions.php on line 127`

Masz tu trzy informacje: typ błędu (syntax error), plik (functions.php motywu), linia (127). Otwórz plik w edytorze z numeracją linii (VS Code, Notepad++, Sublime) i przejdź do wskazanej linii. Najczęstsze przyczyny to:

1. Brak średnika na końcu instrukcji
2. Niezamknięty nawias klamrowy lub okrągły
3. Pomylone cudzysłowy proste z polskimi typograficznymi
4. Niezamknięty komentarz /* bez */
5. Wklejony kod z bloga, gdzie spacje zostały zamienione na non-breaking space

Jeśli błąd pojawił się po wklejeniu snippetu z internetu – zawsze sprawdź, czy edytor nie zamienił prostych cudzysłowów na typograficzne. To powód numer jeden parse errorów na blogach polskich.

Gdy nie wiesz, który plik zepsuł stronę, wyłącz wszystkie wtyczki przez phpMyAdmin (kolumna option_value w wp_options dla active_plugins) lub przez WP-CLI:

`wp plugin deactivate --all --allow-root`

Następnie aktywuj po jednej i sprawdzaj, kiedy wraca błąd. To samo z motywem:

`wp theme activate twentytwentyfour --allow-root`

Jeśli motyw twentytwentyfour działa, problem leży w Twoim motywie. Gdy plugin to nie wina, a motyw też nie – winowajcą bywa custom snippet w functions.php lub mu-plugin. Pomocny jest tu wpis o problemach z wtyczkami WordPress – znajdziesz tam pełen workflow konfliktu wtyczek.

WooCommerce z 5000 produktów importujący feed dostawcy o 3:00 w nocy, aktualizator kopii zapasowych, generator PDF z fakturami – to klasyczne sytuacje, w których standardowe limity PHP są za niskie. Cztery parametry rządzą światem:

• memory_limit – ile RAM może użyć jeden proces PHP (typowo 128M, 256M, 512M)
• max_execution_time – ile sekund może działać skrypt (typowo 30, 60, 300)
• upload_max_filesize i post_max_size – maksymalny rozmiar pliku w uploadzie
• max_input_vars – limit pól formularza (ważne dla custom post types z dużymi metaboxami)

Gdzie to ustawić? Hierarchia od najwyższego do najniższego priorytetu:

1. Panel hostingu (CloudPanel, cPanel, DirectAdmin) – sekcja PHP Settings
2. Plik php.ini lub .user.ini w katalogu głównym strony
3. Plik .htaccess (tylko Apache, gdy włączone AllowOverride All)
4. wp-config.php poprzez ini_set() lub stałą WP_MEMORY_LIMIT

W wp-config.php, przed komentarzem kończącym sekcję edycji:

define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );

W php.ini:

memory_limit = 256M
max_execution_time = 300
upload_max_filesize = 64M
post_max_size = 64M
max_input_vars = 5000

Uwaga – niektóre tanie hostingi blokują nadpisywanie limitów z poziomu strony. Wtedy jedyna droga to ticket do supportu albo zmiana hostingu na taki jak CyberFolks, gdzie te ustawienia są elastyczne i przejrzyste w panelu.

Woluminowy import bądź eksport bazy często wymaga jeszcze zwiększenia mysql.connect_timeout i default_socket_timeout. Jeśli mimo zmian nadal masz timeouty – problem może leżeć w bazie, nie w PHP. Zerknij wtedy do przewodnika o problemach z bazą danych w WordPress.

Jeśli zarządzasz dużym sklepem, sprawdź też nasz przewodnik po optymalizacji WooCommerce oraz strony sklepów internetowych – tam znajdziesz konfigurację serwera dla 5000+ produktów.

Po przejściu na PHP 8.2 albo 8.3 logi zaczynają puchnąć od wpisów typu:

`PHP Deprecated: Creation of dynamic property MyClass::$foo is deprecated`
`PHP Deprecated: Using ${var} in strings is deprecated, use {$var} instead`
`PHP Deprecated: utf8_encode() is deprecated`

Deprecated notice nie psuje strony – PHP nadal wykonuje kod, tylko ostrzega, że w przyszłej wersji ta funkcja zniknie. Pytanie brzmi: ignorować czy naprawiać?

Kiedy można odpuścić:

• Wtyczka lub motyw są aktywnie rozwijane (autor wyda update w ciągu 3-6 miesięcy)
• Notice nie zalewa loga (mniej niż 100 wpisów dziennie)
• Strona działa stabilnie i nie planujesz natychmiastowego skoku do PHP 9

Kiedy trzeba reagować:

• Log puchnie do gigabajtów dziennie i zżera miejsce na dysku
• Notice pochodzi z porzuconej wtyczki bez updatów od 2 lat
• Planujesz migrację na PHP 8.4 lub 9.0 w najbliższych miesiącach
• Performance siada (każdy zapis do logu kosztuje I/O)

Dobra praktyka to wyłączenie zapisu deprecated do logu produkcyjnego, ale z monitoringiem na staging:

error_reporting( E_ALL & ~E_DEPRECATED & ~E_USER_DEPRECATED );

W wp-config.php można też przekierować WP_DEBUG_LOG na osobną ścieżkę poza wp-content, żeby logi nie zajmowały miejsca w katalogu strony. To samo zalecenie pojawia się w naszym wpisie o tym, dlaczego WordPress wolno się ładuje – nadmiarowe logowanie potrafi spowolnić stronę o kilkadziesiąt procent.

Zmiana wersji PHP to nie operacja na żywym organizmie. Robi się to w czterech etapach:

Etap 1: Audyt zgodności
Wtyczka PHP Compatibility Checker od WPEngine skanuje cały kod motywu i wtyczek pod kątem zgodności z wybraną wersją PHP. Lista błędów od razu pokazuje, co się posypie. Alternatywa: WP-CLI z wp plugin verify-checksums --all plus ręczny check changelogów.

Etap 2: Staging
Dobry hosting daje staging jednym kliknięciem (CyberFolks, LH.pl, Zenbox). Sklonuj produkcję, przełącz wersję PHP na docelową, przeklikaj kluczowe ścieżki: koszyk, checkout, formularz kontaktowy, panel admina, edytor postów. Dopiero gdy wszystko gra na stagingu, ruszasz produkcję.

Etap 3: Backup
Pełna kopia – pliki + baza. Nigdy nie zmieniaj wersji PHP bez backupu sprzed 5 minut. Jeśli coś pójdzie źle, restore zajmuje kwadrans, a brak backupu może kosztować dni pracy.

Etap 4: Switch + monitoring
W panelu hostingu zmieniasz wersję PHP. Pierwszy test: czy panel admina się ładuje. Drugi: czy frontend pokazuje zawartość. Trzeci: rzut oka w /wp-content/debug.log. Następne 24 godziny obserwujesz Google Search Console (błędy crawlowania), monitoring uptime (UptimeRobot, BetterStack) i logi serwera.

Najczęstsze pułapki:

• Zapomniana wtyczka cache pokazuje starą wersję strony – wyczyść cache po switchu
• OPcache trzyma stary skompilowany bytecode – restart PHP-FPM po deploy
• Stary autoloader Composera nie odświeża klas – usuń vendor/ i zainstaluj ponownie

Po udanej migracji warto przejrzeć poradnik o problemach z bezpieczeństwem WordPress – nowsza wersja PHP odsłania też nowe wektory ataku.

OPcache to wbudowany w PHP cache skompilowanego bytecode. Bez niego PHP parsuje i kompiluje każdy plik .php przy każdym requeście – z nim trzyma gotowy bytecode w pamięci RAM. Różnica wydajności na WordPressie to typowo 2-3x szybsze ładowanie panelu admina i 30-60% szybszy frontend.

Konfiguracja domyślna w PHP 8.3 jest sensowna, ale dla WordPress warto podkręcić:

opcache.enable=1
opcache.memory_consumption=256
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=20000
opcache.revalidate_freq=60
opcache.fast_shutdown=1
opcache.enable_cli=0
opcache.validate_timestamps=1

Kluczowe parametry:

• memory_consumption=256 – 256 MB na bytecode (dla sklepu z 50 wtyczkami)
• max_accelerated_files=20000 – ile plików może być w cache (WP + WooCommerce to ~12-15k plików)
• revalidate_freq=60 – co 60 sekund sprawdza, czy plik się zmienił

Na produkcji, po deploy nowej wersji wtyczki albo motywu, OPcache trzyma stary kod aż do upływu revalidate_freq. Rozwiązania:

1. opcache_reset() – funkcja PHP do wywołania ze skryptu admin
2. Restart PHP-FPM komendą sudo systemctl restart php8.3-fpm
3. Wtyczka OPcache Manager z dashboardem w admin WP

Problem: shared hosting czasem nie daje dostępu do opcache_reset() ani restartu FPM. Wtedy zostaje czekanie na revalidację albo prośba do supportu. Jeszcze jeden powód, by hostować na czymś rozsądnym – CyberFolks ma OPcache aktywne domyślnie i daje dostęp do flush przez panel.

Więcej o przyspieszaniu znajdziesz w poradniku o cache w WordPress – OPcache to tylko jeden z czterech poziomów cache (browser, page, object, opcode).

OPcache współpracuje też z Redis Object Cache – konfigurację pokazujemy w wpisie Redis i Memcached w WordPress. Dla pełnej diagnostyki wydajności użyj wtyczki Query Monitor – więcej w tekście o debugowaniu WordPress.

Wybór serwera WWW wpływa na to, jak PHP obsługuje requesty. Apache historycznie dominował w hostingach shared, bo prosty .htaccess pozwalał użytkownikom konfigurować przekierowania bez dostępu do globalnej konfiguracji. Nginx wszedł do gry jako lżejszy i szybszy.

Apache + mod_php
Klasyczny model: każdy request to osobny worker Apache z załadowanym modułem PHP. Prosty, działa od zawsze, ale ciężki – każdy worker zżera 30-50 MB RAM nawet jeśli serwuje obrazek.

Apache + PHP-FPM
Apache deleguje requesty PHP do osobnego procesu FPM (FastCGI Process Manager). Lżejsze, oddziela serwowanie statyków od PHP. Częste w nowoczesnych hostingach.

Nginx + PHP-FPM
Najwydajniejsze. Nginx nie ma .htaccess (przekierowania w głównym configu), serwuje statyki bez wołania PHP, deleguje tylko .php do FPM. Typowo 2-3x mniejsze zużycie RAM przy tej samej liczbie requestów.

Konfiguracja PHP-FPM dla WordPressa to balans:

• pm = dynamic (lub ondemand dla niskiego ruchu, static dla wysokiego)
• pm.max_children = 20-50 (zależnie od RAM serwera, każdy child to ~50 MB)
• pm.max_requests = 500 (recyklowanie procesu po 500 requestach – chroni przed memory leak)
• request_terminate_timeout = 300s (kill długich procesów)

Dla małej strony bloga 5-10 children wystarczy. Dla sklepu z 1000 wizyt dziennie celuj w 30-50. Dla większego ruchu zwykle przerzuca się część warstwy frontend na Cloudflare albo Varnish, żeby PHP w ogóle nie wchodził w grę dla cache'owalnych stron.

Dla większości właścicieli bloga i małego sklepu wybór nie jest do zrobienia – hosting decyduje za Ciebie. Jeśli jednak masz VPS lub serwer dedykowany, Nginx + PHP-FPM 8.3 to dziś standard. Powiązany temat: problemy z WP-Cron i schedulerem WordPress – konfiguracja FPM ma na to bezpośredni wpływ.

Każda kolejna wersja PHP od 7.0 wzwyż przynosi 5-15% szybsze wykonanie kodu w benchmarkach syntetycznych. Ile z tego widać w WordPressie? Sprawdziliśmy na sklepie WooCommerce z 2500 produktami i 12 wtyczkami:

PHP 8.3 vs 8.2 to średnio 12-18% szybciej. PHP 8.4 dorzuca jeszcze 3-5%, ale wciąż wiele wtyczek nie deklaruje pełnej kompatybilności.

Dlaczego warto?

• Szybszy admin = mniej frustracji edytora
• Niższy TTFB = lepszy Largest Contentful Paint w Core Web Vitals
• Krótsze importy/eksporty = mniej timeoutów
• Lepsze wykorzystanie tych samych zasobów serwera

Gdzie jest haczyk?

PHP 8.2 wprowadziło Random\Randomizer – kilka starszych wtyczek SEO i caching używało własnych mechanizmów random, które przestały działać. PHP 8.3 wymusza explicit return type w niektórych przypadkach, co psuje ~5% legacy kodu z 2018-2020.

Reguła praktyczna: zaktualizowany ekosystem WordPress (rdzeń + wtyczki + motyw świeższe niż 12 miesięcy) działa na PHP 8.3 bez problemów. Jeśli masz starsze customizacje albo motyw kupiony w 2019, najpierw test na staging.

Chcesz zobaczyć więcej praktycznych testów? W naszym wpisie o tym, dlaczego WordPress wolno się ładuje, pokazujemy też, jak zmierzyć faktyczny zysk po przejściu na nowsze PHP w Twoim sklepie.

Jeśli planujesz pełny audyt techniczny, zerknij na nasze usługi pozycjonowanie SEO – Core Web Vitals to dziś jeden z głównych czynników rankingowych.

Większość problemów PHP w WordPress da się rozwiązać samemu w 2 godziny: aktualizacja wtyczki, podbicie limitu, switch wersji. Ale są sytuacje, w których próba samodzielnej naprawy kosztuje więcej niż faktura developera.

Kiedy zostaw to specjaliście:

1. Custom functions w functions.php motywu – jeśli ktoś dopisał 200 linii kodu do motywu, a Ty nie wiesz, co który robi, nie ruszaj. Jeden źle usunięty fragment psuje checkout albo formularz lead generation.
2. Integracje z zewnętrznymi API (Subiekt, Comarch, BaseLinker, własny CRM) – gdy padają po zmianie PHP, błąd najczęściej jest w autentykacji albo serializacji danych. Diagnoza wymaga znajomości obu stron.
3. Migracja legacy code z PHP 5.6/7.0 – kod sprzed 8 lat to mina. Klasy bez typów, mysql_*, brak namespace, brak Composer. Refactoring to projekt na 20-80 godzin.
4. Sklep WooCommerce z 5000+ produktów i custom logiką – każda zmiana wersji PHP może zepsuć rzeczy, których nie widać w pierwszej godzinie.
5. Strona generuje powyżej 50 tys. zł miesięcznego przychodu – ryzyko downtime przewyższa koszt godziny developera (zwykle 150-300 zł netto).

Sygnały, że pora dzwonić:

• Spróbowałeś dwóch rozwiązań z Google i strona dalej leży
• Logi pokazują błędy w plikach, których nazw nie rozpoznajesz
• Nie masz aktualnego backupu sprzed problemu
• Strona jest źródłem dochodu i każda godzina downtime to konkretne pieniądze

W KC Mobile zajmujemy się migracjami PHP, optymalizacją WordPress i WooCommerce oraz custom developmentem od ponad 20 lat. Audyt sytuacji jest bezpłatny – wystarczy mail lub telefon +48 604 939 140, opowiesz, co się dzieje, dostaniesz wycenę naprawy bez zobowiązań. Jeśli sprawa jest pilna, skorzystaj z formularza kontaktowego – odpowiadamy zwykle w 1-2 godziny w dzień roboczy.