Wtyczka wymaga nowszego PHP, niż masz

Objaw

Wtyczka włączyła się bez protestu i działa od miesięcy. W jej nagłówku stoi Requires PHP: 8.1. Serwer ma 8.0. Nic w sklepie nie wygląda źle.

Dzieje się tak, bo wymaganie jest egzekwowane wyłącznie w chwili instalacji przez panel WordPressa. Wtyczka wgrana przez FTP, przywrócona z kopii zapasowej, skopiowana przy migracji albo zainstalowana zanim serwer zszedł na starsze PHP, omija to sprawdzenie w całości — a raz aktywna, nie jest sprawdzana ponownie.

Ile to kosztuje

Niezgodne PHP nie psuje się stopniowo. Psuje się na dokładnie tym żądaniu, które jako pierwsze dojdzie do linii ze składnią nieznaną interpreterowi, a błąd parsowania jest krytyczny:

• Awaria jest białym ekranem, nie pogorszeniem. PHP nie umie sparsować pliku częściowo. Strona wczytująca ten plik zwraca 500, a jeśli plik ładuje się przy każdym żądaniu — cały sklep.
• Czeka na rzadką ścieżkę kodu. Nowa składnia może siedzieć w obsłudze zwrotów, w liczeniu podatku dla jednego kraju albo na ekranie, który otwierasz dwa razy do roku. Jeszcze nie wystrzeliła.
• Wystrzeli przy aktualizacji. Aktualizacja wtyczki to właśnie moment, w którym ląduje nowy kod, więc najbardziej prawdopodobna chwila na tę awarię to chwila, w której i tak coś zmieniasz.
• Miejsce ma znaczenie. Jeśli błąd krytyczny jest w płatności albo w koszyku, dowiadujesz się od klientów.

Jak to sprawdzić samodzielnie

WP-CLI czyta nagłówki wtyczek, a PHP podaje własną wersję:

php -r 'echo PHP_VERSION, "\n";'
wp plugin list --status=active --fields=name,version --format=table

Samo wymaganie stoi w nagłówku głównego pliku każdej wtyczki:

grep -ri "Requires PHP" wp-content/plugins/*/*.php | grep -v "Requires PHP: *$"

Porównaj każdy wynik z działającą wersją. WordPress pokazuje to również w Narzędzia → Stan witryny, ale wyłącznie dla wtyczek, które sam zainstalował.

Jak naprawić

1. Podnieś PHP, zamiast cofać wtyczkę. Każde wspierane wydanie PHP jest szybsze od poprzedniego, a sklep na 8.0 jest już poza własnym oknem bezpieczeństwa.
2. Przetestuj najpierw na kopii testowej, z wszystkimi wtyczkami aktywnymi. Awarie, których szukasz, to te pojawiające się tylko na konkretnych ekranach.
3. Jeśli wtyczka nie umie działać na nowszej wersji, to ona — a nie serwer — jest rzeczą do wymiany. Wtyczka, która nie nadąża za PHP, nie jest utrzymywana.
4. Sprawdzaj po każdej migracji. Przeniesienie witryny na nowy hosting to najczęstszy sposób, w jaki ta niezgodność powstaje.

Kiedy to fałszywy alarm

• Wtyczki z błędnym albo nieaktualnym nagłówkiem. Część autorów podnosi Requires PHP asekuracyjnie, zanim faktycznie użyje nowszej składni. Deklaracja jest obietnicą wsparcia, nie zawsze wymaganiem technicznym.
• Ścieżki kodu, które w Twojej konfiguracji nigdy się nie wykonują — wtyczka, której nowsza składnia siedzi wyłącznie w integracji, której nie włączyłeś.
• Hostingi z różnymi wersjami PHP dla wiersza poleceń i dla serwera WWW. Sprawdzaj wersję używaną przez serwer WWW, nie tę, którą podaje Twoja powłoka.

Jak znajduje to Merchlint

Merchlint odczytuje nagłówek Requires PHP każdej aktywnej wtyczki i aktywnego motywu, po czym porównuje go z wersją PHP obsługującą żądanie — nie z wersją z wiersza poleceń, która bywa inna. Zgłasza każdą niezgodność z obiema liczbami oraz z informacją, czy wtyczka ładuje się przy żądaniach sklepu, czy tylko w panelu, bo to przesądza, czy ryzykiem jest niedziałający sklep, czy niedziałające zaplecze.

To samo znalezisko wypisuje również wtyczki niedeklarujące wymagania w ogóle, niżej w kolejności — to brak informacji, a nie niezgodność.

Pewność: F — fakt ze środowiska. Jeden numer wersji jest niższy od drugiego.

Ta kontrola jest w dodatku Pro.