Przejście na PHP 8.x w czterech krokach – wywiad z Juliette Reinders Folmer

Aktualizacja witryny, wtyczki lub motywu WordPress do nowej wersji PHP to zadanie, które regularnie się powtarza. Ale jak to zrobić tak efektywnie, jak to możliwe? Skąd wiesz, że niczego nie przeoczysz? Czy jest na to drogowskaz?

W tym artykule odpowiemy na te pytania (i nie tylko) i przyjrzymy się, co obejmuje płynne przejście na PHP 8.x dla witryny, wtyczki lub motywu WordPress, w tym plan działania.

Zrobimy to na podstawie wywiadu, który przeprowadziliśmy z ekspertką PHP Juliette Reinders Folmer. Większość swojego codziennego życia poświęca programowaniu i wszystkiemu, co go otacza, skupiając się głównie na projektach open-source, w tym WordPressie.

Czy jesteś gotowy na płynną zmianę? Ciekawi Cię nasz plan krok po kroku? Więc zanurzmy się od razu!

PHP 8.x — co się zmieniło

Aby zapoznać się ze zmianami, polecamy poniższe artykuły:

• Informacje o wydaniu dla PHP 8.0 i PHP 8.1
• Przewodnik migracji dla PHP 8.0 i PHP 8.1
• WordPress i PHP 8.0 oraz aktualny stan
• Co nowego w PHP 8.0 i PHP 8.1

Po przeczytaniu tych artykułów będziesz na bieżąco informowany o tym, co zmieniło się w PHP 8.x i co musisz zrobić, aby projekty PHP działały bez żadnych problemów.

Jeśli nie masz pewności, jak najlepiej zacząć, nie ma problemu. W rozmowie z Juliette omówiliśmy to szczegółowo, aw tym artykule wyjaśnimy Ci tak szczegółowo, jak to możliwe, jak możesz przejść na PHP 8.x.

W polach informacyjnych wyjaśnimy również, jak wykonywać różne operacje w MyKinsta, naszym zastrzeżonym panelu kontrolnym dla wszystkich witryn, aplikacji i baz danych WordPress.

Przejście na PHP 8.x: jak zacząć

Przejście na PHP 8.x brzmi prosto i technicznie takie jest. Wiele hostów pozwala określić w panelu administracyjnym, której wersji PHP chcesz używać na swojej stronie internetowej. W Kinsta zmianę wersji PHP można wykonać jednym kliknięciem na pulpicie nawigacyjnym MyKinsta.

Ale zanim to zrobisz, jest kilka rzeczy, których musisz być pewien. W zależności od poziomu wiedzy i doświadczenia zalecamy:

• Jeśli zbudowałeś własną witrynę WordPress ze standardowymi motywami i wtyczkami, nie mając dużej wiedzy na temat PHP, zatrudnij programistę lub agencję, aby zbadała, czy Twoja witryna jest odpowiednia do działania w PHP 8.x. Szukasz osoby trzeciej, która może Ci w tym pomóc? Następnie spójrz na naszą stronę Partnerzy, na której znajduje się kilka zaufanych firm, które mogą Ci pomóc.
• Jeśli Twoja witryna WordPress została zbudowana przez podmiot zewnętrzny, programistę lub agencję, skontaktuj się z nimi, aby zapytać, czy Twoja witryna może działać w PHP 8.x.
• Jeśli zbudowałeś swoją witrynę WordPress — na przykład z własnym niestandardowym motywem lub samodzielnie opracowanymi wtyczkami — poniżej mamy dla Ciebie plan działania.

Jeśli Twoja witryna należy do jednej z dwóch pierwszych kategorii, z pewnością zapraszamy do przeczytania dalszej części artykułu, ale nie zalecamy samodzielnego testowania witryny pod kątem zgodności z PHP 8. Zostaw to profesjonalistom.

Niezależnie od tego, co wybierzesz, radzimy nie przełączać swojej działającej witryny na PHP 8 i „zobaczyć, czy działa”. Czy jesteś ciekawy, jak będzie wyglądać Twoja witryna i nie możesz się doczekać, aż będzie działać na PHP 8? Następnie rozpocznij testowanie w środowisku przejściowym. Dobry gospodarz pozwoli ci łatwo skonfigurować środowisko testowe.

W środowisku testowym możesz aktywować PHP 8.x i sprawdzić, czy ta aktualizacja dobrze działa na Twojej stronie. Możliwa jest również praca z lokalną kopią Twojej witryny. Dzięki naszemu bezpłatnemu narzędziu programistycznemu DevKinsta możesz łatwo zaimportować swoją witrynę z pulpitu nawigacyjnego MyKinsta, po czym możesz zmienić wersję PHP na 8.0 lub 8.1.

Jeśli nie widzisz żadnych problemów w środowisku przejściowym, niekoniecznie oznacza to, że w rzeczywistości nie ma żadnych problemów. Poniższy plan działania powie ci, dlaczego.

Testowanie zgodności z PHP 8.x: plan działania

Testowanie: słowo kluczowe dobrego oprogramowania. Nawet w przypadku witryn WordPress i ich komponentów, takich jak motywy, wtyczki i rdzeń WordPress, testowanie jest sposobem na zapewnienie, że nie wydarzy się coś, czego nie chcesz.

Projekt tworzenia oprogramowania składa się głównie z testowania. W tym artykule przyjrzymy się w szczególności testom, które mogą pomóc w bezproblemowym przejściu na PHP 8.x. W naszym artykule na temat narzędzi DevOps znajdziesz sekcję z kolekcją narzędzi, których możesz użyć.

W tym poście na blogu omówiono następujące rodzaje testów:

Przyjrzyjmy się bliżej różnym typom testów, które możemy wykonać.

Analiza statyczna (lub testowanie statyczne)

Pierwszym krokiem, jaki możesz zrobić jako programista PHP, jest przeprowadzenie statycznej analizy kodu za pomocą różnych narzędzi. Analiza statyczna to proces analizy oprogramowania bez wykonywania kodu. Dzięki analizie statycznej możliwe jest wykrywanie błędów, wykrywanie problemów z kompatybilnością PHP 8.x, egzekwowanie standardów kodowania (na przykład WordPress Coding Standards), a nawet modyfikacja i czyszczenie kodu jest możliwe.

Narzędzia do analizy statycznej

Możesz przeprowadzić analizę statyczną za pomocą różnych narzędzi, takich jak:

• PHPKompatybilność
• Psalm
• PHPStan

W chwili pisania tego tekstu nie wszystkie testy PHP 8.1 są obsługiwane w najnowszej wersji PHPCompatibility. Testy PHP 8.1 mogą znajdować się w wersji rozwojowej, więc upewnij się, że używasz ich (na razie) podczas korzystania z PHPCompatibility do analizy swojego projektu i sprawdzenia, jakie są błędy/zalecenia.

Testy PHP 8.1 zostaną wkrótce wydane w nowej głównej wersji. Jeśli chcesz być na bieżąco z tym i masz konto GitHub, otwórz repozytorium GitHub PHPCompatibility i przejdź do Watch -> Custom -> Releases , gdzie możesz wybrać powiadomienie o wydaniu nowej wersji.

PHPCompatibility, która sprawdza tylko kompatybilność z określoną wersją (lub zakresem wersji) PHP, jest łatwa do skonfigurowania. Najlepsze wyniki uzyskasz, jeśli uruchomisz testVersion — na przykład 8.0+ (8.0 i nowsze) — w PHPCompatibility.

Powinieneś zwracać uwagę na przestarzałe lub usunięte funkcje, zmienione domyślne wartości parametrów funkcji, czy używać concat bez nawiasów, czy używać match jako nazwy funkcji (ponieważ jest zarezerwowane od PHP 8.0) itp.

Psalm i PHPStan są dobrymi dodatkami i mogą ci pomóc, przeprowadzając dodatkowe kontrole związane z typami zmiennych. Wadą tych narzędzi jest to, że uzyskanie raportów dotyczących PHP 8.0 i 8.1 wymaga dużo konfiguracji. Nawet jeśli zakończą się sukcesem, możesz spodziewać się wielu fałszywych trafień. Fałszywe alarmy to powiadomienia, które są wysyłane błędnie, spowodowane ograniczeniami analizy statycznej.

Aby poprawnie zinterpretować wyniki tych dwóch narzędzi, wymagana jest solidna wiedza, ale ta wiedza może pomóc w zidentyfikowaniu dodatkowych niezgodności, których PHPCompatibility nie może znaleźć. Zajrzyj do dokumentacji Psalm i PHPStan, jeśli chcesz dowiedzieć się więcej na ich temat.

Streszczenie:

• Wykonaj analizę statyczną za pomocą PHPCompatibility, Psalm, PHPStan
• Rozwiąż wszystkie uzasadnione problemy

Testów jednostkowych

Kolejnym etapem procesu są testy jednostkowe. Testy jednostkowe to metoda testowania pojedynczych fragmentów kodu. W przypadku testów jednostkowych dla każdej jednostki zostaną opracowane określone testy ukierunkowane. Będzie to wymagało przejścia przez różne scenariusze. Korzystnie każdy scenariusz jest testowany oddzielnie od pozostałych, tak aby testy były od siebie niezależne.

Samo posiadanie testów jednostkowych to oczywiście za mało. Trzeba je też uruchomić. Testy jednostkowe najlepiej zautomatyzować przy użyciu narzędzi CI (ciągłej integracji), takich jak Jenkins, GitHub Actions lub Travis.

Obsługa wielu wersji PHP

Jako twórca wtyczek, jeśli chcesz obsługiwać wiele wersji PHP, upewnij się, że testy w CI są przeprowadzane na wszystkich obsługiwanych wersjach PHP.

Oczywiście możesz też wspierać tylko nowsze wersje, wybór należy wyłącznie do Ciebie.

Testowanie z wieloma wersjami PHP wymaga użycia wielu wersji PHPUnit, w zależności od wersji PHP. Ponieważ PHPUnit wprowadził kilka zmian na przestrzeni lat, które wpływają na sposób pisania testów, ta część może być trudna.

Aby obejść ten problem, możesz użyć PHPUnit Polyfills (napisany przez Juliette i sponsorowany przez Yoast). Pozwala to pisać testy, które nie są oficjalnie wspierane przez PHPUnit 9 (a więc mogą działać w PHP 8.x). Polyfills sprawiają, że twoje testy działają w PHPUnit 4.x do 9.x oraz z PHP 5.4 do PHP 8.1 (od teraz).[/notatka]

Teraz, gdy testy są już uruchomione, następnym krokiem jest upewnienie się, że problemy znalezione w testach zostały naprawione.

Pokrycie kodu

Przeprowadzenie tych testów jest najbardziej niezawodnym sposobem znalezienia niezgodności między wersjami.

Czyniąc to, zwróć uwagę na pokrycie kodu testów:

• Załóżmy, że masz funkcję A i napisałeś dla niej test, a funkcja A wywołuje funkcje B, C i D jako część logiki w funkcji.
• Test dla funkcji A został napisany w celu przetestowania logiki funkcji A, ale podczas testowania będzie również wywoływał funkcje B, C i D. W przypadku funkcji B, C i D zwykle testuje się wtedy tylko „szczęśliwą ścieżkę” — sytuację, w której wszystko idzie dobrze — a zatem te funkcje również nie są jeszcze w pełni przetestowane, chociaż (część) kodu w tych funkcjach jest wykonywane podczas testowania funkcji A.
• Dla każdego testu wskaż, który kod jest konkretnie testowany. Robisz to, nadając każdemu testowi @covers W ten sposób B, C i D nie są „liczone” w obliczeniach pokrycia kodu, co pozwala zobaczyć, jaka część kodu jest objęta testami.

Często programiści piszą i testują — czasem nawet nieświadomie — w poszukiwaniu „szczęśliwej ścieżki”. W takich przypadkach konieczne jest również przetestowanie, co się stanie, gdy do funkcji zostaną przekazane nieoczekiwane dane. Testowanie tylko z oczekiwanymi wartościami/typami nie wystarczy .

„Podczas testowania musisz upewnić się, że funkcja robi to, co powinna, ale także, że nie robi tego, czego nie powinna.” — Juliette Reinders Folmer Kliknij, aby zatweetować

Druga część powyższego cytatu jest często zapominana, kiedy jest być może nawet ważniejsza niż pierwsza. Co się stanie, jeśli przekażesz nieprawidłowy typ? Czy pojawia się komunikat o błędzie? A może zmienna rzutowana z funkcją działa normalnie? Co się stanie, jeśli do funkcji zostanie przekazana nieoczekiwana wartość?

Pamiętaj, aby przetestować swoje funkcje z nieoczekiwanymi zmiennymi, typami i wartościami. Tylko wtedy możesz polegać na swoich testach, aby znaleźć problemy, które może powodować nowa wersja PHP.

PHP staje się coraz bardziej restrykcyjne

PHP staje się coraz bardziej precyzyjne (restrykcyjne) w sposobie obsługi „typów” dla własnych funkcji PHP, a także rzeczy takich jak właściwości dynamiczne. Zmiany te mają ogólnie na celu pomóc programistom w dostarczaniu kodu wolnego od błędów (cóż, kodu z mniejszą liczbą błędów). Ale może to stanowić sporą przeszkodę w aktualizacji dla istniejącego wcześniej kodu napisanego w oparciu o „stare” zasady PHP.

Z powodu tego dążenia do bardziej pomocnych komunikatów o błędach w PHP widać, że dostosowywanie istniejącego kodu do nowych wersji PHP zajmuje coraz więcej czasu. Dostosowanie kodu działającego na PHP 5.6 do PHP 7.0 zajęło w większości przypadków tylko ułamek czasu w porównaniu z aktualizacją kodu, aby był odpowiedni dla PHP 8.1. I to pomimo faktu, że PHP 7.0 było „głównym” wydaniem, podczas gdy PHP 8.1 jest „podrzędnym”.

W wielu przypadkach testowanie jest nadal jedynym niezawodnym sposobem określenia, co należy zmodyfikować, aby obsługiwała nową wersję.

Testy jednostkowe są możliwe za pomocą różnych narzędzi, w tym:

• PHPUnit
• Kpina
• Behat,
• Narrator

Wiele z tych narzędzi jest zbudowanych w oparciu o PHPUnit lub w połączeniu z nim.

Ostatecznie nie ma znaczenia, jakich narzędzi używasz. Najważniejszą rzeczą jest to, że testujesz i uruchamiasz testy na nowych wersjach PHP. Ten krok może czasem być bardzo trudny, ale na szczęście, jak wspomniano wcześniej, istnieją do tego narzędzia, takie jak PHPUnit Polyfills.

Testy integracyjne

Testy integracyjne to kolejny krok, który wykonamy, po analizie statycznej i testach jednostkowych. Test integracyjny polega na testowaniu rzeczywistych sytuacji w szerszym kontekście niż tylko „jednostka kodu”. Obejmują one testowanie z aktywną (testową) bazą danych lub testowanie z zewnętrznym interfejsem API, by podać tylko dwa przykłady.

Kiedy więc testujesz kod wtyczki lub motywu w kontekście WordPressa i używasz prawdziwej wersji, są to z definicji testy integracyjne.

WP Test Utils (ponownie napisane przez Juliette i sponsorowane przez Yoast) to doskonałe narzędzie do testowania integracji. WP Test Utils zapewnia narzędzia do pisania testów integracyjnych i jednostkowych, w których WordPress jest „wyśmiewany” za pomocą Brainmonkey i Mockery, gdzie powszechnie używane funkcje WordPress są „sfałszowane”, dzięki czemu testujesz własny kod, a nie kod WordPress.

Testowanie integracji z WordPress to trudniejsza historia, ponieważ obejmuje integrację z WordPress i pakietem testów WordPress. W zależności od tego, które wersje WordPress obsługuje wtyczka lub motyw, musisz wziąć pod uwagę, które wersje PHPUnit są obsługiwane przez sam WordPress, aby uruchomić testy na różnych wersjach PHP.

Na przykład WordPress 5.6 do 5.8 używa PHPUnit 5 do 7 do testowania PHP 5.6 do PHP 8.0, ale od WordPress 5.9 sam WordPress używa PHPUnit Polyfills dla szerszego wsparcia. WP Test Utils działa jako pomost do przezwyciężenia wszystkich tych różnic.

Chcesz dowiedzieć się więcej o tym, jak przeprowadzać testy integracyjne dla wielu różnych wersji WordPress, w tym WordPress 5.9 i nowszych? Następnie przeczytaj o tym na stronie WordPress.

Testowanie ręczne

Teraz, gdy masz już za sobą testy jednostkowe i testy integracyjne oraz rozwiązałeś wszystkie znalezione problemy, czas na testy ręczne. Twoja witryna działa, a Twój własny kod działa, ale używasz też wtyczek A, B i C. Czy wiesz, czy te wtyczki są kompatybilne?

Na przykład sprawdź to u autorów wtyczki i zobacz, czy wskazują, że jest ona zgodna z PHP 8.x. Pytanie brzmi oczywiście, w jaki sposób wtyczka została przetestowana. Często odpowiedź brzmi: w izolacji. Funkcje wtyczki były zwykle testowane w połączeniu z samym WordPressem, bez innych aktywnych wtyczek. I nawet jeśli w tych testach użyto innych wtyczek, istnieje prawdopodobieństwo, że nie wszystkie używane przez ciebie wtyczki były częścią testów, więc weź takie oświadczenie o zgodności z przymrużeniem oka.

Na przykład witryna WordPress z 3 wtyczkami (A, B i C). Możliwe, że na przykład wtyczka B zwraca nieprawidłowy typ zmiennej przez filtr, z którym wtyczka C, używając tego samego filtra, chce pracować. Może to spowodować błąd krytyczny, ponieważ typ nie jest już oczekiwany. Wtyczka C jest wtedy postrzegana jako winowajca komunikatu o błędzie, mimo że prawdziwym winowajcą jest wtyczka B.

Niezgodności interoperacyjności wtyczek są niemożliwe do wykrycia podczas testowania w izolacji. Im więcej aktywnych wtyczek, tym większe prawdopodobieństwo, że coś pójdzie nie tak. Na przykład bardzo korzystne byłoby przekazywanie żądań stron z działającej witryny internetowej do środowiska pomostowego (z włączonym rejestrowaniem błędów), aby odkryć, co faktycznie dzieje się nie tak.

W przypadku tego typu problemu właściciel witryny zwykle widzi tylko komunikat, że wystąpił błąd w ostatnio wykonanym kodzie (w tym przypadku z wtyczki C), mimo że wtyczka C niekoniecznie jest przyczyną problemu.

W większości przypadków wymaga to dużo ręcznej, ludzkiej pracy, a do wykrycia i rozwiązania tych problemów wymagana jest spora ilość smaru łokciowego. Można to zautomatyzować za pomocą kompleksowych testów, ale nie widzimy, aby działo się to zbyt często w WordPress.

Sprawdź dostępność używanych wtyczek

Dla programistów i zespołów deweloperskich: Akceptuj kod tylko wtedy, gdy dostępne są testy. W ten sposób zapewniasz, że wymagane jest mniej testów ręcznych, co oszczędza dużo czasu.

Zakwestionuj strategię testowania, jeśli chcesz kupić komercyjną wtyczkę lub motyw. W ten sposób wspólnie tworzymy świadomość wśród programistów/zespołów programistycznych w społeczności WordPress, aby testowanie było wyżej w programie i wszyscy na tym korzystamy.

Testowanie jest często postrzegane — niesprawiedliwie — jako koszt, podczas gdy w rzeczywistości pozwala zaoszczędzić pieniądze. Dodatkowa inwestycja wymagana do napisania testów zwraca się w postaci znacznie mniejszej liczby zgłoszeń błędów i mniej czasu spędzonego na naprawianiu błędów. Ponadto dzięki zautomatyzowanemu testowaniu oprogramowania rozszerzenia i modyfikacje mogą być wykonywane szybciej, ponieważ testy mogą szybko potwierdzić, że istniejące funkcje nadal działają.

„Bądź miły dla siebie w przyszłości, proszę ;-)” - Juliette Reinders Folmer Kliknij, aby zatweetować

Rola hostów WordPress i PHP 8.x

Dla przeciętnego właściciela witryny wskazówki od hosta są bardzo pożądane. Rozważ następujące:

• Dokumentacja i aktualizacje dla klientów, że WordPress Core, wtyczki i/lub motywy nie są (w niektórych przypadkach) niezgodne z różnymi wersjami PHP
• Opcje testowania (takie jak praca ze środowiskiem przejściowym)
• Metody zgłaszania błędów i kontaktowania się z pomocą techniczną

Jest to również korzystne dla hosta internetowego, ponieważ właściciele witryn często kontaktują się z hostem w celu uzyskania pomocy, gdy pojawiają się problemy. W przypadku przejścia na PHP 8.0 lub 8.1 za potencjalne problemy odpowiada właściciel strony, a im więcej informacji ma właściciel, aby odpowiednio przygotować się do zmiany, tym lepiej.

Udostępnienie PHP 8.0 lub 8.1 klientom jako hostowi WWW to jedno, ale robiąc to, muszą oni upewnić się, że klienci są świadomi, że mogą pojawić się problemy. Zaleca się przetestowanie witryny w środowisku przejściowym z wersją inną niż wersja aktualna. (Wybór wersji PHP jest domyślnie dostępny w Kinsta.)

Minimalna wersja PHP dla WordPress

Ponad 15% wszystkich witryn korzysta obecnie z PHP w wersji 7.0 lub niższej. Widać to w oficjalnych statystykach WordPressa. Około 83% wszystkich witryn WordPress korzysta obecnie z PHP w wersji 7.4 lub niższej. Należy pamiętać, że cokolwiek w wersji niższej lub równej wersji 7.4 nie jest już obsługiwane przez PHP. Korzystanie z wycofanych z eksploatacji wersji PHP może powodować problemy, ponieważ aktualizacje zabezpieczeń nie są już wydawane.

Aby uniknąć problemów, ważne jest, aby właściciele witryn WordPress byli świadomi i poinformowani o minimalnej wersji PHP, która pozwoli na bezpieczne działanie ich witryny. Ze swojej strony właściciele witryn mogą sami modyfikować wersję PHP (możliwe w Kinsta dla wszystkich pakietów) lub poprosić swojego hosta o aktualizację witryny do nowszej wersji PHP. W skrajnych przypadkach możesz przełączyć się na host obsługujący te nowsze wersje.

Ponieważ WordPress wymaga tylko minimalnej wersji 7.4, wielu hostów i właścicieli witryn nie ma wystarczającej motywacji do aktualizacji swoich witryn. I to pomimo faktu, że PHP 7.4 osiągnął koniec życia w listopadzie 2022 roku.

Jeśli WordPress kiedykolwiek zwiększy minimalną wersję PHP, może to oznaczać, że wiele witryn nie będzie już kompatybilnych z aktualizacją do najnowszej wersji WordPress. Jednak aktualizacje zabezpieczeń będą nadal wydawane dla tych nieaktualnych wersji przez dłuższy czas.

Streszczenie

Aby przełączyć się na PHP 8.0 lub nowszy w swojej witrynie, musisz wykonać kilka kroków, które musisz wykonać Ty lub Twój programista. Ważne kroki obejmują:

• Analiza statyczna
• Testów jednostkowych
• Testy integracyjne
• Testowanie ręczne

Przełączając się na PHP 8.x, upewnij się, że wszystko zostało odpowiednio przetestowane. Tylko w ten sposób możesz zagwarantować, że Twoja witryna będzie działać poprawnie, szybko i bezpiecznie w nowszej wersji PHP.

Ogromnie dziękujemy Juliette za udział w tym artykule i za całą jej pracę nad wymienionymi narzędziami!

Zdjęcie Juliette, zrobione przez Jipa Moorsa i wykorzystane za zgodą.