Белый экран WordPress: 5 простых решений

Если ваш сайт WordPress Внезапно появляется совершенно пустая страница. без Суть в том, что вы не «прокляты»: вы просто столкнулись с критической ошибкой, которую WordPress не может корректно отобразить.

проблема

«Белый экран смерти» (WSOD) проявляется как полное отсутствие контента. Иногда появляется эквивалентное сообщение на стороне сервера, например, ошибка 500, или минимальное сообщение, например:

HTTP ERROR 500

Или, если хостинг выдает ошибки PHP (что редко встречается в рабочей среде), что-то вроде:

Fatal error: Uncaught Error: Call to undefined function ... in /home/.../wp-content/themes/.../functions.php:123

Где и когда оно появляется?

Front-end Пустая главная страница или только определенные страницы (часто это страница с шорткодом, виджетом или специальным шаблоном).
Администратор (/wp-admin) Белый экран при входе в систему, недоступная панель управления или белый экран на определенной странице (Расширения, Внешний вид, Редактор…).
Cron / запланированные задачи Сайт «работает», но некоторые действия (отправка электронных писем, импорт) прекращаются, и в журналах обнаруживаются ошибки.
REST API / AJAX Elementor/Divi/Avada больше не могут загрузить редактор, XHR-запросы завершаются с ошибкой, или предварительный просмотр не загружается.

Типичные ситуации, которые я наблюдаю чаще всего:

Сразу после Mise à Jour (WordPress 6.9.4, a плагин(тема, конструктор).
После добавления отрывок в functions.php или через плагин для создания фрагментов кода.
После активации "тяжелый" плагин (кэш, безопасность, конструктор, электронная коммерция).
После внесения изменений на стороне сервера (версия PHP, модуль OPcache, ограничения памяти).

Для кого это предназначено: Если вы новичок, но имеете доступ к своему FTP-серверу/файловому менеджеру (или хотя бы к панели администратора), вы сможете правильно диагностировать проблему и восстановить работу сайта. В итоге вы будете знать, в чем дело. найти точную ошибку, изолировать виновного (плагин/тема/фрагмент кода), и Избегайте появления ложных белых экранов, вызванных кэшем..

Краткое резюме

Не гадайте Включите отладку и прочтите сообщение об ошибке (Решение 1).
Изолировать : деактивируйте все плагины и вернитесь к теме по умолчанию (Решение 2).
Проверьте память. Многие ошибки WSOD возникают из-за Исчерпан допустимый объем памяти. (Решение 3).
Обрывки : отсутствующая точка с запятой в functions.php достаточно, чтобы все отбелить (Решение 4).
Кэш Вы можете «исправить» сайт, даже не видя его, если OPcache/CDN использует старую версию (Решение 5).

Симптомы

«Светодиодный экран смерти» (WSOD) — это не всегда «просто пустая страница». Вот конкретные признаки, на которые следует обратить внимание (и на что они указывают).

Заполните пустую страницу (спереди) но / Wp-администратора Причина проблемы часто кроется в теме оформления, шаблоне, шорткоде или поврежденном кэше страницы.
/ Wp-администратора Белый цвет тоже: чаще всего это фатальная ошибка PHP (плагина, темы, фрагмента кода) или ограничение памяти.
ERREUR 500 В браузере это часто приводит к фатальной ошибке PHP, проблемам с конфигурацией сервера или использованию модуля (OPcache), который предоставляет устаревший код.
Редактор Elementor/Divi/Avada больше не загружается. Ошибки REST API/AJAX, проблемы с памятью, конфликты плагинов (безопасность/кэширование) или скрытые ошибки JavaScript.
Сайт работает локально. но не в производственной среде: различия в версии PHP, расширениях PHP, ограничениях памяти, кэше сервера, правах доступа к файлам.
Только некоторые страницы : неработающий шорткод, слишком большой запрос, бесконечный цикл или изображение/ресурс, который перегружает память.

Быстрая диагностика на стороне браузера: откройте консоль (F12) и посмотрите:

Консоли : Ошибки JavaScript (особенно полезно для разработчиков).
Cеть XHR-запросы к /wp-json/ (REST API) или admin-ajax.php в 500/403 г.

Почему это происходит

Простое объяснение (для начинающих)

WordPress выполняет PHP-код (темы и плагины). Если PHP обнаруживает критическую ошибку, выполнение немедленно останавливается. В зависимости от конфигурации вашего сервера, ошибка может быть скрыта (из соображений безопасности), и вы можете видеть только белый экран.

Поэтому WSOD редко бывает «мистическим». Он почти всегда:

un ошибка в коде (плагин/тема/фрагмент кода),
un нехватка ресурсов (память/время),
или кэш Это приводит к отображению неработающей версии, даже если вы её исправили.

Техническое объяснение (средний/профессиональный уровень)

На самом деле, ошибка часто возникает во время загрузки хуков WordPress. крючок является точкой продолжения: а действие выполняет код в заданный момент времени. фильтры Изменяет значение (например, содержимое) перед его использованием.

Причины (от наиболее частых до наиболее редких), а также то, что я наблюдаю при устранении неполадок в WordPress 6.9.4:

Плагин несовместим с PHP 8.1 и выше. (или ошибка после обновления).
Тема / Детская тема : код в functions.phpшаблон или переопределение WooCommerce.
Фрагмент текста скопирован из старого учебного пособия. (устаревшая функция, некорректный обработчик или код, выполненный слишком рано).
Недостаточно памяти для PHP (Конструкторы + WooCommerce + плагины безопасности = классическая комбинация).
Серверный кэш (OPcache) / CDN которая использует устаревшую версию.
Разрешения... (Реже встречается при истинном WSOD, но может вызывать ошибки 500).

Чтобы помочь вам разобраться, вот диагностическая таблица: «симптом → проверка → решение».

симптом	Причина вероятна	проверка	Решение
Повсюду белый экран	фатальная ошибка PHP	Включите WP_DEBUG + прочитайте `debug.log`	Решение 1 + 2
ERREUR 500	Критическая ошибка PHP / ограничение памяти / кэш сервера	Журналы сервера + `debug.log`	Решение 1 + 3 + 5
Администратор ОК, белый передний план.	Тема / шорткод / кэш страницы	Временно сменить тему + очистить кэш	Решение 2 + 5
Elementor/Divi больше не открывает редактор	Ошибка REST/AJAX, не хватает памяти.	Консоль + Сеть (XHR 500/403)	Решение 3 + «Если это всё ещё не сработает»
WSOD после добавления фрагмента кода	Синтаксическая ошибка / слишком ранний хук	Последний измененный файл, журналы	Решение 4

Предварительные условия перед началом обучения

Сохраните изменения перед внесением каких-либо изменений. Если вам необходимо работать с какими-либо файлами, как минимум сделайте копию следующих файлов:

wp-config.php
папка wp-content (или по крайней мере themes et plugins)

Рекомендуемые технические требования (WordPress 6.9.4 по состоянию на апрель 2026 г.):

PHP + 8.1 (минимально рекомендуемый уровень). Если ваш уровень ниже этого, вы значительно увеличиваете риск появления ошибок и уязвимостей.
Доступ к FTP / SFTP или в файловый менеджер хостинг-провайдера.
В идеале а инсценировка (тестовый сайт). Многие хостинг-провайдеры предлагают это в один клик.

Полезные (бесплатные) инструменты:

Монитор запросов (для просмотра ошибок PHP, запросов, хуков, REST): wordpress.org/plugins/query-monitor
Проверка работоспособности и устранение неполадок (Режим устранения неполадок без влияния на посетителей): wordpress.org/plugins/health-check
Документация по отладке WordPress: developer.wordpress.org/advanced-administration/debug/debug-wordpress

Золотое правило : никогда не изменяйте ядро. (файлы WordPress в wp-includes / wp-admin). Исправление вносится в плагин, дочернюю тему или в конфигурацию.

Решение 1: Включите отладку должным образом (и найдите точную ошибку).

Пустой экран без видимых ошибок заставляет вас гадать. Цель здесь — получить полезное сообщение в файл журнала.

Где следует вмешаться: в файле wp-config.phpв корневой директории WordPress (на том же уровне, что и...) wp-content).

Сохраните изменения перед внесением. Опечатка в wp-config.php может привести к недоступности сайта.

ДО (типичная конфигурация, которая всё скрывает)

На многих сайтах отсутствует информация, или же отладка неполная:

<?php
// ... contenu existant ...

/* C'est tout : aucune trace d'erreur exploitable. */

ПОСЛЕ (устранение неполадок, ориентированное на отладку, без отображения информации для посетителей)

Добавьте (или скорректируйте) эти константы. Разместите их. перед тем ла Ligne /* That's all, stop editing! */ если он есть в вашем файле.

<?php
// ... contenu existant ...

/**
 * Debug WordPress (WordPress 6.9.4+ / PHP 8.1+)
 * Objectif : écrire les erreurs dans wp-content/debug.log sans les afficher aux visiteurs.
 */
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

// Évite d'afficher des erreurs PHP directement dans le HTML.
@ini_set( 'display_errors', '0' );

Перезагрузите пустую страницу (главную или административную).
открытый wp-content/debug.log и найдите последнюю ошибку.

Примеры ошибок, с которыми вы можете столкнуться:

PHP Fatal error:  Uncaught Error: Call to undefined function my_plugin_helper() in /wp-content/plugins/mon-plugin/mon-plugin.php:88

PHP Fatal error:  Allowed memory size of 268435456 bytes exhausted (tried to allocate 20480 bytes) in /wp-includes/class-wpdb.php on line ...

Почему это решает проблему: иногда этот шаг не устраняет «WSOD», но проблема восстанавливается. информация Это позволяет быстро вносить исправления (в конкретный плагин, конкретный файл, конкретную строку). Без этого вы тратите время впустую.

Когда закончите, сдайте работу. WP_DEBUG à false на рабочем сайте. Поддержание активности журнала может привести к раскрытию путей к серверу и конфиденциальной информации, если файл плохо защищен.

Официальный источник: Отладка WordPress

Решение 2: Выявить конфликт между плагином и темой (начальный метод + метод "без доступа к админке")

По моему опыту, WSOD очень часто возникает из-за обновленного плагина (или сборщика), который вызывает фатальную ошибку. Цель: вернуться к минимальной конфигурации, а затем активировать их по одному.

Способ А (для начинающих): через панель администратора, если у вас есть доступ.

идти Расширения> Установленные расширения.
Выделите все, затем дезактивировать.
Проверьте сайт.
Повторно активировать по одному расширению за раз до тех пор, пока не будет воспроизведена ошибка WSOD.

Далее, временно переключитесь на стандартную тему:

Внешний вид > Темы > активировать официальную тему (часто это тема Twenty*).
Попробуйте еще раз.

Если вы используете Divi 5, Elementor или Avada: эти темы/конструкторы добавляют много кода. Часто возникает конфликт с плагином кэширования/безопасности. Тест "тема по умолчанию + плагины отключены" — самый быстрый способ разорвать этот порочный круг.

Метод B (без доступа администратора): через FTP/SFTP

Si /wp-admin Если значение равно "белый", используйте FTP/SFTP.

Шаг 1: Отключите все плагины одновременно.

Где следует вмешаться: переименуйте папку wp-content/plugins en plugins.offWordPress посчитает эти плагины отсутствующими и деактивирует их.

# Exemple (le nom exact dépend de votre outil FTP)
wp-content/plugins  →  wp-content/plugins.off

Проверьте сайт. Если проблема повторится, значит, вы подтвердили, что виноват(ы) плагин(ы). Затем переустановите его:

wp-content/plugins.off  →  wp-content/plugins

Затем, внутри pluginsПереименуйте папки по одной (например, elementor → elementor.off) чтобы найти виновника.

Шаг 2: Принудительно переключитесь на резервную тему, если основная тема перестанет работать.

Если сайт по-прежнему отображается белым цветом при отключенных плагинах, значит, проблема в теме оформления (или дочерней теме).

Опция декриминализовано : Переименуйте папку активной темы (или дочерней темы). WordPress переключится на другую доступную тему.

wp-content/themes/mon-theme-enfant  →  wp-content/themes/mon-theme-enfant.off

Почему это помогает: вы останавливаете загрузку кода, вызывающего сбой. Критическая ошибка в плагине/теме препятствует дальнейшей работе WordPress.

Если вам нужно официальное руководство по устранению неполадок: Часто задаваемые вопросы по устранению неполадок (WordPress.org)

Решение 3: Исправление ошибки, приводящей к сбою из-за недостатка памяти (PHP/WordPress)

Недостаток памяти — распространённая проблема на сайтах, использующих Elementor/Divi/Avada + WooCommerce + плагины безопасности/кэширования. Симптомом иногда является «синий экран смерти», иногда ошибка 500, а иногда редактор вообще не загружается.

Типичное сообщение в debug.log :

PHP Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate ...)

Шаг 1: Увеличьте объем памяти на стороне WordPress (быстро).

Где следует вмешаться: в wp-config.phpперед фразой «прекратите редактирование».

ДО (без явного ограничения)

<?php
// ...

ПОСЛЕ (запрашивает у WordPress использование дополнительной памяти)

<?php
// ...

/**
 * Augmente la mémoire pour WordPress.
 * Attention : si PHP a une limite plus basse, cela ne suffira pas.
 */
define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' ); // Utile pour l'admin et certaines tâches lourdes.

Почему это работает: WP_MEMORY_LIMIT Это указывает WordPress на целевой объем памяти. Но если ваш сервер устанавливает нижний предел, WordPress не сможет его превысить.

Шаг 2: Увеличьте объем выделяемой памяти на стороне PHP (это часто необходимо).

В зависимости от вашего хостинг-провайдера это делается следующим образом:

панель по вопросам размещения (рекомендуется),
Файл php.ini ou .user.ini,
или конфигурацию PHP-FPM (если вы администрируете сервер).

Пример (файл) .user.ini (на многих хостингах с общим доступом):

memory_limit = 512M
max_execution_time = 120

Официальная справочная информация по PHP (memory_limit): php.net memory_limit

Что я тестирую после увеличения объема памяти?

Загрузка пустой страницы.
Открытие редактора (Elementor/Divi/Avada).
Если используется WooCommerce: добавьте товар в корзину, на страницу оформления заказа и на страницу товара.

Если сайт снова стал доступен, но по-прежнему работает медленно, возможно, у вас происходит "взрыв" запросов (Query Monitor очень помогает).

Решение 4: Восстановление неработающего фрагмента кода (functions.php / плагин фрагментов кода) без нарушения работы всего остального.

Самый неприятный сценарий: вы добавляете 10 строк кода «для улучшения WordPress», сохраняете... и всё исчезает. Я часто видел это на сайтах, где код вставлен не в тот файл или отсутствует скобка.

Условия:

отрывок : небольшой фрагмент кода, добавляемый в тему (часто) functions.php) или через плагин.
Ошибка синтаксиса PHP не может прочитать файл (отсутствует точка с запятой, лишняя фигурная скобка...). Это критическая ошибка.

Вариант А: Код был добавлен в файл functions.php (дочерняя тема).

Где следует вмешаться: wp-content/themes/VOTRE-THEME-ENFANT/functions.php

Вполне распространённая ошибка: забыть поставить точку с запятой или закрыть фигурную скобку.

ДО (ошибка: отсутствует точка с запятой)

<?php
add_action( 'wp_enqueue_scripts', 'mon_site_styles' );

function mon_site_styles() {
	// Charge une feuille de style
	wp_enqueue_style( 'mon-style', get_stylesheet_directory_uri() . '/style.css' )
}

ПОСЛЕ (исправлено)

<?php
add_action( 'wp_enqueue_scripts', 'mon_site_styles' );

function mon_site_styles() {
	// Charge une feuille de style
	wp_enqueue_style( 'mon-style', get_stylesheet_directory_uri() . '/style.css' );
}

Почему это решает проблему: PHP требует точку с запятой в конце инструкции. Без неё возникает ошибка синтаксического анализа, и WordPress больше не может загрузиться.

Вариант B: код использует хук слишком рано (функция "ещё не загружена")

Ещё один случай, с которым я столкнулся: в старом учебнике нужно вызвать функцию, которой ещё не существует на момент выполнения кода.

ДО (ошибка: немедленная казнь слишком рано)

<?php
// Mauvaise idée : ce code s'exécute dès le chargement du fichier.
ma_fonction_qui_depend_de_wordpress();

function ma_fonction_qui_depend_de_wordpress() {
	// Exemple : vous faites des appels à des APIs WordPress non disponibles à cet instant
	update_option( 'test', 'ok' );
}

ПОСЛЕ (исправлено: выполнение посредством действия)

<?php
/**
 * On utilise une action pour attendre que WordPress soit chargé.
 * Une "action" est un hook qui déclenche votre code à un moment précis.
 */
add_action( 'init', 'ma_fonction_qui_depend_de_wordpress' );

function ma_fonction_qui_depend_de_wordpress() {
	update_option( 'test', 'ok' );
}

Почему это исправляет ошибку: init Она запускается после загрузки WordPress. Это предотвращает преждевременные вызовы.

Вариант C: фрагмент кода через плагин (WPCode, Code Snippets и т. д.)

Если вы используете плагин для создания сниппетов, его преимущество заключается в том, что он иногда может автоматически отключать критический сниппет. Но если панель администратора недоступна, отключите плагин для сниппетов через FTP (Решение 2), а затем исправьте сниппет.

Ссылка (крючки): developer.wordpress.org/plugins/hooks

Решение 5: Устранение ложных ошибок WSOD, вызванных кэшем (кэш страниц, CDN, OPcache).

Эта ошибка часто ставит в тупик новичков: вы исправляете баг, но белый экран всё равно остаётся. На самом деле, кэш предоставляет неработоспособную версию.

Я часто это вижу на:

сайты, находящиеся за Cloudflare (или другой CDN),
Хостинг-провайдеры с агрессивным кэшированием на серверах
Сайты с включенным OPcache, которые после развертывания были некорректно отключены.

Шаг 1: Очистите «видимый» кэш.

Очистите кэш плагинов (LiteSpeed Cache, WP Rocket, W3TC…).
Очистите кэш CDN (Cloudflare: «Очистить всё» или выполните целевую очистку).
Проверьте в режиме приватного просмотра, добавив параметр: ?nocache=1

Шаг 2: OPcache (на стороне сервера)

Если у вас есть доступ к серверу, наиболее эффективным решением будет перезапуск PHP-FPM (в зависимости от вашей конфигурации системы). Пример (Linux):

sudo systemctl reload php8.2-fpm

Если вы используете общий хостинг, эта команда вам недоступна. В этом случае:

Найдите в панели опцию «Очистить OPcache».
или попросите службу поддержки очистить кэш OPcache (это часто является стандартной просьбой).

Почему это решает проблему: OPcache может хранить в памяти старую версию PHP-файла. Вы исправляете файл… но PHP всё равно выполняет старую версию.

Официальная справочная информация по OPcache: php.net OPcache

Проверки после внесения исправлений

После восстановления работы сайта я всегда провожу одни и те же "простые, но эффективные" тесты:

Фронт : главная страница + 2-3 внутренние страницы + поиск.
Админ : Панель управления, Расширения, Внешний вид, Редактор (если используется).
Строители :
- Elementor: откройте редактор и сохраните изменения.
- Divi 5: откройте визуальный конструктор и проверьте адаптивный предварительный просмотр.
- Avada: откройте Fusion Builder и выберите редактирование контейнера.
Виды : отправить форму (контактная/информационная рассылка).
REST API : быстрая проверка путем посещения /wp-json/ (Вы должны увидеть JSON, а не пустую страницу).

Прочитать еще раз wp-content/debug.log Если проблема продолжает расти, ошибки всё равно остаются (даже если сайт «работает»).
Отключите отладку, если она включена в рабочей среде (Решение 1).

Если это всё ещё не поможет

Когда пяти «начальных» решений недостаточно, я перехожу к более систематичному методу. Он по-прежнему доступен, но требует определенной методичности.

1) Проверьте журналы сервера (часто они содержат больше информации, чем debug.log).

У многих хостинг-провайдеров в панели управления вы найдете «журнал ошибок» Apache/Nginx. Ищите:

PHP Fatal error
Premature end of script headers
Allowed memory size

2) Используйте проверку состояния (режим устранения неполадок).

Если у вас есть права администратора, плагин Health Check позволяет отключать плагины/темы. специально для тебябез ущерба для посетителей. Это очень удобно для работающего веб-сайта.

Плагин: Проверка работоспособности и устранение неполадок

3) Проверьте фактическую версию PHP.

Веб-сайт может «думать», что работает на PHP 8.1, но поддомен или задание cron могут работать на PHP 7.4 (я такое видел). Проверьте:

Инструменты > Здоровье сайта
или панель управления хостинг-провайдера.

4) Временно отключите mu-плагины

. мю-плагины (Обязательные к использованию плагины) загружаются автоматически из wp-content/mu-pluginsОни не отображаются в списке стандартных расширений. Некоторые хостинг-провайдеры используют кэширование/меры безопасности.

тест: переименовать mu-plugins en mu-plugins.off через FTP, затем протестируйте.

5) Постоянные ссылки / правила перезаписи («admin OK, pages 404/500»)

Это не самый чистый WSOD, но он часто возникает после миграции или установки плагина. Перейдите по ссылке:

Настройки> Постоянные ссылки затем нажмите Регистрация (без каких-либо изменений).

Официальный документ: WP-CLI (для профессионалов) (Это полезно, если у вас есть доступ по SSH, но здесь это необязательно).

6) Проверьте права доступа к файлам (редко, но реально).

Чрезмерно строгие права доступа могут вызывать ошибки сервера. В средах общего доступа Linux мы часто наблюдаем следующее:

Файлы: 755
Файлов: 644

Если ваш хостинг-провайдер дает другие рекомендации, следуйте им.

Распространенные ошибки и ловушки

симптом	Причина вероятна	Рекомендуемое решение
Вы включили WP_DEBUG, но `debug.log` не появляются	`wp-content` Недоступно для записи / Неверная конфигурация / Ошибка при загрузке	Проверьте права доступа, затем просмотрите журналы сервера.
WSOD сразу после вставки кода	Отсутствует точка с запятой/фигурная скобка, код вставлен не в то место.	Решение 4 (исправить фрагмент кода), в идеале в виде пользовательского плагина.
В режиме приватного просмотра это работает, но не в «обычном» режиме.	Кэш браузера / плагин / CDN	Решение 5 (очистка) + временное отключение минификации
Elementor/Divi/Avada больше не открывает редактор.	Проблемы с памятью, блокировка REST/AJAX из-за безопасности, конфликт плагинов.	Решение 3 + проверьте консоль + отключите плагин безопасности
Вы следовали старому руководству.	Несовместимый код WordPress 6.9.4 / PHP 8.1	Замените существующий подход на другой, используя имеющиеся хуки, и протестируйте на тестовой площадке.
Вы изменили родительскую тему.	Потеря внесенных изменений при обновлении, риск поломки.	Вернитесь к дочерней теме или пользовательскому плагину (см. раздел «Избегать»).
После «исправления» экран смерти снова появляется.	OPcache/CDN по-прежнему использует старую версию.	Решение 5 (по возможности очистить и перезагрузить PHP-FPM)

Наиболее часто встречающиеся «человеческие» ошибки:

Вставьте фрагмент текста в поврежденный файл (например, в шаблоне вместо) functions.php).
Забыть круглая скобка или точка с запятой.
Смущать действие et фильтры (например, использование) add_action вместо add_filter).
Протестируйте непосредственно на производство без резервной копии.
Забудьте Очистить кэш после исправления.

Вариант / альтернатива

Метод без программирования (рекомендуется для начинающих)

Если у вас есть доступ к панели администратора, установите:

Проверка работоспособности Чтобы отключить плагины/темы только на время вашей сессии: wordpress.org/plugins/health-check
Монитор запросов Чтобы прочитать сообщения об ошибках и определить неисправный хук или плагин: wordpress.org/plugins/query-monitor

Это самый безопасный способ на онлайн-сайте: вы проводите исследование, не нарушая пользовательский опыт.

Более продвинутый метод (для разработчиков): резервное копирование mu-плагина.

Если вы часто устраняете неполадки (или управляете несколькими сайтами), вы можете создать мю-плагин (Загружено автоматически) для обеспечения минимального уровня логирования и предотвращения отображения ошибок.

Куда вставить код: создать файл wp-content/mu-plugins/00-rescue.php (Создайте папку, если она не существует).

<?php
/**
 * Plugin Name: Rescue minimal
 * Description: Aide au dépannage : loggue des infos minimales si le site plante tôt.
 * Author: Votre Nom
 *
 * Attention : ceci ne remplace pas WP_DEBUG. C'est un filet de sécurité.
 */

if ( ! defined( 'ABSPATH' ) ) {
	exit;
}

// Exemple : log simple pour confirmer que WordPress charge bien les mu-plugins.
error_log( '[Rescue] mu-plugin chargé' );

Риски: Слишком большой объем записей в журналы может привести к их переполнению. Старайтесь, чтобы этот файл содержал минимальное количество данных, и удаляйте его после устранения неполадок.

Официальная справочная информация по mu-плагинам: developer.wordpress.org/advanced-administration/plugins/mu-plugins

Избегайте этой проблемы в будущем.

Синие экраны смерти (WSOD) появляются снова, если вы пытаетесь быстро устранить проблему, не меняя своих привычек. Вот что на самом деле снижает риск.

1) Вносите изменения в собственный плагин, а не в файл functions.php.

Для многократно используемых фрагментов кода я предпочитаю небольшой плагин, разработанный специально для этой цели. Его преимущество в том, что его можно отключить одним щелчком мыши, не затрагивая тему оформления.

Куда вставить код: Создайте wp-content/plugins/mon-plugin-custom/mon-plugin-custom.phpЗатем активируйте его.

<?php
/**
 * Plugin Name: Mon plugin custom
 * Description: Snippets stables pour ce site (WordPress 6.9.4+ / PHP 8.1+).
 * Version: 1.0.0
 */

if ( ! defined( 'ABSPATH' ) ) {
	exit;
}

/**
 * Exemple : on accroche un code sur une action.
 */
add_action( 'init', function () {
	// Code sûr : exécuté après le chargement de WordPress.
} );

2) Реализовать план поэтапного выполнения работ.

Проверяйте обновления (WordPress, плагины, темы, конструкторы) на тестовой среде. Это разница между «5 минутами стресса» и «2 часами паники».

3) Проверьте совместимость с PHP 8.1 и выше.

Плагин, за которым не ведется поддержка, может перестать работать после обновления версии PHP. Проверьте совместимость на странице плагина (wordpress.org) и следите за списком изменений.

4) Обеспечьте наличие аварийного доступа.

Функциональный доступ по протоколам SFTP/FTP
Доступ к панели управления хостингом (логи, версия PHP, кэш).
Ежедневное резервное копирование (в идеале, на внешний носитель).

5) Кэш: задокументируйте свой «путь очистки».

На сайтах, использующих CDN, кэш плагинов и серверный кэш, четко указывайте, где следует очищать кэш. В противном случае вы «исправите» что-то, не увидев результата.

Ресурсы

Отладка WordPress (официальная версия): developer.wordpress.org/advanced-administration/debug/debug-wordpress
Хуки (действия и фильтры): developer.wordpress.org/plugins/hooks
MU-плагины: developer.wordpress.org/advanced-administration/plugins/mu-plugins
Монитор запросов (плагин): wordpress.org/plugins/query-monitor
Проверка состояния здоровья (плагин): wordpress.org/plugins/health-check
Устранение неполадок (WordPress.org): wordpress.org/documentation/article/faq-troubleshooting
PHP memory_limit: php.net/manual/en/ini.core.php#ini.memory-limit
OPcache (PHP): php.net/manual/en/book.opcache.php
Исходный код WordPress (зеркало на GitHub): github.com/WordPress/wordpress-develop

Часто задаваемые вопросы

Обязательно ли появление WSOD происходит из-за плагина?

Нет. Тема оформления, дочерняя тема, фрагмент кода, недостаток памяти или кэш сервера — все это может вызывать один и тот же симптом. Самый быстрый способ остается прежним: debug.log + массовое отключение (Решение 1 + 2).

Почему я не получаю никаких сообщений об ошибках?

Поскольку большинство серверов скрывают ошибки PHP в рабочей среде, это нормально (с точки зрения безопасности). Включите логирование через... WP_DEBUG_LOG чтобы получить информацию об ошибке, не отображая её посетителям.

Можно ли это исправить без FTP?

Да, если у вас есть права администратора: проверки работоспособности системы и отключения плагинов часто бывает достаточно. Без прав администратора наиболее прямым путем является доступ к файлам (FTP/SFTP).

Белый цвет на моём сайте присутствует только на одной странице, а не на всех остальных. Почему?

Вероятно, эта страница запускает определенный код: шорткод, виджет, шаблон, ресурсоемкий запрос или контент, которому не хватает памяти. Включите отладку, а затем перезагрузите именно эту страницу, чтобы получить полезный трассировочный файл.

В редакторе Elementor отображается белый экран: это то же самое?

Часто да, но проблема может быть на стороне REST API/AJAX. Проверьте вкладку «Сеть»: если запросы к /wp-json/ ou admin-ajax.php Если возвращается код 500, проверьте наличие ошибки PHP (Решение 1) или нехватки памяти (Решение 3).

После исправления ошибки я всё ещё вижу белый экран. Что мне делать?

Подумайте о кэшировании: приватный просмотр, очистка плагинов, очистка CDN и, если возможно, очистка OPcache (Решение 5). Это очень распространенная ловушка.

Опасно ли включать WP_DEBUG на рабочем сайте?

Если вы отображаете ошибки на экране, то да (вы можете раскрыть конфиденциальную информацию). Если вы только регистрируете (WP_DEBUG_DISPLAY à falseОсновной риск заключается в создании большого файла журнала. Отключите эту функцию после устранения неполадок.

Какой файл мне нужно изменить: functions.php, wp-config.php или .htaccess?

Для диагностики: wp-config.php (Решение 1). Чтобы исправить фрагмент текста: functions.php из дочерней темы или, еще лучше, с помощью пользовательского плагина (Решение 4 / «Избегать»). .htaccess Это больше касается проблем с перезаписью/постоянными ссылками, а не большинства случаев появления "синих экранов смерти".

Сайт восстанавливается после деактивации плагина, но он мне нужен. Что мне делать?

Запишите точную ошибку (файл/строка) и обновите плагин, затем свяжитесь с разработчиком, предоставив журнал ошибок. Тем временем поищите альтернативное решение или отключите только ту функцию, которая вызывает ошибку (часто это кэширование/минификация/безопасность).