Zmiana wersji PHP dla WordPressa. Jak przetestować ją przed przełączeniem?

Firma hostingowa przysyła wiadomość, że stara wersja PHP zostanie wkrótce wyłączona, albo w kokpicie WordPressa pojawia się ostrzeżenie „Zalecana aktualizacja PHP”. Sama zmiana to zwykle jedno pole w panelu hostingu i kilka sekund pracy. Kłopot polega na tym, że nikt z góry nie wie, czy po przełączeniu wszystkie wtyczki i motyw nadal będą działać.

Ta instrukcja jest przeznaczona dla właścicieli firm i osób, które samodzielnie opiekują się witryną na WordPressie, także ze sklepem. Pokazuje, jak sprawdzić nową wersję PHP na kopii witryny, zanim zobaczą ją klienci, i jak przeprowadzić samo przełączenie tak, aby w razie kłopotu wrócić do poprzedniego stanu w kilka minut.

Po lekturze czytelnik będzie umiał ustalić, której wersji PHP używa witryna, wybrać wersję docelową, przygotować kopię testową, odczytać dziennik błędów i rozpoznać, które wpisy są groźne, a które tylko informują o przyszłych zmianach.

Po czym poznać, że pora zmienić wersję PHP, i co może pójść źle?

PHP to język, w którym napisany jest WordPress, jego wtyczki i motywy. Serwer uruchamia ten kod w konkretnej wersji PHP, a wersję wybiera się w panelu hostingu. Każda kolejna wersja działa sprawniej i dostaje poprawki bezpieczeństwa, ale też usuwa stare funkcje języka, z których dawno pisany kod wciąż może korzystać.

Sygnałów, że zmiana jest potrzebna, jest kilka i zwykle pojawiają się razem:

• w kokpicie widać ostrzeżenie „Wymagana aktualizacja PHP” albo „Zalecana aktualizacja PHP”,
• narzędzie „Kondycja witryny” zgłasza, że witryna działa na przestarzałej wersji PHP i zalicza to do spraw bezpieczeństwa,
• hosting zapowiada wyłączenie starej wersji albo dopłatę za jej dalsze utrzymywanie,
• nowa wersja WordPressa, wtyczki lub motywu nie chce się zainstalować, bo wymaga nowszego PHP.

Co najczęściej psuje się po przełączeniu?

Sam WordPress rzadko sprawia kłopot, jeśli jest aktualny. Twórcy systemu testują go z kolejnymi wersjami PHP i publikują tabelę zgodności. Źródłem błędów są prawie zawsze dodatki: wtyczka, której autor przestał ją rozwijać, motyw kupiony lata wcześniej albo fragment kodu dopisany kiedyś na zamówienie w pliku functions.php.

Skutki bywają różne. W najgorszym razie zamiast strony pojawia się komunikat „W witrynie wystąpił błąd krytyczny” albo biały ekran. Częściej zdarza się usterka mniej widoczna: przestaje działać formularz, koszyk nie przelicza dostawy, w kokpicie znika jedna z zakładek, a na górze strony wyświetlają się wiersze ostrzeżeń. Takich usterek właściciel może nie zauważyć przez wiele dni, dlatego test przed przełączeniem ma większą wartość niż samo szybkie sprawdzenie strony głównej.

Którą wersję PHP wybrać jako docelową?

Dokumentacja WordPressa zaleca PHP w wersji 8.3 lub nowszej. System działa także na starszych wersjach, począwszy od 7.4, lecz twórcy wprost zaznaczają, że te starsze wersje zakończyły już swój cykl życia i mogą narażać witrynę na luki bezpieczeństwa.

Twórcy PHP opisują cykl każdej wersji w prosty sposób. Przez dwa lata od wydania wersja jest w pełni wspierana: naprawiane są błędy i luki. Przez kolejne dwa lata dostaje już tylko poprawki krytycznych luk bezpieczeństwa. Po czterech latach wsparcie się kończy i wersja nie dostaje żadnych poprawek. Aktualny stan poszczególnych wersji pokazuje strona „Supported Versions” w serwisie php.net.

Przy wyborze trzeba pogodzić trzy rzeczy. Wersja powinna być nadal wspierana przez twórców PHP, powinna figurować jako zgodna w tabeli zgodności dla używanej wersji WordPressa i powinna być obsługiwana przez wszystkie ważne wtyczki. Tabela zgodności znajduje się w podręczniku zespołu rozwijającego WordPressa, na stronie „PHP Compatibility and WordPress Versions”. Wynika z niej między innymi, że najnowsze wersje PHP są obsługiwane dopiero przez najnowsze wydania WordPressa, więc aktualizacja systemu poprzedza zmianę PHP, a nie odwrotnie.

Czy lepiej przeskoczyć o kilka wersji naraz?

Pod względem technicznym nic nie stoi na przeszkodzie, aby przejść na przykład z 7.4 od razu na 8.3. Im większy przeskok, tym więcej zmian w języku i tym większa szansa, że starszy dodatek zgłosi błąd. Radzę wybrać wersję docelową od razu, a wersje pośrednie traktować jako wyjście awaryjne: jeśli na docelowej coś nie działa, a naprawa wymaga czasu, można tymczasowo zatrzymać się o jeden stopień niżej, o ile ta niższa wersja jest jeszcze wspierana.

Jak sprawdzić obecną wersję PHP i spisać stan wyjściowy?

Zanim cokolwiek zostanie zmienione, trzeba wiedzieć, od czego się zaczyna. Zapisany stan wyjściowy przydaje się dwa razy: przy porównaniu z kopią testową i przy ewentualnym powrocie do poprzednich ustawień.

1. Po zalogowaniu do kokpitu należy przejść do menu „Narzędzia”, a następnie do pozycji „Kondycja witryny”.
2. W narzędziu trzeba przejść na kartę z informacjami o witrynie (druga karta, obok karty ze stanem).
3. Należy rozwinąć sekcję „Serwer” i odszukać wiersz „Wersja PHP”. Tę wartość trzeba zanotować dokładnie, razem z numerem po kropce.
4. W tej samej sekcji warto zanotować limit pamięci PHP, maksymalny rozmiar wgrywanego pliku i limit czasu. Każda wersja PHP na hostingu może mieć te ustawienia zapisane osobno.
5. Na tej samej karcie należy rozwinąć sekcje z włączonymi wtyczkami i z aktywnym motywem, a potem skopiować całość przyciskiem kopiowania informacji do schowka i wkleić do pliku tekstowego.
6. W sklepie na WooCommerce te same dane widać także w menu „WooCommerce”, pozycja „Status”, w części poświęconej środowisku serwera.

Wersję PHP pokazuje również panel hostingu. Dobrze jest porównać obie wartości. Jeśli się różnią, oznacza to zwykle, że dla domeny ustawiono inną wersję niż domyślna dla konta albo że wersję narzuca wiersz w pliku .htaccess. Wtedy wiarygodna jest wartość z „Kondycji witryny”, bo pokazuje, czego naprawdę używa witryna.

Aktualizacje przed testem, nie po nim

Oficjalna strona WordPressa poświęcona aktualizacji PHP wymienia przed zmianą dwie czynności: wykonanie kopii zapasowej oraz zaktualizowanie WordPressa, motywów i wtyczek w menu „Kokpit”, pozycja „Aktualizacje”. Kolejność ma znaczenie. Nowe wydania dodatków zawierają poprawki pod nowsze PHP, więc testowanie starych wydań dałoby fałszywy obraz.

Po aktualizacjach należy obejrzeć witrynę jeszcze na dotychczasowej wersji PHP. Jeżeli coś przestało działać już na tym etapie, winna jest aktualizacja dodatku, a nie PHP, i trzeba to naprawić przed dalszymi krokami. Jak przygotować kopię, którą da się naprawdę odtworzyć, opisałem we wpisie o kopii zapasowej WordPressa.

Jak ocenić wtyczki i motyw jeszcze przed testem?

Wstępny przegląd dodatków nie zastępuje testu, ale wskazuje miejsca, którym trzeba się przyjrzeć szczególnie uważnie.

W kokpicie, w menu „Wtyczki”, przy każdej wtyczce z oficjalnego katalogu znajduje się odnośnik do szczegółów. W oknie szczegółów podane są: data ostatniej aktualizacji, wersja WordPressa, z którą dodatek był testowany, oraz wymagana wersja PHP. Trzeba pamiętać, że wymagana wersja PHP oznacza minimum, a nie potwierdzenie zgodności z najnowszą wersją. Więcej mówi data ostatniej aktualizacji: dodatek nierozwijany od dawna jest pierwszym kandydatem do sprawdzenia.

Wtyczki i motywy kupione poza katalogiem nie pokazują tych danych w kokpicie. Informacji o obsługiwanych wersjach PHP trzeba szukać w opisie produktu i w dzienniku zmian na stronie sprzedawcy. Jeśli licencja wygasła, a dodatek nie pobiera aktualizacji, najpierw należy ją odnowić i zainstalować bieżące wydanie.

Co z wtyczką PHP Compatibility Checker?

Strona WordPressa o aktualizacji PHP nadal wspomina o wtyczce PHP Compatibility Checker, która przegląda kod motywów i wtyczek. Na stronie samej wtyczki w katalogu widnieje jednak ostrzeżenie, że nie jest już rozwijana i nie będzie otrzymywać kolejnych wydań, także tych związanych z bezpieczeństwem. Jej opis mówi o sprawdzaniu zgodności najwyżej do PHP 8.0, a więc nie obejmuje wersji, na które dziś się przechodzi.

Z tego powodu nie radzę opierać na niej decyzji ani instalować jej na działającej witrynie. Narzędzia tego rodzaju tylko czytają kod i go nie uruchamiają, więc zgłaszają fałszywe alarmy i nie wykrywają błędów, które ujawniają się dopiero podczas pracy. Pewną odpowiedź daje wyłącznie uruchomienie witryny na nowej wersji PHP w bezpiecznym miejscu.

Kod dopisany na zamówienie

Osobną grupą są własne modyfikacje: motyw potomny, fragmenty w pliku functions.php, wtyczka napisana kiedyś przez programistę, integracja z systemem magazynowym lub księgowym. Nikt poza właścicielem ich nie aktualizuje, więc to one najczęściej zawodzą na nowym PHP. Warto spisać je przed testem, żeby na kopii sprawdzić właśnie te funkcje.

Kto woli nie zajmować się tym samodzielnie, może zadzwonić pod numer 533 525 168 albo napisać na info@lukaszwudyka.pl. Przejmę sprawę: przygotuję kopię testową, uruchomię ją na nowej wersji PHP, przejrzę dziennik błędów i dopiero po usunięciu usterek przełączę właściwą witrynę.

Jak przygotować kopię testową witryny?

Kopia testowa to drugi, niezależny egzemplarz witryny: z własnymi plikami i własną bazą danych, pod innym adresem, najczęściej w subdomenie. Większość firm hostingowych pozwala ustawić wersję PHP osobno dla każdej domeny i subdomeny. Dzięki temu kopia może działać na nowej wersji, a właściwa witryna w tym samym czasie na starej.

Są trzy drogi do takiej kopii. Najwygodniejsza to funkcja środowiska testowego w panelu hostingu, o ile dany pakiet ją zawiera: jednym poleceniem tworzy kopię i pozwala ją później usunąć. Druga to wtyczka do tworzenia kopii testowych albo do przenoszenia witryn. Trzecia to ręczne skopiowanie plików i bazy do subdomeny. Wybór zależy od hostingu, natomiast warunki, które kopia ma spełnić, są zawsze takie same.

1. W panelu hostingu należy utworzyć subdomenę przeznaczoną na test oraz osobną, pustą bazę danych z własnym użytkownikiem.
2. Trzeba wykonać pełną kopię witryny: wszystkie pliki oraz bazę danych. Ta sama kopia posłuży jako zabezpieczenie przed właściwym przełączeniem.
3. Kopię należy odtworzyć w subdomenie. W pliku wp-config.php kopii muszą się znaleźć dane nowej bazy, a adresy w bazie muszą wskazywać subdomenę. Narzędzia hostingu i wtyczki do przenoszenia robią to same; przy pracy ręcznej nie wolno pominąć zamiany adresów.
4. Dostęp do kopii należy zabezpieczyć hasłem na poziomie katalogu w panelu hostingu. W kokpicie kopii, w menu „Ustawienia”, pozycja „Czytanie”, trzeba dodatkowo zaznaczyć pole „Proś wyszukiwarki o nieindeksowanie tej witryny”.
5. Na kopii należy wyłączyć wszystko, co wysyła coś na zewnątrz: wysyłkę wiadomości do klientów, płatności w trybie produkcyjnym, automatyczne przekazywanie zamówień do hurtowni, kuriera i systemu księgowego. Bramki płatności mają zwykle tryb testowy i z niego trzeba skorzystać.
6. Na końcu należy otworzyć kopię w przeglądarce jeszcze na starej wersji PHP i upewnić się, że wygląda i działa tak samo jak oryginał.

Ostatni krok bywa pomijany, a jest potrzebny. Jeśli kopia ma usterki już na starej wersji PHP, to po przełączeniu nie da się odróżnić błędów kopiowania od błędów zgodności. Punktem odniesienia musi być kopia, która przed zmianą działa poprawnie.

Dane klientów na kopii testowej

Kopia sklepu zawiera zamówienia, adresy i numery telefonów klientów. Podlega więc tym samym zasadom ochrony danych co właściwa witryna. Nie powinna być dostępna bez hasła, nie należy udostępniać jej osobom postronnym, a po zakończeniu testu trzeba ją usunąć razem z bazą danych. Pozostawiona na lata, nieaktualizowana kopia jest jedną z częstszych dróg włamania na konto hostingowe.

Gdy hosting nie pozwala na osobną wersję PHP dla subdomeny

Zdarzają się pakiety, w których wersja PHP jest jedna dla całego konta. Wtedy pozostaje środowisko lokalne na własnym komputerze, do którego importuje się kopię witryny, albo tymczasowe konto testowe u dostawcy. Test lokalny pokaże błędy w kodzie wtyczek i motywu, ale nie odtworzy ustawień serwera, więc po właściwym przełączeniu trzeba sprawdzić witrynę szczególnie starannie.

Jak włączyć zapis błędów i przełączyć PHP na kopii?

Oglądanie stron kopii to za mało. Część problemów nie pokazuje się na ekranie, tylko trafia do dziennika błędów. WordPress ma do tego wbudowany tryb debugowania, który zapisuje komunikaty PHP do pliku. Dokumentacja zastrzega, że nie zaleca się włączania go na działającej witrynie, natomiast kopia testowa jest właściwym miejscem.

1. Przez menedżer plików w panelu hostingu albo przez FTP należy otworzyć plik wp-config.php znajdujący się w katalogu kopii testowej, a nie oryginału.
2. Trzeba odszukać wiersz z komentarzem informującym, że to koniec edycji (w wersji angielskiej zaczyna się od słów „That’s all, stop editing”). Nowe wiersze wstawia się przed nim.
3. Jeżeli w pliku jest już wiersz z WP_DEBUG ustawionym na false, należy go zastąpić poniższym fragmentem, a nie dopisywać drugiego.
4. Po zachowaniu zmian w pliku należy przejść do panelu hostingu, do narzędzia wyboru wersji PHP. Jego nazwa zależy od dostawcy; w panelu cPanel jest to na przykład „MultiPHP Manager”.
5. Na liście domen trzeba wskazać wyłącznie subdomenę testową, ustawić dla niej wersję docelową i zatwierdzić zmianę.
6. Po chwili należy otworzyć w kokpicie kopii „Kondycję witryny” i w sekcji „Serwer” potwierdzić, że wiersz „Wersja PHP” pokazuje nową wartość.

Fragment do wklejenia w pliku wp-config.php kopii testowej, zgodny z dokumentacją WordPressa:

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

Pierwszy wiersz włącza tryb debugowania. Drugi każe zapisywać komunikaty do pliku debug.log w katalogu wp-content. Dwa ostatnie ukrywają komunikaty na ekranie, dzięki czemu kopia wygląda tak, jak zobaczyliby ją klienci. Szerzej opisałem to we wpisie o tym, jak włączyć zapis błędów do pliku i go odczytać.

Wersja się nie zmieniła mimo przełączenia

Jeśli „Kondycja witryny” nadal pokazuje starą wersję, najczęstszą przyczyną jest plik .htaccess skopiowany z oryginału. Na części hostingów wersję PHP dla katalogu ustawia wiersz dopisany do tego pliku przez panel, zwykle zaczynający się od AddHandler. Skopiowany razem z witryną, wymusza starą wersję także na kopii. W takim przypadku należy ponownie zapisać wybór wersji w panelu, a gdy to nie pomoże, zapytać pomoc techniczną hostingu, który wiersz odpowiada za wersję. Nie radzę usuwać wierszy z tego pliku na wyczucie.

Co sprawdzić na kopii i jak czytać dziennik błędów?

Test polega na przejściu przez witrynę tak, jak robią to klienci i osoby z firmy, a potem na przeczytaniu dziennika. Kod wtyczki uruchamia się dopiero wtedy, gdy ktoś użyje danej funkcji, dlatego im więcej miejsc zostanie odwiedzonych, tym pełniejszy będzie dziennik.

• Strona główna, kilka podstron usług, wpis na blogu, strona kategorii i wyniki wyszukiwarki wewnętrznej.
• Każdy formularz: kontaktowy, zapisu na listę, wyceny. Formularz trzeba wysłać i sprawdzić, czy zgłoszenie zapisało się w kokpicie.
• W sklepie cała droga klienta: dodanie produktu do koszyka, kod rabatowy, wybór dostawy, płatność testowa, strona z podziękowaniem, zamówienie widoczne w kokpicie.
• Logowanie i rejestracja klienta, strona konta, przypomnienie hasła.
• Kokpit: edycja i zapis wpisu, wgranie zdjęcia do biblioteki mediów, ekran ustawień każdej ważnej wtyczki, kreator stron używany w witrynie.
• Funkcje działające w tle: zaplanowana kopia zapasowa, generowanie mapy witryny, import cennika, eksport zamówień. Większość wtyczek pozwala uruchomić takie zadanie ręcznie.

Na koniec należy wrócić do „Kondycji witryny” na karcie ze stanem. Narzędzie zgłasza między innymi brak wymaganych lub zalecanych modułów PHP. Rozszerzenia, na przykład do obróbki zdjęć, włącza się na hostingu osobno dla każdej wersji PHP, więc po zmianie wersji lista aktywnych modułów może być inna niż wcześniej.

Trzy rodzaje wpisów w pliku debug.log

Plik debug.log z katalogu wp-content kopii otwiera się w menedżerze plików lub pobiera na komputer. Każdy wpis zaczyna się od daty i godziny, potem następuje rodzaj komunikatu, opis oraz ścieżka do pliku z numerem wiersza. Najważniejsze są rodzaj komunikatu i ścieżka.

Wpis zaczynający się od słów PHP Fatal error oznacza, że wykonywanie kodu zostało przerwane. To on stoi za komunikatem o błędzie krytycznym i białym ekranem. Każdy taki wpis trzeba wyjaśnić przed przełączeniem właściwej witryny, bez wyjątków.

Wpis PHP Warning informuje o nieprawidłowości, po której kod działa dalej. Strona się wyświetla, ale dana funkcja mogła zwrócić błędny wynik. Ostrzeżenia dotyczące funkcji ważnych dla firmy, takich jak koszyk, formularz czy płatność, należy traktować poważnie i sprawdzić ręcznie, czy funkcja działa.

Wpis PHP Deprecated oznacza, że kod korzysta z rozwiązania, które w tej wersji PHP jeszcze działa, lecz w jednej z następnych zostanie usunięte. Takie wpisy nie blokują przełączenia. Są natomiast zapowiedzią kłopotów przy kolejnej zmianie wersji, więc warto przekazać je autorowi dodatku.

Jak ustalić, który dodatek odpowiada za wpis?

Odpowiedź zawiera ścieżka pliku. Jeśli znajduje się w niej fragment wp-content/plugins/, to następny człon jest nazwą katalogu wtyczki. Fragment wp-content/themes/ wskazuje motyw, a następny człon jego katalog. Ścieżka prowadząca do katalogów wp-includes lub wp-admin oznacza pliki samego WordPressa; wtedy winny jest zwykle dodatek, który wywołał funkcję systemu w nieprawidłowy sposób, i trzeba czytać dalszą część wpisu, gdzie widać kolejne pliki.

Po wskazaniu dodatku są cztery wyjścia. Pierwsze to aktualizacja do bieżącego wydania, jeśli nie została jeszcze wykonana. Drugie to zgłoszenie do autora z dokładną treścią wpisu z dziennika i numerem wersji PHP. Trzecie to zastąpienie dodatku innym o podobnym działaniu, co zaleca także oficjalna strona WordPressa, gdy autor nie odpowiada. Czwarte, w przypadku kodu pisanego na zamówienie, to zlecenie poprawki programiście. Po każdej zmianie test tej funkcji trzeba powtórzyć.

Pusty dziennik po rzetelnym przejściu wszystkich punktów oraz brak nowych problemów w „Kondycji witryny” oznaczają, że witryna jest gotowa na właściwe przełączenie.

Jak przełączyć wersję PHP na działającej witrynie?

Przełączenie najlepiej zaplanować na porę najmniejszego ruchu i na dzień, w którym przez kilka następnych godzin ktoś może obserwować witrynę. Nie polecam robić tego tuż przed weekendem, urlopem ani w trakcie kampanii reklamowej.

1. Należy wykonać świeżą kopię zapasową plików i bazy danych i upewnić się, że da się ją pobrać.
2. Trzeba zanotować obecną wersję PHP, aby wiedzieć, do której wrócić.
3. Na właściwej witrynie należy wprowadzić te same zmiany, które okazały się potrzebne na kopii: aktualizacje, wymianę dodatków, poprawki kodu. Po nich trzeba sprawdzić witrynę jeszcze na starej wersji PHP.
4. W panelu hostingu, w narzędziu wyboru wersji PHP, należy ustawić wersję docelową dla domeny głównej. Jeśli witryna działa pod adresem z „www” i bez niego jako osobne pozycje, zmiana musi objąć obie.
5. Warto porównać ustawienia nowej wersji z zanotowanymi wcześniej: limit pamięci, maksymalny rozmiar wgrywanego pliku, limit czasu i listę rozszerzeń. Jeśli są niższe niż poprzednio, należy je wyrównać w panelu.
6. Należy opróżnić pamięć podręczną wtyczki przyspieszającej oraz pamięć podręczną po stronie serwera, jeżeli hosting ją udostępnia.
7. Witrynę trzeba otworzyć w oknie prywatnym przeglądarki, bez zalogowania, i przejść skróconą listę kontrolną: strona główna, formularz, zamówienie próbne, logowanie do kokpitu.
8. W „Kondycji witryny” należy potwierdzić nową wartość w wierszu „Wersja PHP” i przejrzeć kartę ze stanem.

Po czym poznać, że zmiana się udała?

Dowodem są cztery rzeczy naraz: „Kondycja witryny” pokazuje nową wersję, ostrzeżenie o aktualizacji PHP zniknęło z kokpitu, strony i formularze działają jak przedtem, a w dzienniku błędów serwera nie przybywa wpisów o błędach krytycznych. Dziennik błędów serwera jest dostępny w panelu hostingu i działa niezależnie od trybu debugowania WordPressa, więc na właściwej witrynie nie trzeba tego trybu włączać.

Przez pierwszą dobę warto zajrzeć do dziennika jeszcze dwa lub trzy razy i sprawdzić, czy wykonały się zadania zaplanowane: kopia zapasowa, wysyłka powiadomień o zamówieniach, synchronizacja z zewnętrznymi systemami. U części dostawców zadania uruchamiane z harmonogramu serwera mają wersję PHP ustawianą osobno od wersji dla domeny. Jeśli witryna korzysta z takich zadań, trzeba to potwierdzić w panelu lub w pomocy hostingu.

Co zrobić, gdy po przełączeniu witryna przestała działać?

Najważniejsza zasada brzmi: najpierw przywraca się działanie, potem szuka przyczyny. Powrót do poprzedniej wersji PHP w panelu hostingu jest w pełni odwracalny i nie zmienia ani plików, ani bazy danych. Dlatego to pierwszy ruch, a nie ostatni.

Po cofnięciu wersji witryna powinna wrócić do stanu sprzed zmiany. Oficjalna strona WordPressa opisuje ten sam porządek: w razie kłopotów należy poprosić hosting o przywrócenie poprzedniej wersji PHP, a kopię zapasową odtwarzać dopiero wtedy, gdy to nie wystarczy. Odtwarzanie kopii w sklepie oznacza utratę zamówień złożonych po jej wykonaniu, więc nie należy po nie sięgać pochopnie.

Komunikat o błędzie krytycznym i wiadomość od WordPressa

Gdy WordPress wykryje błąd krytyczny, wysyła na adres administratora wiadomość z nazwą dodatku, który go wywołał, oraz z odnośnikiem do trybu odzyskiwania. Po wejściu przez ten odnośnik i zalogowaniu wadliwy dodatek jest wstrzymany, a kokpit działa, więc można dodatek zaktualizować albo wyłączyć. Opisałem to dokładnie we wpisie o tym, jak skorzystać z trybu odzyskiwania.

Jeśli wiadomość nie dotarła, nazwę dodatku pokaże dziennik błędów serwera: ostatni wpis rodzaju „PHP Fatal error” i ścieżka pliku. Wyłączenie wskazanej wtyczki bez dostępu do kokpitu polega na zmianie nazwy jej katalogu w wp-content/plugins przez menedżer plików. To czynność odwracalna, bo przywrócenie nazwy pozwala włączyć wtyczkę ponownie.

Usterka dotyczy tylko jednej funkcji

Gdy witryna działa, a zawodzi jedna rzecz, decyzja zależy od jej wagi. Niedziałający koszyk lub formularz uzasadnia natychmiastowy powrót do starej wersji i dokończenie pracy na kopii. Drobna usterka w rzadko używanym miejscu kokpitu może poczekać na poprawkę autora, o ile poprzednia wersja PHP i tak ma zostać wkrótce wyłączona przez hosting.

Jakich błędów unikać przy zmianie wersji PHP?

Większość nieudanych zmian nie wynika z trudności technicznych, tylko z pominięcia jednego z prostych kroków. Poniższe pomyłki widuję najczęściej.

• Przełączenie wersji dla całego konta zamiast dla jednej subdomeny testowej. Skutkiem jest niezamierzona zmiana na wszystkich witrynach naraz.
• Ocena wyłącznie strony głównej. Błędy kryją się zwykle w koszyku, formularzach i kokpicie.
• Pozostawienie trybu debugowania z wyświetlaniem komunikatów na ekranie. Wiersze błędów ujawniają ścieżki na serwerze i psują wygląd strony.
• Pozostawienie pliku debug.log oraz samej kopii testowej na serwerze po zakończeniu pracy.
• Kopia testowa bez hasła i bez blokady indeksowania, przez co w Google pojawia się druga, identyczna wersja witryny.
• Odkładanie zmiany do dnia, w którym hosting sam wyłączy starą wersję. Wtedy przełączenie następuje bez testu i w terminie wybranym przez kogoś innego.

Do tej listy dodałbym jedną uwagę ogólną. Zmiana wersji PHP nie jest zadaniem jednorazowym, bo każda wersja ma z góry określony czas wsparcia. Notatka z przebiegu testu, lista dodatków, które sprawiły kłopot, oraz zachowane wpisy „PHP Deprecated” wyraźnie skrócą następną zmianę.

Najczęstsze pytania

Czy zmiana wersji PHP może skasować treści albo zamówienia?

Nie. Wersja PHP decyduje o tym, jak uruchamiany jest kod, a nie o zawartości bazy danych ani plików. Wpisy, zdjęcia, produkty i zamówienia pozostają nietknięte, nawet jeśli po przełączeniu strona przestaje się wyświetlać. Dane można utracić dopiero przy nieostrożnym odtwarzaniu starej kopii zapasowej, dlatego pierwszą reakcją na kłopot jest cofnięcie wersji, a nie odtwarzanie kopii.

Czy przed zmianą PHP trzeba aktualizować WordPressa?

Tak, i jest to zalecenie z oficjalnej strony WordPressa o aktualizacji PHP. Tabela zgodności pokazuje, że nowe wersje PHP są obsługiwane dopiero przez nowsze wydania systemu, a stare wydania nie były z nimi testowane. To samo dotyczy wtyczek i motywu: najpierw aktualizacje i kontrola działania, potem zmiana wersji.

W dzienniku są same wpisy „PHP Deprecated”. Czy można przełączać?

Można, o ile wszystkie sprawdzane funkcje działają poprawnie. Wpisy tego rodzaju informują, że dany sposób zapisu kodu zostanie usunięty w przyszłej wersji języka, a w obecnej wciąż działa. Warto przekazać je autorom dodatków i upewnić się, że na właściwej witrynie komunikaty nie są wyświetlane na ekranie.

Hosting sam przełączył wersję i strona nie działa. Co teraz?

Najpierw należy sprawdzić w panelu, czy poprzednia wersja jest jeszcze dostępna do wyboru, i wrócić do niej na czas naprawy. Jeśli została wyłączona na stałe, trzeba odczytać z dziennika błędów serwera nazwę dodatku wywołującego błąd krytyczny, wyłączyć go przez zmianę nazwy katalogu i zaktualizować albo zastąpić. Sposób dochodzenia do winnej wtyczki opisuje wpis o tym, jak znaleźć wtyczkę, która wywołała błąd krytyczny.

Czy nowsza wersja PHP poprawi pozycje w Google?

Bezpośrednio nie, bo wyszukiwarka nie ocenia wersji PHP. Nowsze wersje wykonują kod sprawniej, co może skrócić czas odpowiedzi serwera, a szybkość działania strony jest jednym z wielu sygnałów branych pod uwagę. Nie należy jednak oczekiwać skoku widoczności po samej zmianie; głównymi powodami są bezpieczeństwo i zgodność z nowymi wydaniami WordPressa oraz wtyczek.

Co zrobić z wtyczką, której autor już nie rozwija, a która nie działa na nowym PHP?

Trwałym rozwiązaniem jest zastąpienie jej dodatkiem o podobnym działaniu, który jest regularnie aktualizowany, i przeniesienie ustawień lub danych. Jeżeli wtyczka jest niezbędna i nie ma zamiennika, poprawkę może przygotować programista, lecz od tej chwili utrzymanie jej kodu spoczywa na właścicielu witryny. Pozostawanie na niewspieranej wersji PHP tylko z powodu jednej wtyczki uważam za najgorszy z możliwych wyborów.

Brak czasu albo ochoty, żeby zająć się tym samodzielnie?

Zmiana wersji PHP wygląda na drobiazg, a potrafi zabrać cały dzień, gdy po drodze wychodzi stara wtyczka albo sklep przestaje liczyć dostawę. Jeśli to nie jest praca, na którą jest czas lub chęć, mogę przeprowadzić ją w całości. Sprawdzam obecną wersję i ustawienia serwera, aktualizuję WordPressa i dodatki, przygotowuję zabezpieczoną kopię testową, uruchamiam ją na nowej wersji i przechodzę przez wszystkie ważne funkcje, łącznie z formularzami i zamówieniem próbnym.

Potem czytam dziennik błędów, usuwam usterki albo wskazuję zamienniki dla dodatków, których nie da się naprawić, przełączam właściwą witrynę w spokojnej porze i obserwuję ją po zmianie. Na koniec usuwam kopię testową i przekazuję krótką notatkę z tym, co zostało zrobione. Wystarczy zadzwonić pod numer 533 525 168 albo napisać na adres info@lukaszwudyka.pl i opisać w dwóch zdaniach, o jaką witrynę chodzi.