Что делать, если блочный редактор WordPress не загружается

В большинстве случаев редактор блоков WordPress не загружается из-за ошибки JavaScript — один сломанный скрипт плагина или темы останавливает всё React-приложение, и редактор так и не дорисовывается до конца. Откройте консоль разработчика в браузере (F12 или Cmd+Option+I на Mac), перезагрузите страницу редактирования и прочитайте красную ошибку. Почти всегда в ней указан файл, который выбросил исключение. Одна эта строка подсказывает, какой плагин отключить, и обычно уже через пять минут вы снова пишете текст. Переустановка WordPress, повышение лимита памяти PHP и переход на классический редактор — три самых частых совета в интернете, и все три, как правило, ошибочны.

Почему редактор ломается именно так

Редактор блоков (Gutenberg) — это одностраничное React-приложение, работающее внутри wp-admin/post.php и post-new.php. WordPress подключает целый набор скриптовых пакетов — wp-blocks, wp-element, wp-editor, wp-edit-post — и приложение стартует через wp.domReady(). JavaScript прекращает выполнение на первом же необработанном исключении. Поэтому если любой из подключённых скриптов выбрасывает ошибку во время инициализации редактора, всё, что идёт после него, умирает вместе с ним. Ваша тщательно свёрстанная область записи превращается в пустую белую панель или в сообщение «При работе редактора возникла непредвиденная ошибка».

По умолчанию WordPress ещё и объединяет админские скрипты в меньшее число запросов. Это значит, что сломанный JS одного плагина может утянуть за собой посторонние скрипты, загруженные в том же бандле, — вот почему виновника не всегда видно по одному лишь поведению. А в консоли видно.

Второй сценарий выглядит иначе: редактор загружается, но при сохранении выбрасывает ошибку «Не удалось выполнить обновление. Ответ не является корректным JSON». Это уже не проблема JavaScript. Редактор общается с REST API по адресу /wp-json/wp/v2/ и ожидает в ответ чистый JSON. Если плагин или functions.php вашей темы выводит PHP-уведомление, предупреждение или фатальную ошибку до JSON — либо плагин безопасности блокирует REST-маршрут, либо плагин редиректов переписывает URL — ответ оказывается загрязнён, и редактор не может его разобрать.

Как это чинить, от самого быстрого способа

1. Прочитайте консоль. Воспроизведите сбой с открытыми DevTools. Ошибка вида Uncaught TypeError ... some-plugin/build/index.js напрямую указывает на проблемный плагин. Этот единственный шаг решает большинство случаев и избавляет вас от слепого перебора.

2. Исключите браузер. Сделайте жёсткое обновление (Cmd/Ctrl+Shift+R), затем попробуйте окно в режиме инкогнито с отключёнными расширениями. Блокировщики рекламы и приватные расширения иногда вырезают админские скрипты. Если в инкогнито всё работает — проблема в расширении браузера или устаревшем кэше, а не в вашем сайте.

3. Проверьте REST API напрямую, если вы видели сообщение «не является корректным JSON». Откройте в браузере https://yoursite.com/wp-json/. Вы должны увидеть сплошную стену JSON. Если вместо этого вы получаете HTML, ошибку 500 или редирект на страницу входа — вот она, ваша проблема: какой-то плагин ломает REST-ответ, а не сам редактор.

4. Переберите плагины. Отключите их все, убедитесь, что редактор загружается, затем включайте по одному, пока не сломается снова. Если вы полностью заблокированы в wp-admin, сделайте это по SFTP, переименовав папку:

mv wp-content/plugins wp-content/plugins_off

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

5. Проверьте тему. Переключитесь на Twenty Twenty-Four. Тема, которая подключает сломанный JS редактора или выбрасывает PHP-ошибку в functions.php, даёт те же симптомы.

6. Включите лог и прочитайте настоящую ошибку. Особенно для сбоев REST/JSON включите отладку в wp-config.php:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Фатальная ошибка запишется в wp-content/debug.log с точным именем файла и номером строки. Если этот стек-трейс густой — классы с пространствами имён, цепочки require, фатальная ошибка, погребённая под десятком строк трейса — вставьте его в наш декодер логов ошибок WordPress, чтобы понятным языком увидеть, какой плагин и какая строка на самом деле его вызвали. Это разница между «что-то сломалось» и «сломана строка 214 вот этого конкретного плагина».

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

define( 'SCRIPT_DEBUG', true );
define( 'CONCATENATE_SCRIPTS', false );

Чего делать не стоит

Не устанавливайте плагин Classic Editor, считая, что проблема решена. Он ничего не чинит — он просто прячет блочный редактор, чтобы вы перестали видеть ошибку. Сломанный JavaScript или испорченный REST-ответ никуда не делись, и они снова дадут о себе знать в редакторе сайта, в виджетах или при следующем обновлении. Сначала поставьте диагноз; переходить на классический редактор стоит только если вы сознательно решили отказаться от блоков.

Не повышайте лимит памяти PHP на автомате. Это любимый в интернете рецепт из разряда «скопируй и вставь», но пустой редактор редко связан с нехваткой памяти. Настоящее исчерпание памяти выбрасывает конкретную фатальную ошибку — «Allowed memory size of N bytes exhausted» — которую вы увидите в debug.log. Если этой строки там нет, добавление памяти ничего не изменит.

Не переустанавливайте ядро WordPress. Файлы ядра побайтово идентичны на каждой установке. Будь проблема в ядре, у каждого сайта на WordPress на планете прямо сейчас был бы сломан редактор. Причина почти всегда в ваших плагинах или теме, а переустановка ядра рискует перезаписать что-то нужное, ничего при этом не починив.

Не сбрасывайте и не отключайте плагин кэширования вслепую первым делом. Агрессивная минификация и объединение JS действительно могут сломать редактор, так что проверить это стоит — но сначала загляните в консоль, прежде чем наугад сбрасывать кэши. Гадание — вот как пятиминутная починка растягивается на полдня.

Всё ещё не получается?

Если консоль чистая, REST API возвращает корректный JSON, а полный перебор плагинов и темы всё равно оставляет редактор мёртвым — ответ почти наверняка лежит в debug.log. Включите WP_DEBUG_LOG, воспроизведите сбой один раз и прогоните полученную фатальную ошибку через декодер логов ошибок. Стек-трейс назовёт файл — начните с него.