W listopadzie ubiegłego roku pojawił się PHP 8, który zapowiadał poprawę wydajności, szybkości i bezpieczeństwa.
Jak każdy dobry majsterkowicz, pobiegłem zaktualizować wersję 7.4, a konkretnie 7.4.16, która obecnie działa na serwerze.
plof! przywitał mnie miły błąd 500 i zepsuł całą witrynę. Żaden adres URL nie został rozwiązany.
Wykonałem typowy test polegający na wyłączeniu wszystkich wtyczek i użyciu domyślnego szablonu. Błąd 500 nie zniknął.
Byłem zszokowany, ale zdałem sprawę przekonany, że jest jeszcze za wcześnie na aktualizację i, jak radzili, najlepiej poczekać, aż wszyscy autorzy wtyczek i szablonów zaktualizują swój kod, aby był kompatybilny z PHP 8.
Prawie siedem miesięcy później spróbowałem ponownie i błąd 500 nadal występował.
Pierwszą wskazówką, że źródłem błędu jest tylko ten blog, jest to, że w pozostałych dwóch instalacjach WordPressa, które mam na tym samym serwerze, wszystko działa poprawnie.
Ponieważ błąd 500 może pojawić się z wielu powodów. Następnym logicznym krokiem jest wyciągnięcie dzienników błędów, aby spróbować dowiedzieć się, co jest nie tak. Pojawia się następujący ciąg ostrzeżeń:
PHP Warning: Use of undefined constant minor - assumed 'minor' (this will throw an Error in a future version of PHP) in /home/xxxxxx/public_html/blog/wp-config.php on line 11
Ostrzeżenie PHP: Use of the undefined constant minor - assumed 'minor' (this will throw an Error in a future version of PHP).
Oznacza to, że stała powinna być ujęta w cudzysłów. Idę do wp-config.php i rzeczywiście, minor pojawia się bez cudzysłowów w tej linii.
define ('WP_AUTO_UPDATE_CORE', minor);
Przeszukując forum WordPress stwierdzam, że wiele osób miało ten sam problem z aktualizacją do starszych wersji PHP z powodu konfliktów z wtyczką lub szablonem.
Nie można również wykluczyć, że problem jest związany z instalacją WordPressa, która ma coś zepsutego, jak powiedziano mi w zgłoszeniu, które wysłałem do LucusHost.
W niektórych otrzymanych odpowiedziach piszą, że aby rozwiązać problem wystarczy dodać cudzysłów do "minor", więc proszę spróbować i tak właśnie zrobiłem
define ('WP_AUTO_UPDATE_CORE', 'minor');
WP_AUTO_UPDATE_CORE pozwala kontrolować aktualizacje rdzenia WordPressa dla wersji minor, major i development. Ta stała może być zdefiniowana na kilka sposobów. Usunięcie tej linii nie jest dobrym pomysłem.
#Wyłącza wszystkie aktualizacje rdzenia:
define( 'WP_AUTO_UPDATE_CORE', false );
# Włącza wszystkie aktualizacje, w tym mniejsze i większe aktualizacje:
define( 'WP_AUTO_UPDATE_CORE', true );
# Włącza pomniejsze aktualizacje:
define( 'WP_AUTO_UPDATE_CORE', 'minor' );
Dobra i zła wiadomość.
Dobra wiadomość jest taka, że teraz, po uruchomieniu PHP 8, błąd 500 zniknął.
Na pierwszy rzut oka wszystko wydaje się działać dobrze, zarówno wtyczki, jak i posty.
Zła wiadomość jest taka, że indeks jest uszkodzony i wygląda tak.
Postanowiłem najpierw zaatakować szablon postu, wykonany za pomocą Elementora Pro, na wypadek, gdyby konstruktor zostawił jakieś ukryte śmieci, ale po przejrzeniu go i całkowitym przerobieniu wykluczyłem, że błąd pochodzi stamtąd.
Teraz wciąż sprawdzam szablon(GeneratePress Premium) w środowisku testowym i przynajmniej wiem, gdzie się psuje, ale głównie szukam w WordPressie, który moim zdaniem jest sednem sprawy, jakiś nieaktualny kod wciągnięty, jakiś filtr zatkany smarem lub cokolwiek innego.
Zostawiam tę notatkę tutaj na wypadek, gdyby ktoś miał podobny problem i byłoby to pomocne, lub to, co tu napisałem, lub wie dużo o WP i może dać mi więcej wskazówek, aby go rozwiązać.
Jak tylko znajdę ostateczne rozwiązanie i możliwe wyjaśnienie, zaktualizuję ten post.
Aktualizacja
Dziennik błędów, po włączeniu DEBUG, daje wskazówki, że GeneratePress gdzieś się zawiesza, być może z powodu jakiegoś haka lub filtra, który umieściłem w jego module Elements (lub czymkolwiek innym).
Ponieważ mam szablon potomny GeneratePress, jestem zagubiony i nie wiem, dokąd się stąd udać, ale ponieważ mam kilka podejrzeń, nie uważam jeszcze misji za nieudaną.
Błąd krytyczny: Uncaught TypeError: Unsupported operand types: string int in /home/ public_html/blog/wp-content/themes/generatepress/inc/structure/post-meta.php:169 Stack trace: #0
/home/ public_html/blog/wp-content/themes/generatepress/inc/structure/post-meta.php(419): generate_do_post_meta_item() #1
/home/ public_html/blog/wp-content/themes/generatepress/inc/structure/post-meta.php(538): generate_posted_on() #2
/home/ public_html/blog/wp-includes/class-wp-hook.php(292): generate_post_meta() #3
/home/ public_html/blog/wp-includes/class-wp-hook.php(316): WP_Hook->apply_filters() #4
/blog/wp-includes/plugin.php(484): WP_Hook->do_action() #5
/blog/wp-content/themes/generatepress/content.php(48): do_action() #6
/blog/wp-includes/template.php(732): require('/home/ ...') #7
/blog/wp-includes/template.php(676): load_template() #8
/blog/wp-includes/general-template.php(204): locate_template() #9
/blog/wp-content/themes/generatepress/inc/theme-functions.php(587): get_template_part() #10
/blog/wp-content/themes/generatepress/index.php(37): generate_do_template_part() #11
/blog/wp-includes/template-loader.php(106): include('/home/ ...') #12
/blog/wp-blog-header.php(19): require_once('/home/ ...') #13
/blog/index.php(17): require('/home/ ...') #14
{main} rzucone w /blog/wp-content/themes/generatepress/inc/structure/post-meta.php na linii 169
naprawione! No, prawie
Na szczęście kluczowa okazała się pierwsza linijka, w której pojawiały się wszystkie błędy z tej długiej listy:
Błąd krytyczny: Uncaught TypeError: Unsupported operand types: string int in /home/ public_html/blog/wp-content/themes/generatepress/inc/structure/post-meta.php:169
Tajemnica błędu tkwiła w jakiejś nieobsługiwanej operacji cholernego get_the_time .
Łącząc to wszystko razem, podejrzenia się potwierdziły. Błąd został spowodowany przez ten fragment funkcji, którego użyłem do pokazania dnia i godziny aktualizacji jako rozszerzenia meta w dacie.
Co gorsza, nie wiem jak, ale pozostał on rezydentny po wyłączeniu Code Snippets i wyczyszczeniu pamięci podręcznej.
Morał z tej historii, proszę nie używać funkcji, które działają dobrze dla innych, ponieważ każda strona ma swoją własną historię i jest bardzo prawdopodobne, że coś zepsują, jeśli o nich zapomnisz, zaktualizujesz WP, PHP, szablon lub wtyczkę i nie będą już kompatybilne.
Po usunięciu tego fragmentu wszystko działa dobrze, a strona główna wraca do normy.
Nie ma dwóch bez trzech, kolejny błąd. Teraz Feedzy
Ale proszę jeszcze nie odchodzić, teraz wtyczka Feedzy (jak sądzę) lub coś z nią związanego psuje stronę z wiadomościami.
Nadszedł czas, aby otworzyć zgłoszenie do pomocy technicznej, ponieważ jest to wersja płatna, aby poinformować twórców wtyczki, czy jest ona w 100% kompatybilna z PHP 8 (i czy psuje się, ponieważ nie jest) lub uzyskać od nich wskazówkę.
02/07/2021- Feedly odtworzyło fatalny błąd przy użyciu PHP 8 i przekazało problem swoim programistom, teraz musimy poczekać, aż wydadzą nową wersję wtyczki, która naprawi problem.
05/07/2021- Opis błędu jest już dostępny na ich Githubie.
06/07/2021 - Chociaż nie odpowiedzieli jeszcze ani nie wydali nowej wersji z poprawką, w tym zatwierdzeniu można znaleźć linie kodu, które to naprawiają. Przetestowałem to i, w oczekiwaniu na dobre i dokładne testy, wydaje się, że PHP 8 niczego już nie psuje.
Podsumowując
Nie jest źle. Od posiadania błędu 500, który zepsuł cały blog, do posiadania go tylko na stronie głównej i wreszcie na jednej"drugorzędnej" stronie, aby w końcu znaleźć poprawkę, wystarczy, aby być zadowolonym z godzin zainwestowanych w naprawę.
Kluczem do wszystkiego jest badanie, spędzanie całego czasu na szukaniu źródła i tego, co powoduje w innych częściach bloga. Proszę nie próbować szybkich rozwiązań bez wystarczających wskazówek, ponieważ albo stracą Państwo czas, albo w zły sposób zepsują coś innego.
Zaktualizuję ponownie, gdy uda mi się pokonać nowy błąd za pomocą Feedzy lub cokolwiek to jest tym razem.
