Jak zainstalować lub zmienić PHP dla WordPress

Przeglądarka wysyła żądanie, serwer przekazuje odpowiednią pracę do PHP, a kod WordPress odczytuje dane i przygotowuje odpowiedź. Użytkownik otrzymuje wynik, zwykle HTML, a nie pliki źródłowe wykonywane przez interpreter. Wtyczka może wyświetlić informacje o środowisku, lecz nie zastępuje instalacji PHP obsługującej serwer WWW.

Na hostingu współdzielonym wersją najczęściej zarządzasz w panelu dostawcy. Na serwerze VPS administrator odpowiada dodatkowo za pakiety, usługę PHP-FPM, przypisanie domeny i konfigurację serwera WWW. W hostingu zarządzanym część tych ustawień może być niedostępna dla właściciela strony. Wtedy zlecenie zmiany wymaga uzgodnienia z obsługą hostingu.

Zacznij od wskazania konkretnej domeny i środowiska. Jedno konto hostingowe może obsługiwać kilka witryn, a zmiana ustawienia dla całego konta może dotknąć każdej z nich. Przy wdrożeniu WordPress warto zapisać odpowiedzialność za środowisko PHP już w dokumentacji odbiorowej: kto aktualizuje PHP, kto sprawdza zgodność aplikacji i kto reaguje na błąd.

W panelu WordPress otwórz Narzędzia → Stan witryny → Informacje i odszukaj dane serwera. Zapisz wersję PHP oraz podstawowe limity. Porównaj je z ustawieniem domeny w panelu hostingu. Rozbieżność może wynikać z konfiguracji konkretnego katalogu, innej usługi lub niezastosowanej zmiany.

Terminal dostarcza osobnej informacji. Polecenia poniżej służą do odczytu środowiska CLI; nie zmieniają wybranej wersji dla domeny:

php -v
php --ini
php -m

Pierwsze pokazuje wersję interpretera znalezionego w ścieżce powłoki, drugie pliki konfiguracji, trzecie załadowane moduły. Wynik PHP 8.4 w terminalu nie dowodzi, że żądania WWW również obsługuje PHP 8.4. Zadanie cron lub WP-CLI może korzystać z innego pliku wykonywalnego niż PHP-FPM.

Nie zostawiaj publicznego pliku z pełnym phpinfo jako stałego elementu witryny. Ujawnia konfigurację środowiska i może pokazać dane niepotrzebne odwiedzającym. Do diagnozy wykorzystaj panel, informacje WordPress albo czasowo ograniczony dostęp techniczny. Porównuj ustawienia tego samego środowiska, a nie lokalnego komputera z produkcją.

Rozdziel cztery pytania: czy interpreter uruchomi rdzeń, co rekomenduje WordPress, czy dana gałąź PHP otrzymuje poprawki i czy działa na niej Twoja aplikacja. Wymagania WordPress wskazują PHP 8.3 lub nowsze jako rekomendację. Wymienione tam starsze minimum techniczne nie stanowi zalecenia dla nowego wdrożenia.

Macierz WordPress i PHP pomaga sprawdzić zależność od wersji rdzenia. Dokumentacja zastrzega, że zestawienie wersji dostępnych w chwili wydania nie jest obietnicą pełnej zgodności każdego rozszerzenia. Osobno sprawdź dokumentację motywu, bramki płatniczej, mechanizmu faktur i własnego kodu.

Według cyklu wsparcia PHP, sprawdzonego 14 września 2026 r.:

Wybierz wspieraną gałąź z aktualnym wydaniem poprawkowym i potwierdzoną zgodnością. Nie traktuj samej obecności PHP w panelu hostingu jako dowodu wsparcia producenta. Jeżeli stara wtyczka blokuje przejście, ustal sposób jej aktualizacji lub wymiany, zamiast bezterminowo utrzymywać zależność od wygasłego środowiska.

Staging powinien możliwie wiernie odtwarzać wersje kodu i konfigurację produkcji. Lokalna instalacja pomaga znaleźć błędy składni czy niezgodne wywołania, ale może mieć inne rozszerzenia i limity. Różnice opisujemy w poradniku WordPress na localhost. Kopię testową odłącz od prawdziwych wysyłek, płatności i automatyzacji klienta.

Przed zmianą zapisz wersję PHP, sposób uruchamiania, ustawienia domeny i wymagane rozszerzenia. Przygotuj kopię plików oraz bazy i sprawdź możliwość jej odtworzenia. Dostęp do panelu hostingu powinien działać niezależnie od WordPress, ponieważ awaria aplikacji może odciąć wp-admin.

Z góry określ zakres operacji. Jeżeli zmieniasz wyłącznie interpreter, powrót do poprzedniej konfiguracji PHP może wystarczyć do wycofania tej zmiany. Jeśli równolegle aktualizujesz wtyczkę lub uruchamiasz migrację danych, samo cofnięcie PHP nie przywróci wcześniejszych plików ani bazy.

W działającym sklepie odtworzenie starej bazy może usunąć późniejsze zamówienia. Dlatego plan powrotu musi uwzględniać nowe dane i czas wykonania kopii. Szerszą procedurę opisuje poradnik aktualizacji WordPress.

Nazwy ekranów zależą od dostawcy: mogą mówić o wersji PHP, konfiguracji domeny albo ustawieniach interpretera. Nie zakładaj, że przycisk zmienia tylko otwartą stronę. Przed zapisaniem sprawdź domenę, katalog dokumentów i zakres ustawienia.

1. Odczytaj obecną konfigurację i potwierdź gotowość kopii.
2. Wybierz przetestowaną gałąź oraz sprawdź przypisane jej moduły.
3. Zapisz zmianę zgodnie z instrukcją dostawcy.
4. Odczytaj wersję przez WordPress i przetestuj żądanie, które omija cache strony.
5. Porównaj działanie najważniejszych funkcji oraz świeże wpisy w logach.

Na VPS potrzebna jest instrukcja dopasowana do systemu operacyjnego, repozytoriów i architektury usług. Uniwersalne polecenie instalacji pakietu nie rozwiązuje przypisania puli PHP-FPM, uprawnień ani konfiguracji serwera WWW. Nie kopiuj komend dla innej dystrybucji tylko dlatego, że zawierają właściwy numer PHP.

Uzgodnij również zmianę interpretera używanego przez zadania cykliczne. Działająca strona i niedziałający import magazynu to nadal nieudane wdrożenie. Zapisz wynik zmiany oraz osobę odpowiedzialną za dalszą obserwację.

Zmiana gałęzi może oznaczać inną listę modułów lub inny plik konfiguracji. Błąd po przełączeniu nie musi wynikać z niezgodności języka: aplikacja może nie widzieć potrzebnego rozszerzenia albo otrzymać inny limit pamięci.

Porównaj obsługę połączenia z bazą, przetwarzania obrazów, żądań HTTP i archiwów. Konkretne wymagania wynikają z używanych funkcji WordPress oraz rozszerzeń. Lista modułów z CLI nie zastępuje sprawdzenia środowiska WWW. Podobnie zwiększenie memory_limit w jednym pliku nie dowodzi zmiany limitu w puli obsługującej witrynę.

Zapisz wartości upload_max_filesize, post_max_size, memory_limit i limitów wykonania potrzebnych w Twoim procesie. Nie zwiększaj ich bez diagnozy do przypadkowo dużych liczb. Import dużego katalogu i zwykłe otwarcie strony mają różne wymagania, a ograniczenia mogą istnieć również w serwerze WWW lub pośredniczącym proxy.

Po zmianie sprawdź import obrazu, zapis edytora i reprezentatywny import danych na środowisku testowym. Zachowaj prywatność logów: komunikaty błędów nie powinny pojawiać się w publicznej odpowiedzi strony. Konfiguracja OPcache także wymaga kontroli administratora, szczególnie gdy kod po wdrożeniu wygląda na nieodświeżony.

Otworzenie strony głównej nie jest pełnym testem. Cache może zwrócić gotowy HTML, mimo że dynamiczne żądanie kończy się błędem. Sprawdź panel, zapis treści, wyszukiwanie i formularz w trybie testowym. W sklepie przejdź ścieżkę wyboru wariantu, koszyka i testowej płatności, bez uruchamiania prawdziwych wysyłek czy obciążenia karty.

Porównuj logi z godziną wykonania operacji. Zapisz pierwszy błąd krytyczny, plik i wywołanie; sam komunikat w przeglądarce zwykle nie wskazuje źródła. Ostrzeżenia o przestarzałych funkcjach wymagają oceny, ale nie są tym samym co przerwanie działania interpretera. Procedurę zawężania przyczyny znajdziesz w debugowaniu WordPress.

Jeżeli pojawiła się awaria, wycofaj zmianę środowiska PHP według przygotowanego planu i ponownie sprawdź aplikację. Nie przywracaj odruchowo starej bazy, gdy zmieniono tylko PHP. Zidentyfikuj problematyczny komponent na stagingu i przygotuj poprawkę przed kolejną próbą.

Gdy potrzebujesz pomocy, prześlij opis konfiguracji i objawu, bez haseł i pełnego zrzutu danych klientów. Przydatne są wersje, godzina zmiany i zanonimizowany komunikat błędu. Dalsza opieka może obejmować mały pakiet godzinowy; zakres, reakcję i warunki SLA ustalamy indywidualnie.

• Serwer pod WordPress: jak dobrać parametry i przygotować środowisko
• Jak skonfigurować zadania cron dla WordPressa i sprawdzić, czy działają