Бял екран в WordPress: прочетете грешката, преди да пипате сайта

Фатална грешка или бял екран: една и съща повреда

Белият екран най-често е фатална грешка на PHP: файл от сайта е поискал нещо невъзможно и изпълнението е спряло, преди да покаже каквото и да било. От WordPress 5.2 насам WordPress прихваща тези грешки: вместо празна страница показва „Има фатална грешка на този уебсайт.“ и изпраща имейл до административния имейл адрес на сайта.

Страницата остава напълно бяла в няколко случая: по-стара версия на WordPress, грешка, настъпила преди зареждането на този механизъм, константата WP_DISABLE_FATAL_ERROR_HANDLER, зададена на true, или разширение за кеш, което сервира празна страница, запазена по време на повредата. Методът по-долу важи за всички тези случаи.

Три действия могат да почакат, докато прочетете грешката: преинсталиране на WordPress, изтриване на разширения, възстановяване на старо резервно копие. Всяко от тях може да изтрие настройки или скорошни данни, а съобщението за грешка обикновено казва кой компонент да изключите, без да губите нищо.

Прекият път: режимът за възстановяване

Когато WordPress прихване грешката, той изпраща до административния имейл адрес на сайта съобщение със заглавие „[Име на сайта] Сайтът ви има технически проблем“. То назовава разширението или темата, причинили грешката, и съдържа връзка, която отваря администрацията в режим за възстановяване.

• В този режим проблемният компонент е поставен на пауза само за вас: посетителите ви продължават да виждат грешката.
• От Разширения или Изглед > Теми деактивирайте сигнализирания компонент, след това кликнете върху „Излизане от режим за възстановяване“ в административната лента.
• Връзката е валидна 24 часа и WordPress изпраща най-много един такъв имейл на ден. Ако имейлът не пристигне, проверете папката за спам, след това преминете към следващия метод.

Прочетете грешката: журналът за отстраняване на грешки

Свържете се със сайта по SFTP или през файловия мениджър на хостинг доставчика, отворете wp-config.php в корена и заменете реда define( 'WP_DEBUG', false ); с тези четири реда:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

Те се поставят над коментара, който затваря редактируемата част на файла (/* That's all, stop editing! Happy publishing. */, който и в WordPress на български остава на английски). Презаредете страницата с грешката, след това отворете wp-content/debug.log. WP_DEBUG_DISPLAY със стойност false държи съобщенията във файла, извън страницата, която виждат посетителите ви.

Ако debug.log остане празен или не се появи, грешката е записана директно от PHP: потърсете файл error_log в корена на сайта или в wp-admin, или раздела с журнали за грешки в панела на хостинг доставчика.

Какво казва съобщението и кое действие му отговаря

Фаталната грешка се побира в един ред: видът на грешката, описанието ѝ, след това in, последвано от пълния път до файла и номера на реда. Пътят е най-полезната информация: wp-content/plugins/ime/ означава разширение, wp-content/themes/ime/ означава тема.

define( 'WP_MEMORY_LIMIT', '256M' );

Изключете проблемния компонент без администрацията

По SFTP или през файловия мениджър

Преименувайте папката на разширението, посочено в съобщението, например wp-content/plugins/ime-na-razshirenie на ime-na-razshirenie.off. WordPress вече не намира разширението и спира да го зарежда; настройките му остават записани в базата данни, а WordPress го деактивира при следващото отваряне на екрана с разширенията.

При тема преименуването на папката ѝ в wp-content/themes отново дава достъп до администрацията, но посетителите виждат празна страница, докато няма активна тема. Веднага отворете Изглед > Теми: WordPress установява, че активната тема е повредена, и се връща към инсталирана тема по подразбиране.

С WP-CLI

wp plugin list --status=active
wp plugin deactivate ime-na-razshirenie
wp theme list
wp theme activate twentytwentyfive

Първата команда показва списъка на активните разширения, полезен преди всяко групово деактивиране. Ако самият WP-CLI спре на грешката, добавете към командата --skip-plugins --skip-themes: тогава той се стартира, без да зарежда разширенията и темата. Разширенията в папката wp-content/mu-plugins се зареждат въпреки това; ако грешката идва от някое от тях, преименувайте файла му.

Когато съобщението не посочва компонент, wp plugin deactivate --all деактивира всички разширения. Ако сайтът се върне, активирайте ги отново едно по едно, като презареждате сайта след всяко: последното активирано преди връщането на грешката е виновното.

След като сайтът се върне

1. Върнете define( 'WP_DEBUG', false ); и премахнете WP_DEBUG_LOG от wp-config.php.
2. Изтрийте wp-content/debug.log: поставен в папка, достъпна от уеб, той може да бъде прочетен от всеки и съдържа пътища на сървъра.
3. Обновете или заменете проблемния компонент, след като прочетете списъка му с промени.
4. Изчистете кеша на разширението за кеш и този на хостинг доставчика, ако има такъв.
5. За следващия път: тествайте обновяванията върху копие на сайта, преди да ги приложите на живия сайт.