Редактор WordPress Gutenberg не завантажується: практичний чекліст відладки

Швидкий план діагностики

Якщо ви хочете найшвидший шлях до вузького місця — припиніть гадати і виконайте це в порядку. Мета не «подивитисяся, що працює». Мета — визначити, який шар вас дурить.

1) Спочатку перевірте консоль браузера (JS-помилки вирішують усе)

• Відкрийте сторінку редактора: /wp-admin/post-new.php або /wp-admin/post.php?post=ID&action=edit.
• DevTools → Console: шукайте червоні помилки та неуспішні мережеві запити.
• DevTools → Network: фільтруйте по wp-json, rest, block-editor, wp-admin/load-scripts.php та admin-ajax.php.

Рішення: Якщо ви бачите «Failed to fetch», «Unexpected token < in JSON» або 401/403/5xx на REST-ендпойнтах — це не «проблема Gutenberg». Це проблема API/автентифікації/WAF/кешу.

2) Перевірте REST API із сервера (не довіряйте браузеру)

Вдарте по /wp-json/ та по аутентифікованому ендпойнту. Якщо сервер не може дістатися до самого себе (або повертає HTML там, де має бути JSON), Gutenberg буде нлюватися.

Рішення: Якщо /wp-json/ не працює — виправляйте це спочатку. Gutenberg залежить від нього, як кисень від легень.

3) Вимкніть плагіни і переключіться на стандартну тему (сурово, але по-діловому)

Робіть це через WP-CLI, щоб не опинитися заблокованими тим самим інтерфейсом, який намагаєтесь полагодити.

Рішення: Якщо відключення плагінів вирішує проблему — вмикайте їх пакетами, щоб знайти винуватця. Якщо допомагає зміна теми — шукайте скрипти редактора, enqueue-проблеми або CSP-заголовки від теми.

4) Перевірте кешування та рівні безпеки (звичні підозрювані)

• Об’єктний кеш (Redis/Memcached)
• Повно-сторінковий кеш/CDN (Cloudflare, Fastly, varnish, nginx microcache)
• Правила WAF, що блокують wp-json або адміністративні скрипти
• CSP-заголовки, що блокують inline-скрипти WordPress

Рішення: Якщо редактор завантажується в режимі інкогніто, але не в звичайному — перевірте кешовані активи, service workers або агресивні розширення браузера. Якщо редактор працює при обході CDN/WAF — злочинець у конфігу на edge.

5) Підтвердіть, що PHP і сховище не ламаються під навантаженням

Gutenberg робить більше запитів, ніж класичний редактор. Якщо PHP-FPM насичений, диск працює на межі, або opcache збоїть, редактор здається «завислим», але справжня проблема — затримки й тайм-аути.

Рішення: Якщо в логах сервера видно 502/504 або тайм-аути — вирішуйте питання ємності і затримок. Діагностувати WordPress на вмираючому диску — все одно, що налаштовувати піаніно під час землетрусу.

Як насправді завантажується Gutenberg (і як він ламається)

Gutenberg — це JavaScript-додаток, вбудований у wp-admin. Коли ви відкриваєте редактор, WordPress повертає адміністративну сторінку, яка підвантажує купу скриптів (React, дата-стори, реєстр блоків, UI редактора), а потім отримує контент і конфігурацію через REST API виклики.

Це означає, що режими відмов зазвичай групуються в чотири корзини:

1. Проблеми з bootstrap: JS/CSS редактора не завантажуються або завантажені пошкоджені. Типові причини: кеш/CDN переписування, мінізації, змішаний контент, CSP, неправильний content-type.
2. Проблеми API: wp-json блокується, повертає HTML замість JSON, автентифікаційні cookie не приймаються, nonce-проблеми, 401/403 від WAF, 5xx від PHP.
3. Проблеми з шаром даних: дивні стани об’єктного кешу, помилки бази даних, роздування автозавантажуваних опцій, повільні запити з тайм-аутами.
4. Оточення: ліміт пам’яті PHP, виснаження opcache, заповнений диск, права, пошкодження файлів або «корисні» плагіни безпеки, що підсилюють точність ендпойнтів.

Коли блоковий редактор «не завантажується», це часто не один катастрофічний збій. Це ланцюг: скрипт падає, JS-додаток не може отримати REST-ендпойнти, і він показує індикатор вічно, бо чекає на обіцянку, яка ніколи не виконається. Ваше завдання — знайти перше зламане посилання.

Цитата, яку варто тримати на стіні, бо вона дратівливо точна: Надія — не стратегія. — генерал Гордон Р. Салліван.

Жарт №1: Gutenberg — це односторінковий додаток у світі багатосторінкових сайтів. Це як поставити гоночний двигун у візок для покупок і дивуватися, чому він скрипить.

Цікаві факти та коротка історія (чому це повторюється)

• Gutenberg спочатку вийшов як плагін, перш ніж був влитий у ядро WordPress, тому деякі сайти досі несуть спадщину плагінної версії Gutenberg.
• WordPress 5.0 (2018) зробив блоковий редактор стандартним, що раптово підкинуло мільйони адмін-середовищ до важчого JavaScript-навантаження.
• Блоковий редактор сильно покладається на REST API; класичний редактор міг обходитися меншою кількістю динамічних викликів.
• wp-admin історично терпів «креативні» налаштування кешування, бо більшість адмін-сторінок рендерились на сервері. Gutenberg швидше карає некоректні кеші.
• Плагіни безпеки почали агресивно фільтрувати JSON-ендпойнти у міру зростання REST-атак; деякі правила «вирішують» безпеку, ламаючи редактор.
• Потоки nonce і cookie змінювалися з часом із підвищенням безпеки адміна, тому старі зворотні проксі та SSO-рішення можуть втратити сумісність.
• Багато оптимізаційних плагінів створювались для фронтенду; вони охоче мініфікують і відкладають скрипти в wp-admin, якщо це не вказано явно.
• Блок-теми і Full Site Editing збільшили площу редактора (редактор сайту, шаблонні частини, глобальні стилі). Більше ендпойнтів — більше способів зламатися.

Перші спостереження: класифікуйте несправність за 60 секунд

Що бачить користувач?

• Нескінченний індикатор / «Loading…» вічно: зазвичай заблокований REST API виклик або рання фатальна JS-помилка під час завантаження.
• Білий екран / порожня область контенту: фатал в JS, блокування CSP, 404 для скрипта або PHP-фатал, який виливає HTML у JSON-ендпойнти.
• «The editor has encountered an unexpected error» з кнопкою «Copy error»: добре; це означає, що Gutenberg зловив виняток. Скопіюйте його і використайте.
• Редактор завантажується, але не може зберегти / оновити: часто це nonce/автентифікація/cookie проблеми, REST 401/403 або блокування POST модулем безпеки/WAF.
• Відбувається лише для певних користувачів: невідповідність ролей/прав, корупція usermeta, розширення браузера або відмінності cookie через CDN.
• Відбувається лише на певному пості: пошкоджена розмітка блоків, величезний post_content, вбудований HTML/шорткоди, що спричиняють парсер, або надмір ревізій/метаданих.

Швидкі перевірки: чи це ваша машина?

• Спробуйте інкогніто/приватне вікно.
• Спробуйте інший браузер.
• Вимкніть розширення браузера (особливо блокувальники реклами та скриптів).

Якщо це допомагає — це не баг WordPress. Це саботаж на клієнтській стороні.

Практичні завдання з командами (і рішення)

Ці завдання передбачають, що у вас є shell-доступ до сервера (або контейнера) з WordPress. Якщо ні — можна виконати частину перевірок через браузер і адмінку, але швидкість буде обмежена нарадами.

Завдання 1: Підтвердіть версії WordPress та плагінів через WP-CLI

cr0x@server:~$ cd /var/www/html
cr0x@server:/var/www/html$ wp core version
6.6.2
cr0x@server:/var/www/html$ wp plugin list --status=active --fields=name,version
akismet 5.3.3
wp-super-cache 1.12.4
wordfence 7.11.8

Що це означає: Ви встановлюєте базову лінію. Поведінка Gutenberg залежить від версій ядра та плагінів.

Рішення: Якщо ядро дуже старе (або плагіни), пріоритезуйте оновлення в тестовому середовищі. Якщо оновлювати неможливо — будете відлагоджувати навколо відомих виправлених багів.

Завдання 2: Перевірте, чи REST API доступний із сервера

cr0x@server:~$ curl -sS -D- -o /dev/null https://example.com/wp-json/
HTTP/2 200
content-type: application/json; charset=UTF-8
cache-control: no-cache, must-revalidate, max-age=0

Що це означає: 200 і JSON content-type — щасливий шлях.

Рішення: Якщо отримаєте 301/302 цикли — виправте site URL або заголовки проксі. Якщо content-type — text/html, хтось перехоплює ендпойнт (вивід від теми/плагіна, сторінка блокування WAF або PHP-фатал з HTML).

Завдання 3: Перевірте, чи REST відповіді насправді HTML (класичний вбивця Gutenberg)

cr0x@server:~$ curl -sS https://example.com/wp-json/ | head
{"name":"Example Site","description":"","url":"https:\/\/example.com","home":"https:\/\/example.com","gmt_offset":"0","timezone_string":"UTC"

Що це означає: JSON має починатися з {. Якщо він починається з <!doctype html> або <html, ви не отримуєте JSON.

Рішення: Якщо з’являється HTML — перевірте плагіни безпеки, що інжектять вивід, помилки сервера або upstream (CDN/WAF), що повертає сторінку блокування.

Завдання 4: Переконайтесь, що скрипти wp-admin віддаються коректно (статус, тип, розмір)

cr0x@server:~$ curl -sS -D- -o /dev/null "https://example.com/wp-admin/load-scripts.php?c=0&load[]=wp-blocks,wp-element,wp-editor"
HTTP/2 200
content-type: application/javascript; charset=UTF-8
cache-control: private, max-age=0, no-store, no-cache, must-revalidate

Що це означає: Скрипти редактора мають повернути JavaScript, не HTML і не кешовану «challenge»-сторінку.

Рішення: Якщо content-type неправильний — зупиніться. Виправляйте кешування/мініфікацію/CDN-переписування до того, як торкатися WordPress.

Завдання 5: Шукайте PHP-фатали в час, коли редактор падає

cr0x@server:~$ sudo tail -n 80 /var/log/php8.2-fpm.log
[27-Dec-2025 10:41:12] WARNING: [pool www] child 2314 said into stderr: "PHP Warning:  Undefined array key "foo" in /var/www/html/wp-content/plugins/some-plugin/plugin.php on line 91"
[27-Dec-2025 10:41:12] WARNING: [pool www] child 2314 said into stderr: "PHP Fatal error:  Uncaught Error: Call to undefined function wp_get_environment_type() in /var/www/html/wp-content/plugins/some-plugin/plugin.php:132"

Що це означає: Фатали можуть зламати REST-відповіді та лоадери скриптів, що призводить до непрямого провалу Gutenberg.

Рішення: Якщо бачите фатали — відключіть плагін/тему, що їх викликає. Не «хакуйте» навколо фаталів.

Завдання 6: Перевірте лог debug WordPress на підказки щодо REST/редактора

cr0x@server:~$ sudo tail -n 80 /var/www/html/wp-content/debug.log
[27-Dec-2025 10:41:11 UTC] WordPress database error Deadlock found when trying to get lock; try restarting transaction for query UPDATE `wp_options` SET `option_value` = '...' WHERE `option_name` = '_transient_timeout_wp_core_block_patterns'
[27-Dec-2025 10:41:12 UTC] PHP Warning:  Cannot modify header information - headers already sent by (output started at /var/www/html/wp-content/plugins/some-plugin/plugin.php:91)

Що це означає: Дедлоки і «headers already sent» часто перекладаються у зламаний JSON.

Рішення: Виправляйте блокування бази даних (або прибирайте код, що робить повторні оновлення опцій). Виправляйте «headers already sent», видаляючи зайвий вивід, BOM або гучні плагіни.

Завдання 7: Швидко вимкніть усі плагіни (потім вмикайте пакетами)

cr0x@server:~$ cd /var/www/html
cr0x@server:/var/www/html$ wp plugin deactivate --all
Success: Deactivated 27 of 27 plugins.

Що це означає: Ви щойно суттєво звузили простір пошуку проблеми.

Рішення: Якщо Gutenberg почав працювати — вмикайте плагіни групами по 3–5, поки знову не зламається. Останній пакет містить вашого винуватця.

Завдання 8: Переключіться на стандартну тему, щоб виключити кастомізації на рівні теми

cr0x@server:~$ cd /var/www/html
cr0x@server:/var/www/html$ wp theme list --status=active
+----------------+----------+-----------+---------+
| name           | status   | update    | version |
+----------------+----------+-----------+---------+
| corp-theme     | active   | none      | 4.9.1   |
+----------------+----------+-----------+---------+
cr0x@server:/var/www/html$ wp theme activate twentytwentyfour
Success: Switched to 'Twenty Twenty-Four' theme.

Що це означає: Багато «корпоративних тем» додають адмін/редактор скрипти, стилі блоків або CSP-заголовки.

Рішення: Якщо стандартна тема вирішує — порівняйте, що робить тема в functions.php: enqueued скрипти, фільтри REST, заголовки безпеки і хуки редактора.

Завдання 9: Перевірте патерни HTTP-статусів у логах веб-сервера (REST-ендпойнти й адмін-скрипти)

cr0x@server:~$ sudo awk '$7 ~ /wp-json|load-scripts.php|admin-ajax.php/ {print $4, $7, $9}' /var/log/nginx/access.log | tail -n 20
[27/Dec/2025:10:41:10 /wp-json/wp/v2/types?context=edit 403
[27/Dec/2025:10:41:10 /wp-admin/load-scripts.php?c=0&load[]=wp-blocks,wp-element,wp-editor 200
[27/Dec/2025:10:41:11 /wp-json/wp/v2/settings 403
[27/Dec/2025:10:41:12 /wp-json/wp/v2/users/me?context=edit 403

Що це означає: Повторювані 403 на /wp-json/wp/v2/* сильно натякають на WAF/плагін безпеки/неправильні права доступу.

Рішення: Якщо 403 співпадають з падіннями редактора — фокусуйтеся на автентифікації, nonce і правилах безпеки, а не на JS-бандлах.

Завдання 10: Перевірте, чи ваш зворотний проксі відправляє правильну схему/хост (поширене зламане nonce/cookie)

cr0x@server:~$ sudo grep -R "fastcgi_param\|proxy_set_header" -n /etc/nginx/sites-enabled | head -n 40
/etc/nginx/sites-enabled/example.conf:42:proxy_set_header Host $host;
/etc/nginx/sites-enabled/example.conf:43:proxy_set_header X-Forwarded-Proto $scheme;
/etc/nginx/sites-enabled/example.conf:44:proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

Що це означає: Якщо WordPress думає, що він на HTTP, а користувачі на HTTPS — отримаєте змішані cookie, неправильні редиректи і невалідацію nonce.

Рішення: Якщо ви за load balancer/ingress — підтвердіть, що X-Forwarded-Proto і WordPress siteurl/home відповідають реальності.

Завдання 11: Перевірте насичення PHP-FPM (затримки виглядають як проблема JS)

cr0x@server:~$ sudo systemctl status php8.2-fpm --no-pager
● php8.2-fpm.service - The PHP 8.2 FastCGI Process Manager
     Loaded: loaded (/lib/systemd/system/php8.2-fpm.service; enabled)
     Active: active (running) since Fri 2025-12-27 08:12:04 UTC; 2h 31min ago
     Status: "Processes active: 42, idle: 0, Requests: 19832, slow: 117"

Що це означає: «idle: 0» і зростаюча кількість повільних запитів вказують на насичення. Gutenberg генерує багато адмін-запитів; він підсилює вузькі місця.

Рішення: Якщо насичення є — аналізуйте slow-логи, обережно підвищуйте кількість FPM-процесів і усувайте кореневі причини (повільна БД, повільний диск, важкі плагіни), перш ніж просто додавати воркерів і плавити RAM.

Завдання 12: Перевірте вільне місце на диску та тиск інодів (нудні проблеми викликають захоплюючі відмови)

cr0x@server:~$ df -h /var/www/html
Filesystem      Size  Used Avail Use% Mounted on
/dev/nvme0n1p2  100G   96G  4.0G  96% /
cr0x@server:~$ df -i /var/www/html
Filesystem       Inodes  IUsed   IFree IUse% Mounted on
/dev/nvme0n1p2  6553600 6501021 52579   99% /

Що це означає: Мало вільного місця або вичерпання інодів можуть зламати оновлення плагінів, записи кешу, файли сесій і тимчасові файли PHP.

Рішення: Якщо використання >90% або іноди >95% — класифікуйте як інцидент: звільніть місце, обертайте логи, очищуйте кеші і вирішіть причину росту.

Завдання 13: Перевірте відгук БД і блокування таблиць

cr0x@server:~$ mysql -u root -p -e "SHOW FULL PROCESSLIST\G" | sed -n '1,80p'
*************************** 1. row ***************************
     Id: 1432
   User: wpuser
   Host: 127.0.0.1:59314
     db: wordpress
Command: Query
   Time: 18
  State: Sending data
   Info: SELECT option_name, option_value FROM wp_options WHERE autoload = 'yes'

Що це означає: Довгі запити на wp_options (autoload) — класичний вектор повільності адміна. Gutenberg відчуватиме «злам», коли насправді відбувається тайм-аут.

Рішення: Якщо запит autoload повільний — аудитуйте розмір автозавантаження опцій, прибирайте сміття і виправляйте плагіни, що спамлять опціями.

Завдання 14: Перевірте розмір автозавантажених опцій (невидимий якір)

cr0x@server:~$ mysql -u root -p wordpress -e "SELECT ROUND(SUM(LENGTH(option_value))/1024/1024,2) AS autoload_mb FROM wp_options WHERE autoload='yes';"
autoload_mb
12.47

Що це означає: Автозавантажувані опції завантажуються на кожен запит. Двозначні мегабайти — це не «нормально». Це податок на затримку.

Рішення: Якщо autoload великий — знайдіть головних винуватців і відключіть/виправте плагіни, що додають великі автозавантажувані записи.

Завдання 15: Ідентифікуйте найбільші автозавантажувані опції (знайдіть плагін)

cr0x@server:~$ mysql -u root -p wordpress -e "SELECT option_name, ROUND(LENGTH(option_value)/1024,1) AS kb FROM wp_options WHERE autoload='yes' ORDER BY LENGTH(option_value) DESC LIMIT 15;"
option_name	kb
some_plugin_cache	2048.0
theme_mods_corp-theme	1536.4
wpseo_titles	412.7

Що це означає: Тепер у вас є імена. Імена — це дія.

Рішення: Для великих кеш-опцій плагінів — переключіть їх на non-autoload або очистіть. Для theme_mods — розгляньте, чи тема занадто багато зберігає і чи редактор сайту це посилює.

Завдання 16: Тимчасово обійдіть об’єктний кеш, щоб перевірити, чи Redis/Memcached не отруюють адмінку

cr0x@server:~$ cd /var/www/html/wp-content
cr0x@server:/var/www/html/wp-content$ ls -l object-cache.php
-rw-r--r-- 1 www-data www-data  48210 Dec 10 09:14 object-cache.php
cr0x@server:/var/www/html/wp-content$ sudo mv object-cache.php object-cache.php.disabled

Що це означає: WordPress використовує wp-content/object-cache.php як drop-in. Перейменування вимикає його.

Рішення: Якщо Gutenberg починає працювати після відключення об’єктного кешу — ваш бекенд кешу або drop-in має баги/неправильну конфігурацію. Виправте це; не лишайте кеш вимкненим назавжди, якщо вам подобаються дорогі запити до БД.

Завдання 17: Підтвердіть, що заголовки не блокують скрипти (CSP — частий самосаботаж)

cr0x@server:~$ curl -sS -D- -o /dev/null https://example.com/wp-admin/post-new.php | egrep -i "content-security-policy|x-frame-options|x-content-type-options"
content-security-policy: default-src 'self'; script-src 'self'; object-src 'none'
x-content-type-options: nosniff

Що це означає: Строгий script-src 'self' може зламати адмінку WordPress, бо ядро іноді покладається на inline-скрипти (і на динамічно підвантажувані чанки).

Рішення: Якщо CSP надто суворий — налаштуйте його конкретно для wp-admin (або видаліть там). Безпека — добра, але ламати редактор не є «більш безпечно», це просто незручно.

Завдання 18: Перевірте наявність змішаного контенту або примусового HTTP у конфігурації WordPress

cr0x@server:~$ wp option get siteurl
https://example.com
cr0x@server:~$ wp option get home
https://example.com

Що це означає: Якщо ці значення HTTP, а ваша адмінка HTTPS — отримаєте невідповідності активів і дивну поведінку cookie.

Рішення: Виправте siteurl/home і заголовки проксі. Потім очистіть кеши.

Типові помилки: симптом → корінь проблеми → виправлення

1) Симптом: Нескінченний індикатор «Loading…» у редакторі

Корінь проблеми: REST API виклики повертають 403 (WAF/плагін безпеки) або повертають HTML замість JSON.

Виправлення: Перевірте /wp-json/ та /wp-json/wp/v2/users/me?context=edit у Network DevTools. Додайте REST-ендпойнти в білдист WAF, відкоригуйте правила плагіна безпеки або виправте PHP-фатали, що породжують HTML-вивід.

2) Симптом: «The editor has encountered an unexpected error» після оновлення плагіна

Корінь проблеми: Плагін неправильно додає скрипти в wp-admin (неправильні залежності, конфліктний React або затирання глобальних змінних).

Виправлення: Вимкніть плагін. Якщо його потрібно залишити — переконайтесь, що він не постачає свій React або не збирає пакети WordPress неправильно; оновіть до сумісної версії.

3) Симптом: Редактор працює для адміністраторів, але падає для редакторів/авторів

Корінь проблеми: Обмеження прав/ролей блокують REST-ендпойнти з context=edit, часто через membership-плагіни або кастомний код.

Виправлення: Порівняйте REST-відповіді за ролями. Виправте мапінг прав і не блокуйте масово wp/v2 ендпойнти.

4) Симптом: Редактор працює лише в інкогніто

Корінь проблеми: Розширення браузера, кешовані пошкоджені активи або interference service worker.

Виправлення: Вимкніть розширення, очистіть дані сайту і переконайтеся, що адмін-активи не кешуються CDN. Перевірте cache-control для load-scripts.php, щоб воно було private/no-store.

5) Симптом: «Updating failed. The response is not a valid JSON response.»

Корінь проблеми: REST-запит збереження повертає HTML (вивід PHP-попередження, сторінка блокування WAF або 500-сторінка).

Виправлення: Подивіться тіло неуспішного мережевого запиту. Виправте PHP-попередження/фатал, відключіть плагін, що друкує вивід, або додайте ендпойнт у білдист WAF.

6) Симптом: Gutenberg ламається лише на великих постах

Корінь проблеми: Великий post_content, багато блоків, важкі шорткоди або виснаження пам’яті під час парсингу/рендерингу блоків.

Виправлення: Обережно підвищіть пам’ять PHP і max execution time, видаліть патологічні блоки/шорткоди, розділіть контент і почистіть ревізії.

7) Симптом: Редактор зламався одразу після «оптимізації продуктивності»

Корінь проблеми: Плагін мініфікації/відкладення застосувався до wp-admin, або CDN закешував wp-admin/load-scripts.php.

Виправлення: Виключіть wp-admin і load-scripts.php з оптимізацій. Переконайтеся, що edge поважає private/no-store заголовки для адміна.

8) Симптом: Випадкові збої, особливо під навантаженням

Корінь проблеми: Насичення PHP-FPM, повільна БД, нестабільність об’єктного кешу, латентність диска або вичерпання інодів.

Виправлення: Ставте це як інцидент продуктивності: перевірте статус FPM, slow-логи, processlist БД, простір на диску/іноди. Виправляйте ємність і гарячі точки.

Чеклісти / покроковий план

Чекліст A: Відлагодження не завантаження Gutenberg (15–30 хв)

1. Консоль браузера: зафіксуйте першу червону помилку. Не десяту. Зазвичай перша і має значення.
2. Вкладка Network: ідентифікуйте перший невдалий запит (часто /wp-json/, /wp-json/wp/v2/settings або /wp-admin/load-scripts.php).
3. Підтвердіть на сервері: curl до невдалого ендпойнта і перевірте статус та content-type.
4. Вимкніть плагіни: wp plugin deactivate --all.
5. Змініть тему: тимчасово активуйте стандартну тему.
6. Обійдіть кеші: вимкніть object cache drop-in; обходьте CDN якщо можливо (прямий origin host header або внутрішній VIP маршрут).
7. Перевірте логи: PHP-FPM лог + веб-лог помилок + debug.log WordPress.
8. Відновлюйте поступово: вмикайте плагіни пакетами, потім тему, потім кеші.

Чекліст B: Коли збереження не вдається, але редактор завантажується

1. У DevTools знайдіть невдалий запит збереження (зазвичай POST на /wp-json/wp/v2/posts/ID).
2. Проінспектуйте тіло відповіді: чи це HTML (сторінка помилки), JSON (з кодом помилки) або пусто?
3. Перевірте заголовки автентифікації/cookie: користувач залогінений? Є SSO або проксі, що переписує cookie?
4. Перевірте логи сервера на 401/403/500 у час тих запитів.
5. Тимчасово вимкніть набори правил WAF, що впливають на POST/JSON ендпойнти.
6. Підтвердіть, що генерація nonce не кешована (адмін-сторінки не повинні кешуватися).

Чекліст C: «Не завантажується» через продуктивність (бо тайм-аути виглядають як баги)

1. Перевірте активні/idle процеси PHP-FPM, повільні запити і тайм-аути.
2. Перевірте БД: довгі запити, блокування таблиць і розмір автозавантаження.
3. Перевірте диск: простір, іноди і симптоми латентності I/O (глибина черги, high await).
4. Спочатку вимкніть найважчі адмін-плагіни (пейдж-білдери, аналітика, сканери безпеки).
5. Лише потім коригуйте таймаути/пам’ять. Збільшення лімітів без виправлення повільності просто продовжує страждання.

Жарт №2: Коли хтось каже «Я нічого не міняв», я припускаю, що вони хочуть сказати «Я щось змінив і не записав цього».

Три корпоративні міні-історії з поля бою

Міні-історія 1: Інцидент через невірне припущення

Середня компанія запускала WordPress за load balancer і nginx reverse proxy. Міграція була «проста»: перенести трафік, залишити origin тим самим, вважати це перемогою. Редактор одразу почав зависати для деяких користувачів, але не для всіх. Звісно, перша теорія була «Gutenberg непередбачуваний».

Підказка була в мережевому трейсінгу: REST-виклики до /wp-json/wp/v2/users/me?context=edit повертали 401 для деяких сесій. Той же користувач, різні результати в залежності від того, на який проксі-нод потрапив. Це пахло cookie.

Вони припустили, що додаток зрозуміє HTTPS автоматично, бо «load balancer термінує TLS». WordPress не поділяв цього припущення. Він дивився на те, що бачить: запити приходили на origin як HTTP, і WordPress генерував cookie/nonce з поведінкою, що не відповідала HTTPS-браузеру.

Вирішення було просте: встановили X-Forwarded-Proto коректно, переконалися, що WordPress його поважає, і виправили siteurl/home. Редактор одразу відновився, а постмортем був нудно банальним: система робила саме те, до чого її налаштували, а не те, що люди вважали.

Міні-історія 2: Оптимізація, що зіграла злий жарт

Інша організація хотіла швидшу адмінку і розгорнула «розумне кешування» на CDN: кешувати будь-який 200-відповідь з «статичними» query-параметрами. Хтось помітив, що load-scripts.php і load-styles.php виглядають як статичні активи. Вони помилилися в такому ключовому сенсі, що спричинили брудні понеділки.

Деякий час здавалось, що все добре. Потім прийшло дрібне оновлення WordPress. Закешований адмінський бандл скриптів не відповідав новим очікуванням серверу, і раптом Gutenberg почав падати з JS-помилками про відсутні модулі та невизначені функції.

Інженери ганяли фантомів: конфлікти плагінів, теми, баги браузера. Підказкою було те, що помилка траплялася лише для користувачів, яких обслуговував edge CDN, і зникала при обході edge. Заголовки cached response теж були підозріло «public».

Виправлення: ніколи не кешуйте лоадери wp-admin на CDN, поважайте private/no-store семантику WordPress, і не вважайте query-string активи безпечними лише тому, що вони на вигляд схожі. Оптимізацію відкотили, і адмінка знову стала нудною — а це правильний стан для бекенду CMS.

Міні-історія 3: Нудна, але правильна практика, що врятувала день

У enterprise-сайта була постійна операційна вимога: кожна зміна, яка зачіпає кешування, WAF або заголовки проксі, має включати префлайт-тест на трьох ендпойнтах — /wp-json/, /wp-admin/load-scripts.php і аутентифікований REST-запит. Не гламурно. Не опціонально.

Одного дня команда безпеки затиснула нову політику WAF, щоб зменшити бот-трафік. Вона блокувала запити, що виглядали як «перебирання API», що включало деякі REST-маршрути, які використовувалися аутентифікованими адмін-екранами. CMS-команда не помітила цього одразу, бо фронт-енд сторінки все ще рендерились.

Але префлайт-тест, який запускався з CI за допомогою облікового запису редактора з низькими правами, провалився за хвилини. Звіт про провал містував HTTP-статуси і фрагменти відповідей. Це означало, що CMS-команді не довелося сперечатися, чи Gutenberg «впав»; у них були докази.

Політику WAF відкоригували з таргетованим дозволом для аутентифікованого wp-json трафіку, і інцидент залишився малим. Мораль прісно передбачувана: нудні перевірки, які ви автоматизуєте, рятують вас, коли люди стають креативними.

Поширені запитання

1) Чому Gutenberg так сильно покладається на REST API?

Тому що це JavaScript-додаток, який отримує і зберігає контент через API-маршрути. Якщо /wp-json/ заблоковано, Gutenberg не може надійно завантажити дані поста, налаштування, інформацію про користувача або виконувати операції збереження.

2) Редактор працює на моєму ноуті, але не у колег. Хто перший підозрюваний?

Кешування та рівні безпеки, що відрізняються за географією, cookie або IP. Поведінка CDN edge, WAF-челенджі або корпоративні проксі можуть вибірково ламати wp-admin запити.

3) Чи може одне PHP-попередження дійсно зламати редактор?

Так. Якщо попередження виводить текст під час REST-відповіді, ваш JSON стає «JSON плюс шум», і Gutenberg вважає його недійсним. Виправте попередження або коректно приглушіть вивід — не просто ховайте його.

4) Чи варто просто встановити плагін Classic Editor і забити?

Тільки як тимчасова міра. Це може підтримати редакторів, поки ви виправляєте підлягаючу проблему з REST/кешуванням/безпекою. Якщо сприймати це як постійне рішення, ви платите відсотки за проблему.

5) Який найшвидший спосіб довести конфлікт плагінів?

Вимкніть усі плагіни через WP-CLI і протестуйте. Якщо працює — вмикайте пакетами. Це швидше, ніж читати код плагінів і прикидатися, що вам це подобається.

6) Чи може база даних бути причиною, чому Gutenberg не завантажується?

Абсолютно. Повільні автозавантажувані опції, дедлоки або довгі запити можуть затримувати REST-відповіді до часу, коли UI тайм-аутиться або здається замороженим. Перевірте processlist і розмір autoload.

7) Об’єктний кеш допомагає чи шкодить Gutenberg?

І те, й інше. Коректно налаштований об’єктний кеш зменшує навантаження на БД і пришвидшує адмінку. Неправильні або баговані drop-in можуть повертати застарілі/некоректні дані, ламати nonces або викликати неконсистентну поведінку. Тимчасово відключіть для ізоляції проблеми.

8) Отримую 403 на wp-json маршрутах лише в wp-admin. Чому?

Тому що аутентифіковані REST-виклики включають cookie і nonce, і рівні безпеки часто обробляють їх інакше. Правила WAF, які підходять для анонімних GET-запитів, можуть блокувати аутентифіковані API-маршрути редактора.

9) Чи погана ідея ставити CSP в wp-admin?

Сам по собі — ні, але легко зробити неправильно. Якщо задати сувору політику без врахування скриптових патернів адмінки WordPress, ви заблокуєте базову функціональність. Налаштовуйте CSP обережно і тестуйте редактор.

10) Мій сайт у мультисайті. Є особливі режими відмов Gutenberg?

Так: невідповідності domain mapping, питання scope cookie між субдоменами та плагіни, активовані на мережевому рівні, що впливають на REST-поведінку. Тестуйте REST API і редактор на кількох підсайтах і ролях.

Наступні кроки, які можна зробити сьогодні

1. Доведіть шар: консоль браузера + вкладка network, потім curl ті самі ендпойнти із сервера.
2. Зробіть REST буденною справою: переконайтеся, що /wp-json/ повертає JSON з 200, а не редиректи, не HTML і не «театр» WAF.
3. Ізолюйте змінні: вимкніть плагіни, переключіться на стандартну тему, обійдіть об’єктний кеш, обійдіть CDN/WAF.
4. Виправляйте інфраструктурні нудні речі: насичення PHP-FPM, тиск на диск, автозавантажуване блоут БД і неправильно задані заголовки проксі.
5. Закріпіть запобігання: додайте просту автоматизовану перевірку, яка після змін кешування/WAF/проксі б’є по REST і адмін-скриптах.

Якщо виконувати ці кроки в такому порядку, ви припините «відлагоджувати Gutenberg» і почнете виправляти справжню систему, яку Gutenberg лише виявляє. І в цьому вся суть гри.