У листопаді минулого року вийшов PHP 8. У ньому було оголошено про деякі покращення продуктивності, швидкості та безпеки.
Як і будь-який хороший майстер, я побіг оновлюватись з 7.4, а саме з 7.4.16, версії, яка зараз працює на сервері.
і тут мене зустрічає приємна помилка 500, яка ламає весь сайт. Жодна URL-адреса не вирішується.
Я провів типовий тест вимкнувши всі плагіни і використовуючи шаблон за замовчуванням. Помилка 500 не зникла.
Я був шокований, але змирився з цим, будучи переконаним, що ще занадто рано оновлюватися і, як мені порадили, найкраще почекати, поки всі автори плагінів і шаблонів оновлять свій код, щоб зробити його сумісним з PHP 8.
Майже через сім місяців я спробував ще раз, але помилка 500 все ще була там.
Першою ознакою того, що помилка виникає лише в цьому блозі, є те, що в інших двох інсталяціях WordPress, які я встановив на тому ж сервері, все працює коректно.
Оскільки помилка 500 може з'явитися з багатьох причин. Наступним логічним кроком буде витягнути журнали помилок, щоб спробувати з'ясувати, в чому справа. З'являється рядок попереджень на кшталт цього:
PHP Попередження: Використання невизначеної константи minor - припускається 'minor' (це призведе до помилки в майбутній версії PHP) в /home/xxxxxx/public_html/blog/wp-config.php на рядку 11
Попередження PHP: Використання невизначеної константи minor - передбачається 'minor' (це призведе до помилки в майбутній версії PHP).
Тобто, константа повинна бути взята в лапки. Я заходжу в wp-config.php і, звичайно ж, в цьому рядку з'являється minor без лапок.
define ('WP_AUTO_UPDATE_CORE', minor);
Пошукавши на форумі WordPress, я виявив, що багато людей стикалися з такою ж проблемою при оновленні до старіших версій PHP через конфлікти з плагінами або шаблонами.
Також не можна виключати, що проблема пов'язана з установкою WordPress, в якій щось зламалося, як мені повідомили в тікеті, який я відправив на LucusHost.
У деяких відповідях, які вони отримують, вони кажуть, що для вирішення проблеми просто додайте лапки до "minor", тож спробуйте, і це те, що я зробив
define ('WP_AUTO_UPDATE_CORE', 'minor');
WP_AUTO_UPDATE_CORE дозволяє контролювати оновлення ядра WordPress для мінорних, основних і девелоперських версій. Ця константа може бути визначена кількома способами. Видалення цього рядка не є гарною ідеєю.
#Вимикає всі оновлення ядра:
define( 'WP_AUTO_UPDATE_CORE', false );
# Увімкнути всі оновлення, включаючи малі та великі оновлення:
define( 'WP_AUTO_UPDATE_CORE', true );
# Вмикає мінорні оновлення:
define( 'WP_AUTO_UPDATE_CORE', 'minor' );
Є хороші і погані новини.
Хороша новина полягає в тому, що тепер, під час запуску PHP 8, помилка 500 зникла.
На перший погляд, все працює нормально, як плагіни, так і пости.
Погана новина полягає в тому, що індекс зламався і виглядає ось так.
Я вирішив атакувати спочатку шаблон шаблон постушаблон, зроблений за допомогою Elementor Proна випадок, якщо конструктор залишив якесь приховане сміття, але переглянувши його і переробивши повністю, я виключив, що помилка походить звідти.
Зараз я все ще видаляю шаблон (GeneratePress Premium) в тестовому середовищі і принаймні знаю, де він ламається, але в основному я дивлюся на WordPress, де, на мою думку, криється суть проблеми, якийсь застарілий код, якийсь фільтр, забитий жиром або ще щось.
Я залишаю цю замітку тут на випадок, якщо у когось була подібна проблема, і вона може бути корисною, або те, що я написав тут, або хтось знає багато про WP і може дати мені ще кілька підказок, як її вирішити.
Як тільки я знайду остаточне виправлення і можливе пояснення, я оновлю цей пост.
Оновлення
Журнал помилок, після активації DEBUG, дає підказки, що GeneratePress десь падає, можливо, через якийсь хук або фільтр, який я поставив в його модулі Elements (або щось подібне).
Оскільки у мене є дочірній шаблон GeneratePress, я розгубився і не знаю, куди рухатися далі, але оскільки у мене є пара підозр, я ще не вважаю місію проваленою.
Фатальна помилка: Uncaught TypeError: Непідтримувані типи операндів: string + int в /home/ public_html/blog/wp-content/themes/generatepress/inc/structure/post-meta.php:169 Трасування стеку: #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
у файлі /blog/wp-content/themes/generatepress/inc/structure/post-meta.php на 169-му рядку виникла помилка {main}
виправлено! Ну, майже
На щастя, перший рядок був ключовим, саме він викликав усі помилки з цього довгого списку:
Фатальна помилка: Uncaught TypeError: Непідтримувані типи операндів: string + int в /home/ public_html/blog/wp-content/themes/generatepress/inc/structure/post-meta.php:169
Загадка помилки полягала в якійсь непідтримуваній операції клятого get_the_time .
Зв'язавши все докупи, підозри підтвердилися. Помилка була викликана цим фрагментом функції, який я використовував для відображення дня і часу оновлення як розширення мета в даті.
Що ще гірше, я не знаю як, але він залишився резидентним після відключення Фрагменти коду і очищення кешу.
Мораль цієї історії: не використовуйте функції, які добре працюють для інших, тому що кожна сторінка має свою особливу історію, і дуже ймовірно, що вони в кінцевому підсумку щось зіпсують, якщо ви забудете їх, оновите WP, PHP, шаблон або плагін, і вони більше не будуть сумісні.
Видаливши цей фрагмент, все працює нормально, і домашня сторінка повернулася до нормального вигляду.
Немає двох без трьох, ще одна помилка. Тепер Feedzy
Але не розходьтеся, тому що тепер плагін Плагін Feedzy (напевно) або щось з ним пов'язане обриває сторінку новин.
Настав час відкрити тікет підтримки, оскільки це платна версія, щоб повідомити розробникам плагіна, чи сумісний він на 100% з PHP 8 (і якщо він ламається через те, що це не так), або отримати від них підказку.
02/07/2021 - Feedly відтворив фатальну помилку, використовуючи PHP 8, і передав проблему своїм розробникам, тепер нам залишається чекати, коли вони випустять нову версію плагіна, яка виправляє проблему.
05/07/2021 - Опис помилки тепер доступний на їхньому Github.
06/07/2021 - Хоча вони ще не відповіли і не випустили нову версію з виправленням, в цьому коміті вже є рядки коду, які виправляють цю помилку. Я протестував його і, за відсутності хорошого і ретельного тестування, здається, що PHP 8 більше нічого не ламає.
Підводячи підсумки
Непогано. Від помилки 500, яка зламала весь блог, до помилки лише на головній сторінці і, нарешті, на одній"другорядній" сторінці, щоб в кінцевому підсумку знайти виправлення - цього достатньо, щоб бути задоволеним годинами, витраченими на ремонт.
Ключ до всього - в дослідженні, витратьте весь свій час на пошук джерела проблеми і її причин в інших частинах вашого блогу. Не намагайтеся швидко вирішити проблему без достатньої кількості підказок, тому що ви або витратите свій час, або, в гіршому випадку, зламаєте щось ще.
Я оновлю статтю, коли мені вдасться виправити новий баг за допомогою Feedzy чи як там його цього разу.
