В ноябре прошлого года 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: 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} брошен в /blog/wp-content/themes/generatepress/inc/structure/post-meta.php на линии 169
исправлено! Ну, почти
К счастью, первая строка была ключевой, именно там были вызваны все ошибки в этом длинном списке:
Фатальная ошибка: Uncaught TypeError: Unsupported operand types: string + int in /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 или что это за хрень на этот раз.
