PHP 7 jest już nieobsługiwane, więc dalsze korzystanie z niego zwiększa ryzyko ataku. Sama zgodność wtyczki z PHP 7.4 nie oznacza jednak, że zadziała na PHP 8.3. Najbezpieczniej sprawdzić ją na stagingu, używając WP-CLI i logów PHP, zanim zmienisz wersję środowiska na produkcji.
Dlaczego PHP 7 to problem?
Wersje PHP 7.x nie otrzymują już standardowych poprawek bezpieczeństwa. Strona może działać bez widocznych problemów, ale używa środowiska, którego nie powinno się traktować jako docelowego dla aktywnego serwisu.
Przejście na PHP 8.x nie jest jednak wyłącznie zmianą numeru wersji. W PHP 8 zmieniono część zachowań języka, obsługę typów danych oraz funkcji oznaczonych wcześniej jako przestarzałe. W rezultacie kod działający w PHP 7.4 może generować ostrzeżenia albo zatrzymać wykonanie w PHP 8.3.
Informacja „kompatybilne z PHP 7” nie jest certyfikatem działania w nowoczesnym środowisku. Szczególnej uwagi wymagają wtyczki, których autorzy od dawna nie publikują aktualizacji, oraz rozszerzenia zawierające własne, stare biblioteki i SDK.
Nie zmieniaj PHP bez testu na kopii strony. Staging może wydłużyć przygotowanie migracji, ale chroni produkcję przed przestojem i utratą funkcji.
Jak sprawdzić wtyczki przed przejściem na PHP 8.3?
WP-CLI pozwala szybko przygotować listę aktywnych wtyczek i obserwować błędy podczas ich ładowania. Polecenia wykonuj na środowisku stagingowym, nie na stronie obsługującej użytkowników.
Podstawowa procedura wygląda tak:
- Sprawdź wersję PHP – uruchom
php -vi potwierdź, z jakiego środowiska korzysta staging. - Zapisz aktywne wtyczki – użyj
wp plugin list --status=active --format=csv > active-plugins.csv. - Włącz logowanie na stagingu – ustaw
WP_DEBUGiWP_DEBUG_LOGnatrue, aWP_DEBUG_DISPLAYnafalse. - Przetestuj ładowanie rozszerzeń – po zmianie PHP uruchom
wp plugin deactivate --all, a następniewp plugin activate --all 2>&1 | tee plugin-test.log. - Przejrzyj logi – sprawdź plik
wp-content/debug.logoraz log PHP udostępniany przez hosting.
Jeżeli nie chcesz wyłączać wszystkich rozszerzeń naraz, możesz aktywować je pojedynczo. Przy większej liczbie wtyczek szybsze będzie dzielenie ich na grupy, a następnie zawężanie zestawu po znalezieniu błędu.
W logu zwróć uwagę na typ komunikatu, ponieważ ostrzeżenie i błąd krytyczny wymagają innej reakcji:
| Typ problemu | Co oznacza | Działanie |
|---|---|---|
| Deprecated lub ostrzeżenie | Wtyczka używa starego sposobu działania, ale strona może nadal odpowiadać. | Zaktualizuj wtyczkę i obserwuj log. Nie ignoruj dużej liczby takich komunikatów. |
| Fatal error | Wykonanie kodu zostało przerwane, a część strony lub cała witryna może przestać działać. | Ustal wtyczkę wskazaną w ścieżce błędu, wyłącz ją i przywróć działającą wersję środowiska. |
| Uncaught Error | Kod wywołał nieobsługiwaną sytuację, często z podanym plikiem i numerem linii. | Sprawdź wskazany plik, wersję wtyczki i zgłoszenia autora przed ponowną aktywacją. |
Komunikaty takie jak Deprecated: Creation of dynamic property mogą nie wyłączyć strony od razu, ale wskazują na stary kod. W PHP 8.3 podobne miejsca mogą wymagać aktualizacji. Sam brak błędu podczas aktywacji nie wystarcza, dlatego sprawdź też frontend, panel administracyjny, formularze, płatności i zadania cron.
Co zrobić, gdy wtyczka nie działa?
Po znalezieniu winowajcy nie zaczynaj od ręcznej edycji plików. Najpierw ustal, czy problem ma znane rozwiązanie i czy autor nadal utrzymuje rozszerzenie. Możliwe ścieżki są następujące:
- Aktualizacja – zainstaluj najnowszą wersję wtyczki i sprawdź jej wymagania dotyczące PHP oraz WordPressa.
- Zamiennik – wybierz utrzymywane rozszerzenie, jeśli obecne nie działa na PHP 8.x albo autor nie reaguje na zgłoszenia.
- Ręczna poprawka – rozważ ją tylko wtedy, gdy znasz PHP, masz testy i możesz utrzymywać własną wersję po kolejnych aktualizacjach.
- Usunięcie – usuń wtyczkę, która nie jest potrzebna albo od lat nie otrzymała aktualizacji.
Wtyczki nieutrzymywane od kilku lat są ryzykiem nie tylko podczas migracji PHP. Mogą zawierać znane luki i kolidować z kolejnymi wersjami WordPressa. Dla użytkownika bez doświadczenia programistycznego bezpieczniejszym rozwiązaniem jest wymiana lub usunięcie rozszerzenia niż poprawianie jego kodu na stronie produkcyjnej.
Jak bezpiecznie przeprowadzić migrację?
Staging powinien być kopią produkcji z osobną bazą danych i plikami. Na nim najpierw zmień PHP na planowaną wersję, na przykład PHP 8.3, a następnie wykonaj testy. Kolejność ogranicza ryzyko, ale nie zastępuje kopii zapasowej.
Przed zmianą na produkcji przejdź przez tę listę:
- Backup – wykonaj kopię bazy danych i katalogu
wp-content, a pliki przechowuj poza publicznym katalogiem strony. - Staging – sklonuj witrynę, zmień na niej PHP i sprawdź działanie wtyczek przez WP-CLI.
- Testy funkcji – sprawdź stronę główną, podstrony, logowanie, formularze, wysyłkę poczty, sklep i zadania cron, jeśli są używane.
- Aktualizacje – zaktualizuj wtyczki przed migracją rdzenia, ale testuj każde większe rozszerzenie po zmianie PHP.
- Rollback – przygotuj sposób przywrócenia bazy, plików i poprzedniej wersji PHP.
Dopiero po pozytywnych testach zmień PHP na produkcji. Jeśli strona przestanie działać, nie usuwaj pochopnie plików. Odczytaj ostatni wpis w debug.log, wyłącz wskazaną wtyczkę przez WP-CLI lub tymczasowo zmień nazwę katalogu wp-content/plugins, a następnie przywróć poprzednią wersję PHP i backup, jeśli problem dotyczy większej części witryny.
Najbezpieczniejszy plan to backup, staging, testy na PHP 8.3 i dopiero potem produkcja. Wtyczka działająca na PHP 7.4 może wymagać aktualizacji, zastąpienia albo usunięcia, zanim migracja będzie gotowa.
