Перейти до вмісту
Помилки та збої

Виправляємо, коли блоковий редактор WordPress не завантажується

Найчастіше блоковий редактор WordPress, який не завантажується, — це помилка JavaScript: один зламаний скрипт від плагіна чи шаблону зупиняє весь застосунок React, і

Опубліковано

Пропустіть читання — скористайтеся інструментом Декодер фатальних помилок PHP у WordPress Вставте помилку. Ми назвемо плагін.

Найчастіше блоковий редактор WordPress, який не завантажується, — це помилка JavaScript: один зламаний скрипт від плагіна чи шаблону зупиняє весь застосунок React, і редактор так і не дорендерюється. Відкрийте консоль розробника у браузері (F12 або Cmd+Option+I на Mac), перезавантажте екран редагування та прочитайте червону помилку. Вона майже завжди називає файл, який спричинив збій. Цей один рядок підказує, який плагін вимкнути, і зазвичай ви можете повернутися до написання менш ніж за п’ять хвилин. Перевстановлення WordPress, підвищення ліміту пам’яті PHP та перехід на класичний редактор (Classic Editor) — три найпоширеніші поради в інтернеті, і всі три зазвичай хибні.

Чому редактор ламається саме так

Блоковий редактор (Gutenberg) — це односторінковий застосунок React, який працює всередині wp-admin/post.php і post-new.php. WordPress підключає набір пакетів скриптів — wp-blocks, wp-element, wp-editor, wp-edit-post — і застосунок ініціалізується через wp.domReady(). JavaScript припиняє виконання на першому ж неперехопленому винятку. Тож якщо будь-який підключений скрипт викидає помилку під час ініціалізації редактора, усе, що йде після нього, гине разом із ним. Ваша ретельно налаштована область запису перетворюється на порожню білу панель або повідомлення “The editor has encountered an unexpected error.”

За замовчуванням WordPress також об’єднує адмінські скрипти в меншу кількість запитів. Це означає, що зламаний JS одного плагіна може потягнути за собою й зовсім не пов’язані з ним скрипти, завантажені в тому самому бандлі, — і саме тому винуватця не завжди видно лише з поведінки. Але його видно в консолі.

Другий тип збою виглядає інакше: редактор завантажується, але при збереженні викидає “Updating failed. The response is not a valid JSON response.” Це вже не проблема JavaScript. Редактор спілкується з REST API за адресою /wp-json/wp/v2/ й очікує у відповідь чистий JSON. Якщо плагін або functions.php вашого шаблону виводить повідомлення PHP (notice), попередження чи фатальну помилку перед JSON — або плагін безпеки блокує REST-маршрут, або плагін перенаправлень переписує URL — відповідь забруднюється, і редактор не може її розпарсити.

Як це виправити, найшвидше — першим

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

2. Виключіть браузер. Зробіть жорстке перезавантаження (Cmd/Ctrl+Shift+R), а потім спробуйте вікно в режимі інкогніто з вимкненими розширеннями. Блокувальники реклами та приватні розширення інколи вирізають адмінські скрипти. Якщо в інкогніто все працює, проблема в розширенні браузера або застарілому кеші, а не у вашому сайті.

3. Перевірте REST API напряму, якщо ви бачили повідомлення “not a valid 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-відповідь нікуди не діваються й знову дадуться взнаки в редакторі сайту, у віджетах або наступного разу під час оновлення. Спочатку діагностуйте; повертайтеся до Classic лише якщо ви свідомо вирішили відмовитися від блоків.

Не підвищуйте ліміт пам’яті PHP рефлекторно. Це улюблений інтернетом фікс копіпастом, але порожній редактор рідко буває через вичерпання пам’яті. Справжнє вичерпання викидає конкретну фатальну помилку — “Allowed memory size of N bytes exhausted” — яку ви побачите в debug.log. Якщо цього рядка немає, більше пам’яті нічого не змінить.

Не перевстановлюйте ядро WordPress. Файли ядра побайтно ідентичні на кожній інсталяції. Якби проблема була в ядрі, кожен сайт на WordPress у світі мав би зараз зламаний редактор. Причина майже завжди у ваших плагінах чи шаблоні, а перевстановлення ядра ризикує перезаписати щось, нічого при цьому не виправивши.

Не очищайте й не вимикайте плагін кешу наосліп першим кроком. Агресивна мініфікація та об’єднання JS можуть зламати редактор, тож це варто перевірити — але зазирніть у консоль, перш ніж навмання скидати кеші. Здогадки — це те, як п’ятихвилинне виправлення перетворюється на цілий вечір.

Досі не вдається?

Якщо консоль чиста, REST API повертає валідний JSON, а повний бісекшен плагінів і шаблону все одно залишає редактор мертвим, відповідь майже завжди чекає в debug.log. Увімкніть WP_DEBUG_LOG, відтворіть збій один раз і пропустіть отриману фатальну помилку через декодер журналу помилок. Стек-трейс назве файл — починайте звідти.