PHP 8.2: co to oznacza dla WordPressa, wtyczek i programistów?

Opublikowany: 2022-12-14

PHP 8.2.0 zadebiutowało 8 grudnia 2022 r. Jako główna aktualizacja wprowadza ulepszenia wydajności, prostszą składnię i większe bezpieczeństwo typów dzięki null , false i true jako samodzielnym typom. Jedną z największych zmian, które mogą stanowić wyzwanie dla programistów WordPress, jest wprowadzenie klas tylko do odczytu , które nie zezwalają na właściwości dynamiczne.

Właściwości dynamiczne są przestarzałe i spowodują błąd krytyczny w PHP 9 lub prawdopodobnie PHP 10. Chociaż potencjalnie bolesne — zwłaszcza dla rdzenia WordPressa — wycofanie jest kluczową cechą i darem dla programistów PHP.

Rzućmy okiem na ostatnią ewolucję PHP, a także na to, jak programiści WordPress utrzymują kompatybilność wsteczną, jednocześnie wykorzystując nowe funkcje, gdy przyniosą one największe korzyści użytkownikom końcowym.

Nadążanie za rozwojem PHP w WordPress

Ponieważ rdzeń WordPressa zachowuje znaczną kompatybilność wsteczną bez planowanych dat zakończenia okresu eksploatacji, kiedy stare wersje nie będą obsługiwane, firmy zajmujące się WordPressem muszą określić własny cykl życia produktu lub usługi oraz wersje PHP, które będą obsługiwać.

W przeciwieństwie do WooCommerce, który wymaga co najmniej PHP 7.4, rdzeń WordPress obecnie zaleca tylko PHP 7.4 lub nowszy. „Działa także z” PHP 5.6.20, którego data wycofania z eksploatacji wygasła pod koniec 2018 roku. Projekt WordPress odnotowuje to i ostrzega, że ​​używanie nieobsługiwanych wersji PHP „może narazić Twoją witrynę na luki w zabezpieczeniach”. (Wymagania WordPress.org)

Na szczęście tylko 5,1% wszystkich witryn WordPress korzysta obecnie z PHP 5.6, a tylko 2% korzysta z jeszcze starszej wersji. 20% używa PHP 7.0 do 7.3, a największa grupa (56,7%) używa PHP 7.4. (Statystyki WordPress.org)

Niestety, PHP 7.4 właśnie osiągnął datę EOL pod koniec listopada 2022 r. PHP 8.0 ma mniej niż rok do oficjalnego wsparcia bezpieczeństwa przez większą część 2023 r. Aktualna i aktywnie obsługiwana wersja, PHP 8.1, przestarzała się pod koniec 2024 r. PHP 8.2, które właśnie doczekało się pierwszej stabilnej wersji, będzie miało wsparcie bezpieczeństwa do grudnia 2025 r.

Jest to szybki cykl wydawniczy i nic dziwnego, że ekosystem WordPressa stara się za nim nadążyć. Ponieważ ponad połowa sieci działa na WordPressie, jest to duży statek, który nie może szybko zawrócić. To o wiele bardziej balansowanie niż wyścig w kierunku krwawiącej krawędzi. Skok do PHP 8 ma jednak wiele zalet dzięki dużym funkcjom zwiększającym wydajność, takim jak kompilacja PHP Just-in-Time (JIT) w czasie wykonywania w celu szybszego wykonywania przy mniejszym zużyciu pamięci.

Kompromis między kompatybilnością wsteczną a stabilnością, przyszłościowym myśleniem a innowacjami

Kompromis między zapewnieniem jak najszerszej publiczności użytkowników a utrzymaniem waluty z PHP zawsze stanowił dylemat dla programistów WordPress, hostów i firm produktowych. Agencje i freelancerzy mający długoterminowych klientów i starsze witryny napotykają ten sam problem: aktualizacja minimalnych wymagań może zmusić obecnych klientów do wprowadzenia znaczących zmian w ich witrynach lub doprowadzić do ich awarii.

Z jednej strony korzyści wynikające z bycia na bieżąco z PHP to lepsze bezpieczeństwo i wydajność oraz najnowsze koncepcje programistyczne i możliwości dla programistów. Z drugiej strony, główną korzyścią płynącą z opóźnienia minimalnego wymaganego PHP jest zadowolona (aczkolwiek zadowolona) i szeroka baza klientów. Jest to sytuacja typu „zapłać mi teraz lub zapłać później”. W pewnym momencie musisz zerwać bandaż.

Dobre dane i dane telemetryczne dotyczące środowisk użytkowników mogą pomóc w określeniu najmniej uciążliwego czasu na podniesienie minimalnego wymagania dotyczącego wersji PHP. Większość programistów wtyczek obserwuje te liczby za pomocą własnych narzędzi, ponieważ nie jest to część aktywnych danych instalacyjnych repozytorium wtyczek WordPress.org. Nieuchronnie każda potencjalnie przełomowa zmiana, która ma wpływ na wiele osób, z pewnością spowoduje falę zgłoszeń do pomocy technicznej.

Nadanie priorytetu kompatybilności wstecznej wiąże się również z dużymi pracami konserwacyjnymi. Obsługa bardzo dużej i zróżnicowanej bazy użytkowników jest świetna dla użytkownika końcowego, ale oznacza, że ​​programiści muszą dbać o to, aby ich kod działał w wielu różnych środowiskach. „Uwielbiam wspierać starsze wersje PHP w miarę dodawania nowych funkcji” — nie powiedział nigdy żaden programista!

Muszą się martwić nie tylko o starsze PHP — to także starsze bazy danych i dziesiątki innych odmian stosu WordPress. Przypadki brzegowe pojawiają się i wprawiają w zakłopotanie nawet ekspertów, gdy istnieje szerokie spektrum środowisk serwerowych WordPress z przestarzałymi elementami.

Najlepszy czas na podniesienie minimalnych wymagań PHP

Wydanie iThemes Security Pro 7.2 jest dobrym przykładem podniesienia minimalnych wymagań PHP produktu WordPress, aby zapewnić zarówno innowacyjność, jak i stabilność obecnym klientom.

Od wersji 7.2 iThemes Security Pro wymaga PHP 7.3 lub nowszego i obsługuje do 8.1. Decyzja o aktualizacji wymagań PHP dla iThemes Security Pro została podjęta w celu wdrożenia frameworka WebAuthn. Implementacja wymagała bibliotek, które potrzebują PHP 7.3+ do zarządzania szyfrowaniem i kluczami publicznymi. Funkcje 2FA, hasła i logowania biometrycznego wprowadzone w iThemes Security Pro 7.2 są bezpośrednim wynikiem tej decyzji. W czasie, gdy jego jasne hasła są łamane, zespół iThemes Security po raz pierwszy wprowadził logowanie bez hasła do WordPress jako podstawowe uwierzytelnianie użytkownika.

Byłoby możliwe zbudowanie tych funkcji przez przepisanie bibliotek WebAuthn w celu zapewnienia zgodności ze starszymi wersjami PHP. Oczywiście wymagałoby to znacznie więcej pracy i stworzenia dodatkowego kodu do utrzymania. Mądrzejszym rozwiązaniem było nadążanie za społecznością PHP w umiarkowanym tempie poprzez przyjęcie zależności, które wymagają PHP 7.3 lub nowszego. Większość ich użytkowników już tam była. Dlatego zespół programistów iThemes Security postanowił podnieść minimalne wymagania PHP dla nowych i obecnych użytkowników.

W przypadku produktów WordPress, które są mocno zainwestowane w edytor bloków Gutenberga, takich jak GiveWP, zarządzanie zmianami może być jeszcze trudniejsze. Stabilność i powolne tempo zmian w rdzeniu WordPressa może być frustrujące dla programistów PHP zaplecza, ale pozwala programistom front-endu JavaScript/React napędzać platformę do przodu.

Jason Adams, kierownik ds. rozwoju w GiveWP, zauważa, że ​​nie muszą one być wstecznie kompatybilne, ponieważ mogą przenosić użytkowników między wersjami w miarę rozwoju edytora witryny. Jednak „nie ma czegoś takiego jak migracja do PHP” — skomentował. W końcu będą musieli dostosować się do architektury PHP 9 i odejść od nowo przestarzałych funkcji w PHP 8.2.

Nie ma jednego „właściwego czasu” dla każdego produktu w całym ekosystemie WordPress na aktualizację minimalnych wymagań PHP. „To nie jest problem, który można rozwiązać filozoficznie” — powiedział mi Adams. To naprawdę zależy od osądu opartego na tym, ilu użytkowników będzie miało negatywny wpływ na zmianę. Jeśli 90% lub więcej korzysta z PHP 7.2 lub 7.4, podniesienie minimalnych wymagań do tego poziomu jest opłacalne.

Liczby te mogą się znacznie różnić w zależności od konkretnej bazy użytkowników produktu, mówi Adams. Produkt używany przez bardziej zaawansowanych technicznie klientów będzie bliższy obecnie obsługiwanym wersjom PHP. Produkt taki jak GiveWP, z którego korzysta wiele organizacji non-profit, będzie musiał położyć większy nacisk na kompatybilność wsteczną. Innym rozwiązaniem jest zezwolenie starszemu kodowi i jego użytkownikom na rozgałęzienie w długoterminowej wersji, która będzie obsługiwana, ale bez dodawania nowych funkcji. Kiedy użytkownicy będą gotowi do uaktualnienia, będą mogli przeprowadzić migrację do nowej głównej wersji stworzonej z myślą o przyszłej kompatybilności z PHP.

Powiadomienia o wycofaniu napędzają rozwój

WordPress.com właśnie wprowadził PHP 8.2 jako opcję dla swoich planów biznesowych i e-commerce z aktywowanymi funkcjami hostingu, a w ekosystemie WordPress.org jest mało prawdopodobne, aby dość dobrze zaprojektowany starszy kod zepsuł się lub stał się niepewny w następnej dużej wersji PHP wydanie. Mimo że podstawowa baza kodu WordPress.org oficjalnie oferuje tylko wsparcie „beta” dla PHP 8.0, generalnie działa dobrze z najnowszymi wersjami PHP, podobnie jak dobrze obsługiwane wtyczki. Nie będą zgłaszać błędów krytycznych ani błędów analizy. Nie powinieneś nawet widzieć wielu ostrzeżeń z włączonym debugowaniem. Możesz zobaczyć wiele powiadomień o przestarzałych funkcjach, które nie są jeszcze błędami.

Frustracje związane z szybkim cyklem wydawania PHP mają wiele wspólnego z tym, że programiści ugrzęzli w chwastach, refaktoryzując swój kod i nadrabiając zaległości z przestarzałymi aspektami PHP. Ta krytyczna praca może sprawić, że będą mieli mniej czasu na odkrywanie i wprowadzanie innowacji dzięki nowym koncepcjom i możliwościom, które przynosi najnowsza wersja PHP.

Jest inny sposób spojrzenia na tę sytuację. Radzenie sobie z przestarzałymi funkcjami PHP jest w rzeczywistości przyszłościowe i zmusza programistów do biegłości w kolejnych iteracjach ewoluującego języka. Bez tego nieco wymuszonego ćwiczenia, istniejąca wiedza łatwiej zadomowiłaby się w starych nawykach, które staną się złe, gdy staną się przestarzałe.

Powiadomienia o wycofaniu wskazują rzeczy, które działają teraz, ale będą się psuć w przyszłych wersjach PHP. To jest dobre dla ciebie, jeśli jesteś programistą, jak wyjaśnia Brent Roose. Jeśli programiści zwrócą uwagę na te powiadomienia, będą mieli mnóstwo czasu, aby zająć się każdym przestarzałym kodem. I nie powinno to blokować drobnych aktualizacji wersji.

Timothy Jacobs, główny programista iThemes ds. bezpieczeństwa i główny komisarz WordPress, mówi, że dobrze jest mieć ostrzeżenia o wycofaniu. Popychają programistów do przyjęcia „bardziej poprawnego” i „mniej delikatnego” kodu, który będzie coraz bardziej bezpieczny, wydajny, odporny na błędy i lepiej radził sobie z przypadkami brzegowymi. Z tego punktu widzenia powiadomienia E_DEPRECATED wypełniające dziennik błędów są „jak system wczesnego ostrzegania, że ​​w przyszłości coś się zepsuje, ale nie jest zepsute teraz”.

Rezygnacja z właściwości dynamicznych po PHP 8.2

Uzasadnienie Nikity Popova dotyczące wycofywania właściwości dynamicznych w PHP 9 jest dobrym przykładem ewolucyjnego dążenia PHP w kierunku bardziej odpornego kodu i konwencji programowania:

Motywacja do tej zmiany jest dwojaka: aby zapobiec błędom (spowodowanym literówkami lub zmianami nazw) w powszechnym przypadku oraz aby wyraźnie określić celowe użycie. Podstawowy problem polega na tym, że odczyt z nieistniejącej właściwości generuje diagnostykę, która natychmiast uwidacznia problem, podczas gdy zapis do nieistniejącej właściwości jest całkowicie cichy. PHP nie daje żadnej wskazówki, że programista popełnił błąd.

Dwuminutowy film Brenta Roose'a na temat ewolucji od PHP 5.6 do 8.2 jest błyskotliwą i prostą wizualną ilustracją tego, jak daleko PHP zaszło od 2014 roku do chwili obecnej. Na przykładzie prostego obiektu do przesyłania danych Roose pokazuje, jak kod PHP 5.6 drastycznie się kurczy do znacznie prostszego, szczuplejszego i ogólnie bardziej eleganckiego bloku kodu w drodze do PHP 8.2.

Jak zauważa Roose w swoich wskazówkach dotyczących postępowania z właściwościami dynamicznymi (które są przestarzałe w PHP 8.2), programiści powinni mieć dużo możliwości aktualizacji istniejącego kodu, zanim ostrzeżenia o deprecjacji zmienią się w błędy krytyczne. Jednak ten pas startowy szybko się zmniejszy, a WordPress jest przypadkiem szczególnym. Tonya Mork ma zaakceptowaną propozycję w Trac dotyczącą obsługi wycofania nieznanych właściwości dynamicznych w rdzeniu WordPress. Ona i Juliette Reinders Folmer martwią się, że programiści WordPressa nie będą mieli wystarczająco dużo czasu na refaktoryzację swojego kodu, nie wspominając o specjalnych wyzwaniach związanych z utrzymaniem kompatybilności w przód dla dwudziestoletniego projektu. Mork, Reinders Folmer i Sergey Biryukov byli w większości niedocenionymi bohaterami tego trudnego zadania.

W swoim omówieniu dynamicznych właściwości i magicznych metod w PHP 8.2 Mork i Reinders Folmer zwracają uwagę, że korzenie WordPressa w PHP 3 i 4 utrzymują go w solidnym, proceduralnym wszechświecie programowania, podczas gdy PHP nadal rozwija się jako język obiektowy. Główni programiści muszą znaleźć sposób na zachowanie zachowania starszego kodu we współczesnym PHP bez naruszania wstecznej kompatybilności, „a jednocześnie uczynić kod lepszym i bezpieczniejszym oraz złagodzić przestarzałe właściwości dynamiczne PHP 8.2”, jak to ujął Reinders Folmer. „Właściwie bardzo utrudniamy sobie życie przez zasadę braku [wstecznej kompatybilności] rdzenia [WordPress]”, zauważa w filmie.

„Istnieje ku temu dobry powód” — odpowiada Mork — „to dla użytkowników. Użytkownicy mają pewność, że mogą nacisnąć ten przycisk i dokonać aktualizacji, i że pomyśleliśmy o kompatybilności wstecznej, że nadaliśmy jej priorytet. To dla nas kamień węgielny… dzięki czemu użytkownicy mogą mieć pewność, że dokonają aktualizacji”.

Cały rozwój polega na utrzymaniu…

Wyjątkowym wyzwaniem jest przeniesienie „nowoczesnego” PHP do pracy z dwiema poprzednimi głównymi wersjami PHP w celu zachowania kompatybilności wstecznej w rdzeniu WordPress. Deweloperzy wtyczek mają znacznie łatwiejsze zadanie aktualizowania swojego kodu w sposób, który może wykorzystać nowe funkcje, takie jak klasy tylko do odczytu w PHP 8.2 i wycofywanie właściwości dynamicznych. Wiele z tych prac to także w dużej mierze forma konserwacji.

Architektonicznie zmiany, które wprowadza PHP 8+, koncentrują się na koncepcjach programistycznych, takich jak niezmienność. Niezmienne struktury danych „z natury nie rozwiązują problemów z bezpieczeństwem”, ale według Jacobsa pomagają programistom być mniej podatnym na błędy i bardziej poprawnym:

Nie powiedziałbym, że niezmienna struktura danych jest z natury bezpieczna, a zmienna struktura danych jest niepewna. Niezmienne struktury danych mogą raczej pomóc w wyeliminowaniu błędów programistycznych, które mogą prowadzić do problemów z bezpieczeństwem. Zmniejszając liczbę różnych stanów, w których może istnieć nasz kod, możemy zmniejszyć złożoność naszego kodu, a tym samym zmniejszyć ryzyko popełnienia błędów.

Najlepszym powodem utrzymywania kodu zgodnie ze standardem aktywnie wspieranych wersji PHP jest redukcja ryzyka związanego z bezpieczeństwem. Zdaniem Adamsa PHP 8.2 wprowadza przydatne udogodnienia i „bariery ochronne”, ale niewiele z nich może ekscytować programistów lub być postrzegane jako zmieniające zasady gry. Coś w rodzaju atrybutu #[\SensitiveParameter] może być bardziej praktyczne, ponieważ umożliwia filtrowanie poufnych danych ze śladów stosu, które często trafiają do usług innych firm. Wprowadzone w PHP 8 atrybuty to ostatnia innowacja Adamsa, która przykuła jego uwagę, umożliwiając coś, czego wcześniej nie można było zrobić: „opisz coś [jak klasy, zmienne, metody itp.] z metaperspektywy”.

Wykorzystanie nowych funkcji w PHP 8.0 do 8.2 i przyszłych wydaniach to miejsce, w którym kreatywność programistów może zabłysnąć, ale samo wspieranie tych wersji, aby wtyczki i rdzeń WordPressa na nich nie psuły się, jest zarówno praktyczne, jak i niezbędne.

…A każda konserwacja jest sztuką

Jeff Atwood ma stary, ale znakomity wpis na blogu zatytułowany „Szlachetna sztuka programowania konserwacji”, który przeczytałem niedawno dzięki Biuletynowi hakerskiemu Kale'a Davisa. „Programowanie konserwacji jest powszechnie postrzegane jako praca porządkowa” — pisze Atwood. Przypomniało mi to artystkę Mirele Laderman Ukeles, której „Maintenance Art Manifesto” zawsze wydawała mi się bardzo związana z programowaniem i tworzeniem stron internetowych:

Dwa podstawowe systemy: rozwój i utrzymanie. Kwaśna kula każdej rewolucji: po rewolucji, kto będzie zbierał śmieci w poniedziałek rano? […] Systemy rozwojowe to systemy częściowego sprzężenia zwrotnego, w których istnieje duże pole do zmian. Systemy konserwacji to systemy z bezpośrednim sprzężeniem zwrotnym, w których jest niewiele miejsca na zmiany.

Laderman Ukeles była młodą artystką i świeżo upieczoną matką w 1969 roku, kiedy napisała manifest i ogłosiła, że ​​konserwacja jest sztuką. Była sfrustrowana tym, jak najnowocześniejsze dzieła sztuki i praca o wysokim statusie są oddzielone od pracy, która je umożliwia: rodzicielstwa, nauczania umiejętności i tradycji artystycznych lub po prostu organizowania pokazu sztuki. Zrobiła niezapomnianą wystawę opartą na sobie, działając jako woźny w muzeum. Następnie spędziła większość swojej (ciągłej) kariery jako artystka-rezydentka Departamentu Sanitarnego miasta Nowy Jork. Jej pierwszym projektem w tej roli było osobiste podziękowanie wszystkim 8500 pracownikom sanitarnym „za utrzymanie Nowego Jorku przy życiu”.

Atwood ma podobne podejście do programowania. Cytuje kilka głównych osobistości w dziedzinie inżynierii oprogramowania, które twierdzą, że oczernianie prac konserwacyjnych jest całkowicie błędne. Robert L. Glass uważał, że „konserwacja jest znaczącym wyzwaniem intelektualnym, a także rozwiązaniem, a nie problemem”, dlatego należy ją traktować jako ważne zadanie dla najbardziej wykwalifikowanych ludzi. Joel Spolsky napisał dawno temu, że programiści są leniwi, a powodem, dla którego „zawsze chcą wyrzucić kod i zacząć od nowa”, jest to, że „trudniej jest przeczytać kod niż go napisać”.

W rozmowie z Andym Huntem Dave Thomas argumentował: „Całe programowanie to programowanie konserwacyjne, ponieważ rzadko piszesz oryginalny kod. …. Większość czasu spędzasz w trybie konserwacji. Więc równie dobrze możesz po prostu ugryźć kulę i powiedzieć: „Utrzymuję od pierwszego dnia”. Dyscypliny, które dotyczą konserwacji, powinny obowiązywać na całym świecie”. Hunt zgodził się: „Kod jest oryginalny tylko przez pierwsze 10 minut, kiedy wpisujesz go po raz pierwszy. Otóż ​​to."

Atwood ostatecznie skłania się ku temu punktowi widzenia, ale przypomina wspólną perspektywę programistów WordPress, którą słyszałem od Jasona Adamsa i Timothy'ego Jacobsa. Specjalna sztuka rozwoju/utrzymania WordPressa?

„To balansowanie”.

Najlepsza wtyczka zabezpieczająca WordPress do zabezpieczania i ochrony WordPress teraz 35% taniej!

WordPress obsługuje obecnie ponad 40% wszystkich stron internetowych, więc stał się łatwym celem dla hakerów o złośliwych zamiarach. Wtyczka iThemes Security Pro usuwa zgadywanie z zabezpieczeń WordPress, aby ułatwić zabezpieczanie i ochronę witryny WordPress. To tak, jakby zatrudnić pełnoetatowego eksperta ds. bezpieczeństwa, który stale monitoruje i chroni Twoją witrynę WordPress.

Zaoszczędź 35% teraz!