Jak sprawdzić czy nasza strona będzie działać z PHP 7

PHP Compatibility Checker

Na WPzen od zawsze namawiam do korzystania z możliwie nowych (a na pewno ze wciąż wspieranych) wersji interpretera PHP – czyli na tę chwilę z 5.6, 7.0 lub 7.1. Ogólnie można przyjąć, że użytkownicy WordPressa dość niefrasobliwie podchodzą do tematu, ale na szczęście powoli się to zmienia. W lipcu ubiegłego roku z niewspieranych wersji PHP korzystało prawie 80% instalacji tego CMSa, a 10 miesięcy później już „tylko” nieco ponad 50%.

Jedną z najczęstszych przyczyn trzymania się starej wersji PHP jest obawa o kompatybilność strony z nowszą wersją interpretera. Problem ten jest szczególnie poważny w przypadku większych serwisów z dużą liczbą zainstalowanych wtyczek i/lub z wtyczkami i motywem pisanymi na zamówienie. Na szczęście istnieje prosty sposób na sprawdzenie czy nasza strona będzie bez problemu działać z nowszą wersją PHP.

Po co korzystać z nowszej wersji PHP?

Ze wspieranych przez twórców wersji interpretera PHP powinniśmy korzystać przede wszystkim dlatego, że tylko dla tych wersji przygotowywane są poprawki, w tym również te związane z bezpieczeństwem.

Jeśli wciąż korzystamy z PHP w wesji 5.x (wersja 5.6 jest wciąż wspierana), to warto rozważyć przejście na nowszą wersję 7.0 lub 7.1. Z punktu widzenia użytkownika główną zaletą jest zauważalny wzrost wydajności – z testów wynika, że nawet dwukrotny! Oczywiście nie oznacza to, że nasza strona będzie ładować się dwa razy szybciej, bo czynników o tym decydujących jest znacznie więcej, ale każda poprawka wydajności jest dla nas cenna.

Sprawdzamy czy nasza strona zadziała z PHP 7

Oczywiście najpewniejszą metodą na sprawdzenie kompatybilności naszej strony z nowszą wersją PHP jest stworzenie roboczej kopii serwisu i samodzielne jej przetestowanie. Nie wszyscy jednak mogą, chcą lub potrafią to zrobić. Na szczęście istnieje mniej pracochłonna i znacznie prostsza metoda – wystarczy skorzystać z darmowej wtyczki PHP Compatibility Checker.

Wtyczkę instalujemy na stronie, którą chcemy przetestować. Po aktywacji rozszerzenia w panelu administracyjnym przechodzimy do sekcji Narzędzia → PHP Compatibility.

PHP Compatibility Checker

Wtyczka daje nam możliwość sprawdzenia kompatybilności naszej strony z różnymi wersjami PHP, dzięki czemu przyda się ona również osobom, które utknęły na starych i niewspieranych wersjach interpretera (starszych niż 5.6). Niestety, wtyczka nie ma opcji sprawdzania kompatybilności strony z PHP 7.1.

Po wybraniu interesującej nas wersji PHP określamy, czy narzędzie ma przeskanować wszystkie zainstalowane wtyczki i motywy (Scan all plugins and themes) czy tylko te aktywne (Only scan active plugins and themes), a następnie klikamy przycisk Scan site.

Po zakończeniu skanowania wtyczka wyświetli listę sprawdzonych wtyczek i motywów wraz z informacjami o ich kompatybilności w wybraną wersją PHP.

PHP Compatibility Checker

Na zamieszczonym powyżej zrzucie ekranu widać, że jedna z wtyczek nie przeszła testu – o ile cztery ostrzeżenia (warnings) można zignorować, o tyle dwóch błędów (errors) już nie. Kliknięcie linku toggle details pozwala na zapoznanie się ze szczegółowymi informacjami na temat znalezionych problemów.

PHP Compatibility Checker

I tu niestety zła wiadomość: osoby nie będące programistami z większością problemów po prostu sobie nie poradzą. Widoczny raport można jednak skopiować i wysłać autorowi motywu lub wtyczki, który z pewnością będzie wiedział co zrobić.

Wtyczka nie jest oczywiście idealna. Zdarza się, że niepotrzebnie zgłasza ona problem z jakimś rozszerzeniem (false positive), ale to nie do uniknięcia w przypadku na przykład fragmentów kodu odpowiedzialnych za wsteczną kompatybilność ze starszymi wersjami PHP. Może się również zdarzyć, że mimo braku wykrytych problemów po przejściu na nowszą wersję PHP coś jednak przestanie działać. Nie zmienia to jednak faktu, że narzędzie to może przydać się do wczesnego wykrywania potencjalnych błędów i poprawianie ich zanim pojawią się na produkcyjnej wersji naszej strony.

Bezpośredni link

  • Od siebie mogę powiedzieć tyle, że motywy TemplateMonster postawione na Cherry v3 nie są kompatybilne z PHP 7+, także przed zakupem tych radzę się zastanowić.

    • A co z Cherry 4.x?

      • V4 ma zupełnie inną budowę(częściowo modularną) i często do nich dorzucało się wtyczki, które korzystały z przestarzałych funkcji itp. – tutaj chyba nie trzeba tłumaczyć ewentualnych konsekwencji :) Skórki z v4, które próbowałem ustawiać na php 7.1 się wyłożyły ale nie jestem w stanie powiedzieć, czy to jest zasada. Jeśli miałbym stawiać, to na tak ale znowu ręki nie dam uciąć, bo „goła” wersja frameworka może sobie dawać radę(problemy przy php7+ były od modułów).

        Wiem, że na pewno ich darmowy motyw na v4:
        https://www.templatemonster.com/wordpress-themes/54803.html
        – wyłoży się na php7+

        Generalnie jednak jest bardzo mało skórek na v4 i zazwyczaj jest v3 albo od razu v5(nie mam pojęcia dlaczego tak mało motywów mają na v4 – ktoś z lead designerów może dał ciała), gdzie ten drugi nie będzie robił problemów. Na plus – wszystko powoli przerabiają na v5, włącznie z darmowymi skórkami. Mnie osobiście v5 kompletnie nie pasuje ale to już moja dygresja.

        • Pozwolę sobie nie pogodzić z Panem, że dla V4 jest mało :) Ich 107 :) I tendencja jest taka, że motywy zbudowane w oparciu o Cherry Framework 3.x są usuwane, bo jednak przestrzały. Mogę polecić motywy V5, które są GPL. Na obecną chwilę ich już 320+. No i one muszą działać z 7.1 :)

          • No właśnie Panie Januszu problem jest z tym, że TM jest ze wszystkim trochę w tyle, a nawet bardzo.

            Cherry v3 to Boostrap w wersji 2, czyli swoje czasy świetności miał w 2013 roku – wchodząc na TM bez problemu znajdę na głównych stronach jeszcze skórki, które są oparte o v3, co tak naprawdę nie powinno mieć miejsca. Ponadto cherry plugin(część składowa frameworka) w wersji mniejszej, niż 1.2.8.0 miała całkiem poważną dziurę bezpieczeństwa – nadal są sprzedawane skórki, które owy plugin w wersji mniejszej posiadają i się w żaden sposób automatycznie do tej wersji nie zaktualizuje(chyba, że ktoś wie o problemie ale bądźmy szczerzy, to jest naprawdę niewielki odsetek ludzi).

            Bootstrap w wersji 3(tj. Release candidate) pojawił się zaledwie kilkanaście dni później od pierwszej wersji v2.
            Mamy tutaj różnicę 18 Jul 2013 – 27 Jul 2013
            (dane biorę na podstawie dat wydań z githuba: https://github.com/twbs/bootstrap/releases)
            – jednak na tym etapie nikt w górnych szczeblach developu nie pomyślał o integracji BSa v3 pod cherry v3, tylko z jakiegoś powodu jechano dalej na v2, zapewne tak wyszło „taniej”, aniżeli przebudowywanie frameworka.

            Cherry v4 oparty na bootstrap v3 zostaje wydany w czerwcu 2015:
            https://github.com/CherryFramework/cherryframework4/releases?after=v4.0.2
            – od tego czasu do dzisiaj(2017 rok, maj) mówi Pan dokładnie o 107 sztukach skórek, gdzie w latach 2013-2015 skórek na Cherry v3 pojawiło się kilkaset? Nie znam dokładnej liczby ale na pewno kilkakrotnie więcej. Widać tutaj wielką niechęć do własnego tworu, który był całkiem chętnie reklamowany swojego czasu. Dla mnie to był krok w przód ale skórek z Cherry v4 po prostu nie pojawiało się wiele, 100 sztuk na kilkanaście kategorii różnych branż to naprawdę niewielki wybór.

            Na dzień dzisiejszy pojawia się coraz więcej skórek v5, co jest jak najbardziej ok i widzę, że nawet część darmowych została przekonwertowana na v5 ale przyznam szczerze, że design nowych skórek na TM jest po prostu przeciętny. Poza tym problemem jest kluczowa kwestia, którą zacytuję u bezpośrednio od Pana:
            tendencja jest taka, że motywy zbudowane w oparciu o Cherry Framework 3.x są usuwane
            – zdanie powinno brzmieć „wszystkie motywy oparte o cherry v3 zostały usunięte”.

            Wiem, że w tak potężnej firmie nie jest to kwestia dni, czy nawet miesięcy przy takiej ilości motywów ale uważam, że TM jest na tyle tuży, że posiada odpowiednie siły przerobowe, aby przyspieszyć proces.

            Nie mam nic do Pana i wiem też, że Pan osobiście nie ma nic wspólnego z developerką na TM ale ktoś na górze u was podejmuje nie do końca trafne decyzje. Widać to również po środowisku profesjonalistów, którzy lekko mówiac stronią od motywów z TM – i ciężko im się dziwić.

            Życzę, aby TM rozwijało się jak najlepiej ale nie widzę obecnie scenariusza, w którym dałoby się wytłumaczyć dlaczego nadal są sprzedawane motywy na v3 – może nawet i v4, bo ten powinien być również już w pełni kompatybilny z php 7+ nawet jeśli sam framework nie jest już rozwijany. Ot co po prostu ze względu na prawidłowe podejście do tematu i nie olewanie kwestii bezpieczeństwa i optymalizacji(z którymi nie oszukujmy się, TM miał problem).

            Wiem, że to ostra krytyka z mojej strony ale jeśli przełoży się ona w jakikolwiek sposób na jakość usług, to jak najbardziej na miejscu :)

          • Krytyka jest ok. Bo bez tego nie można tworzyć normalnych produktów. Dziękuję Panu i przekażę ten komentarz do developerów. Zawsze im przekazuję uwagi, ale jak pisał Pan, nie mam wpływu na ten dział.
            P.S. Zaskoczył mi Pan tym pytaniem. Ale mogę powiedzieć szczerze, że komanda developerów WP nie jest duża i zawsze braknie rąk.

  • Mam pytanie wykonałem test i okazało się, że 2 wtyczki Google Analytics Dashboard for WP (GADWP) i Popup Maker „The plugin/theme was skipped as it was too large to scan before the server killed the process.” nie zostały zbadane. Natomiast wtyczka Toolset Types ma 21 ostrzeżenia – czy nie lepiej przed przełączeniem na wyższą wersje PHP byłoby wyłączenie i być może nawet usunięcie tych wtyczek, a później ich ponowną instalację?

    • Paweł Knapek

      Nie bardzo wiem jaki sens w tym. Możesz załączyć tryb debug (albo patrzeć w error loga), przełączyć na wyższą wersję i będziesz widział czy strona działa i sypie jakimiś poważniejszymi błędami czy nie. Jak działa i brak poważnych błędów, to ok. A jak nie działa, to zobaczysz w którym miejscu się sypie i albo zdezaktywujesz ręcznie przykładowo felerną wtyczkę, albo cofniesz do pierwotnej wersji PHP’a i będziesz czekał na aktualizacje. Wbrew pozorom nic strasznego.
      Poza tym jak Bartosz na końcu wspomniał, wtyczka jest tylko pomocą, a nie nieomylną wyrocznią -wynik skanu należy jeszcze poddać interpretacji, bo może być zafałszowany np. wsteczną kompatybilnością.

      • Przełączyłem się na ver.7.1 na razie nie działa mi wysyłanie przez –

        Contact Form 7 – natomiast nie mogę być pewien czy to na pewno sama zmiana wersji PHP to wykonała. Innych błędów nie wykryłem. Mógłbyś dwa słowa o logach napisać, włączyłem opcję debagowania – może warto skorzystać z wtyczki?

        • Paweł Knapek

          W dużym skrócie, jak w wp-configu ustawisz sobie WP_DEBUG na true i WP_DEBUG_LOG na true (warto też ustawić WP_DEBUG_DISPLAY na false – co by inni nie widzieli komunikatów na stronie), to w katalogu wp-content pojawi się plik debug.log, w którym będą logowane błędy.
          Natomiast bardziej szczegółowe są bezpośrednie logi serwera, tutaj tzw. Error Log. Dostęp do nich jest już uzależniony od hostingu – na jednych jest dostępny z poziomu panelu administracyjnego, na innych z poziomu sFTP/SSH, na innych zaś poprzez support hostingu.

          • Prawdopodobnie nie chodzi o PHP. Jedynie co na razie udało mi się ustalić to błąd „” podczas kliknięcia przycisku wyślij( Contact Form 7) – obraca się ale nic się nie dzieje. Tutaj są pewne sugestie co może być nie tak – https://contactform7.com/why-isnt-my-ajax-contact-form-working-correctly/ jednak na razie nie wpadłem co to.

            Ciekawostką natomiast jest fakt, że mimo konfiguracji https://codex.wordpress.org/Debugging_in_WordPress – nie pojawił mi się plik – „/wp-content/debug.log file” – stąd wnioskuje, że to nie PHP.

            Zastanawiam się czy to może nie użycie – wtyczki Autoptimize czegoś nie namieszało.