Problemy z PHP w WordPress: diagnoza i kontrolowana naprawa

Wersję PHP dobierz jednocześnie do okresu wsparcia i zgodności używanego kodu. Według oficjalnego harmonogramu PHP na 14 września 2026 r. PHP 8.2 i 8.3 mają wsparcie obejmujące poprawki bezpieczeństwa, natomiast 8.4 i 8.5 pozostają w okresie aktywnego wsparcia. Aktywne wsparcie 8.3 zakończyło się 31 grudnia 2025 r., a poprawki bezpieczeństwa przewidziano do 31 grudnia 2027 r.

Wymagania WordPressa, WooCommerce i wtyczek mogą się różnić. Dokumentacja serwera WooCommerce odnosi wymagania do wskazanej wersji sklepu. Zgodność starszego kodu z interpreterem nie jest tym samym co dalsze wsparcie bezpieczeństwa interpretera. Z kolei obecność najnowszej wersji w panelu hostingu nie dowodzi zgodności wszystkich rozszerzeń.

Przed wyborem sporządź listę rdzenia, motywu, wtyczek i własnych fragmentów PHP. Sprawdź deklaracje autorów, wymagane rozszerzenia PHP oraz rzeczywiste próby na kopii. Aktualizacja nie ma gwarantowanego procentu przyspieszenia. Jeżeli celem jest wydajność, porównaj ten sam proces na tych samych danych i warunkach, oddzielając odczyt z cache od wykonania PHP.

Zapisz godzinę wystąpienia, adres i czynność użytkownika. Log serwera może zawierać błędy różnych aplikacji, dlatego pojedynczy wpis bez kontekstu łatwo przypisać do niewłaściwego zdarzenia. Sprawdź, czy problem dotyczy tylko panelu, określonej podstrony czy również zadań wykonywanych w tle. Potrzebny jest log środowiska obsługującego tę czynność, nie dowolny plik o nazwie error.log.

WordPress może korzystać z WP_DEBUG_LOG, a hosting udostępniać własne logowanie PHP. Nie pokazuj szczegółów błędów publicznym odwiedzającym. Plik diagnostyczny przechowuj poza publicznym katalogiem lub zabezpiecz przed odczytem z internetu. Ogranicz dostęp, czas przechowywania i zakres danych. Przed przekazaniem fragmentu usuń hasła, tokeny oraz dane klientów.

Przykładowy komunikat Call to undefined function get_field wskazuje na wywołanie niedostępnej funkcji. Może chodzić o zależność ACF, kolejność ładowania lub sposób odwołania do funkcji. Sama nazwa nie dowodzi, że wystarczy aktywować jedną wtyczkę. Plik i linia wskazują miejsce ujawnienia problemu, nie zawsze jego pierwotną przyczynę. Gdy widzisz pusty ekran, pomocny jest też poradnik o diagnozie WSOD.

Fatal error oznacza błąd przerywający dany przebieg wykonania. W komunikacie może pojawić się brak funkcji, nieobsłużony wyjątek lub wyczerpana pamięć. Te przypadki wymagają różnych działań. Aktualizacja wtyczki może usunąć konkretny błąd, ale bez potwierdzenia nie zakładaj, że rozwiąże dowolny problem PHP.

Parse error dotyczy składni. Może pojawić się podczas ładowania konkretnego pliku, nawet jeśli wcześniejsza część programu zdążyła wykonać inne operacje. Po ręcznej edycji porównaj zmianę i sprawdź składnię właściwym interpreterem. Lint sprawdza składnię bez uruchamiania logiki aplikacji; nie potwierdza zgodności zależności ani działania formularza. Własne fragmenty porządkuj zgodnie z zasadami dodawania kodu do WordPressa.

Deprecated informuje o zachowaniu wycofywanym z użycia. W zwykłym trybie sam komunikat nie zatrzymuje programu, lecz własny handler błędów, publiczny wydruk lub nadmierne logowanie mogą wpływać na rezultat. Dokumentacja zmian PHP 8.1 opisuje między innymi utratę precyzji przy niejawnej konwersji float do int. Nie jest to uniwersalny fatal error. Nie ustalaj arbitralnego progu ostrzeżeń, poniżej którego można zignorować niezgodność. Zapisz źródło, wpływ i plan poprawki zamiast traktować wyciszenie jako naprawę.

Allowed memory size exhausted wskazuje na osiągnięcie limitu pamięci w danym wykonaniu. Sprawdź efektywny limit i operację, która do niego doszła. Duży import może wymagać podziału pracy na porcje; zapętlony kod nie stanie się poprawny po przydzieleniu kolejnych zasobów. Szczegółową diagnozę znajdziesz w poradniku o PHP memory limit.

Limit czasu może pochodzić z PHP, serwera pośredniczącego albo zewnętrznego połączenia. Rozróżnij przerwanie skryptu od oczekiwania na odpowiedź bazy czy API. Samo zwiększenie max_execution_time nie zmieni wszystkich pozostałych ograniczeń. Podobnie upload_max_filesize dotyczy pliku, a post_max_size całego żądania, które zawiera również narzut i pozostałe pola.

Nie ma uniwersalnej hierarchii ustawień panelu, php.ini, .htaccess i wp-config.php. Dostępność zmiany zależy od SAPI oraz trybu konkretnej dyrektywy. To, co odczytasz w CLI, może różnić się od procesu obsługującego stronę. Przed zmianą potwierdź właściwe środowisko z administratorem hostingu. Nie kopiuj starych dyrektyw rozszerzenia mysql do współczesnej konfiguracji mysqli ani całego zestawu wysokich limitów z przypadkowego poradnika.

Przygotuj spójną kopię plików i bazy oraz sprawdzony sposób odtworzenia. Kopia sprzed zmiany nie gwarantuje, że późniejsze zamówienia lub edycje da się bezpiecznie zastąpić. Ustal punkt przywrócenia i sposób zachowania danych powstałych w trakcie prac. Do próby użyj środowiska, które nie wysyła prawdziwych wiadomości, płatności ani zgłoszeń do integracji.

Na kopii porównaj wersję PHP, rozszerzenia i efektywne ustawienia z planowaną produkcją. Sprawdź krytyczne ścieżki: panel, edycję, wyświetlanie treści oraz operacje zależne od wtyczek. Testy formularzy i sklepu muszą korzystać z przechwyconych wysyłek lub odpowiedniego sandboxa. Samo otwarcie strony głównej może ominąć kod, który uruchamia się dopiero przy zapisie lub zadaniu cyklicznym.

Sumy kontrolne potwierdzają zgodność plików z danym wzorcem, nie kompatybilność z PHP. Skan statyczny również nie zastępuje prób działania. Zmieniaj jeden rozpoznany czynnik naraz; nie wyłączaj wszystkich wtyczek na produkcji jako ogólnej metody naprawy. W obsłudze WordPressa plan odbioru i wycofania powinien powstać przed przełączeniem wersji, a wynik pozostać zapisany dla osoby przejmującej utrzymanie.

OPcache przechowuje skompilowany kod PHP. Po zmianie plików sposób odświeżenia zależy od konfiguracji procesu i wdrożenia. Dokumentacja OPcache opisuje dyrektywy oraz ich dostępność w wersjach; opcache.fast_shutdown usunięto w PHP 7.2, więc nie należy dopisywać go do konfiguracji współczesnej instalacji.

OPcache w CLI nie jest automatycznie tym samym cache co w PHP-FPM. Restart wspólnej usługi może wpłynąć na inne witryny. Nie publikuj otwartego skryptu opcache_reset i nie traktuj restartu jako neutralnej pierwszej próby. Administrator powinien ustalić zakres puli, sposób wdrażania kodu oraz właściwe odświeżenie. Parametry liczby procesów FPM dobiera się do obciążenia i zasobów, nie wyłącznie liczby wizyt.

Do wsparcia przekaż wersje, czas zdarzenia, oczekiwany rezultat, zanonimizowany log i listę już wykonanych działań. Jeśli problem dotyczy własnego kodu lub integracji, zapisz także zależności. Skontaktuj się z KC Mobile, aby ustalić zakres diagnozy i naprawy. Dalsza obsługa może obejmować małe pakiety godzinowe. Zakres prac oraz warunki SLA ustalamy indywidualnie, na podstawie potrzeb witryny.