Збої редактора WordPress: конфлікти плагінів і як виявити порушника

Якщо ваш редактор WordPress аварійно завершує роботу, перезавантажується, стає порожнім або застрягає на індикаторі завантаження, це не «просто поганий день у браузері». Ви бачите ланцюжок відмов: помилка JavaScript → REST-запит не пройшов → автозбереження померло → редактор здався. Або PHP-фатали за кулісами. Або плагін воює з іншим плагіном із такою ж витонченістю, як двоє малюків у серверній.

Добра новина: більшість «аварій» редактора можна діагностувати менш ніж за годину, якщо працювати як оператор. Відтворіть помилку. Ізолюйте. Читайте логи. Змінюйте одну змінну за раз. Потім вкажіть на винуватця з доказами, а не інтуїцією.

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

Це версія «в мене п’ять хвилин і стейкхолдер дивиться, як я ділюся екраном». Мета — не виправити все одразу. Мета — знайти шар, що відмовляє: JS у браузері, REST/AJAX WordPress, PHP, база даних або інфраструктура.

Перш за все: визначте, чи це клієнтський JavaScript або серверний PHP

• Відкрийте DevTools браузера → Console. Якщо бачите червоні помилки (TypeError, «Cannot read properties», заблоковані скрипти, CORS), ви в JS-території.
• Відкрийте DevTools → Network і перезавантажте редактор. Відфільтруйте за wp-json і admin-ajax.php. Якщо ці виклики повертають 401/403/500 або зависають, проблема на боці API/PHP.

По-друге: відтворіть у чистій сесії

• Вікно інкогніто/приватне (без розширень, чисті куки). Якщо там працює, у вас кешовані автентифікаційні/сесійні проблеми, розширення браузера ламає адміністративний JS або агресивне edge-кешування.
• Тимчасово переключіться на дефолтну тему. Теми можуть «отруювати» адмін-екрани глобальними скриптами.

По-третє: агресивно ізолюйте конфлікти плагінів

• Вимкніть усі плагіни, підтвердьте стабільність редактора, потім вмикайте пакетами (бінарний пошук). Не вмикайте 37 плагінів по одному, якщо вам не подобається тортури.
• Якщо вимкнення вирішує проблему, це конфлікт плагінів, а не «WordPress такий собі». Звузьте коло.

По-четверте: перегляньте логи навмисно

• PHP error log на предмет фаталів, вичерпання пам’яті, невизначених функцій.
• WordPress debug log для попереджень/notice, що корелюють із завантаженням редактора.
• Логи вебсерверу на предмет 500, 403, таймаутів на REST-ендоінтах.

По-п’яте: підтвердьте виправлення чистим відтворенням

• Відредагуйте пост, викличте автозбереження, вставте блок, відкрийте reusable blocks/patterns, опублікуйте.
• Слідкуйте за Network і Console на предмет нових помилок. Виправлення, що «виглядає нормально», але залишає помилки в консолі — це майбутні інциденти в масках.

Одна парафразована ідея, часто пов’язана з SRE-підходом (парафраз): Сподівання — це не стратегія; надійність приходить через продуманий дизайн і перевірку. — загалом пов’язано з культурою експлуатації та надійності.

Що насправді означає «збій редактора» у WordPress

«Збій» — це слово користувача. WordPress не запускає єдиний процес редактора, який сегфолить; це вебзастосунок. Коли користувачі кажуть «редактор зламався», зазвичай це одне з наступного:

• Порожній екран (white screen of death) на маршруті редактора через PHP-фатали або коли вивід пошкоджено перед відправленням JSON-відповідей.
• Блоковий редактор завантажується, але стає неактивним через виняток JavaScript, часто від плагіна, що інжектить скрипти, блокує основні скрипти або конфліктує з залежностями React.
• Індикатор завантаження застряг через збої REST API (401/403/500) або блокування запитів правилами WAF/CDN.
• Автозбереження не працює, що призводить до «Updating failed» і зрештою відчуття, що редактор поламаний.
• Редактор завантажується, але не можна опублікувати через проблеми з правами, nonce, автентифікацією REST або фільтрами контенту, що повертають некоректні відповіді.

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

Короткий жарт #1: Плагіни як колеги в open office — поодинці нормальні, разом голосні, і хтось обов’язково торкається ваших налаштувань.

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

Трохи корисного контексту допоможе дебагу швидше, бо він показує, де шви системи.

1. Gutenberg (блоковий редактор) став за замовчуванням у WordPress 5.0 (2018). Це був тектоничний зсув: адміністраторний інтерфейс на React, що сильно покладається на REST-ендпоінти і сучасну збірку JS.
2. Блоковий редактор покладається на REST API для основних робочих процесів. Плагін, що ламає REST-відповіді (додатковий вивід, неправильні заголовки, зміни автентифікації), може «зламати» редагування, не торкаючись коду редактора.
3. Сторінки адмінки WordPress не є «імунними» до фронтенд-скриптів. Теми та плагіни можуть підключати скрипти глобально; недбале підключення може забруднити wp-admin.
4. Багато билд- і бібліотек блоків постачають власні JS-бандли. Якщо вони бандлять несумісні версії React-пакетів або розраховують на глобали, редактор перетворюється на місце злочину.
5. Автозбереження й ревізії — не опціональні дрібнички. Автозбереження — це REST/AJAX-потік; коли воно падає, довіра користувача швидко руйнується, бо бояться втратити контент.
6. Сек’юріті-плагіни та WAF дедалі частіше інспектують адмін REST-запити. Помилкові спрацьовування трапляються часто, особливо для JSON-пейлоадів з HTML, шорткодами або «підозрілими» рядками.
7. Обмеження пам’яті PHP усе ще практичний фактор. Редактор може викликати складний парсинг блоків, обробку зображень, SEO-аналіз і рендеринг кастомних полів — усе одночасно.
8. Кешування об’єктів може змінити поведінку плагінів. Деякі плагіни неправильно обробляють кешовані перевірки можливостей, валідацію REST nonce або транзієнти, пов’язані з редактором.
9. WP-CLI став серйозним інструментом для керування плагінами на масштабі. Він швидший, скриптується і працює коли wp-admin не працює.

Поширені режими відмов: де з’являються конфлікти

1) Колізії JavaScript у wp-admin

Блоковий редактор — це JS-застосунок. Одна необроблена помилка може зупинити рендеринг або зламати важливі потоки, як-от вставку блоків. Поширені причини:

• Плагін підключає скрипти на всіх сторінках адмінки (замість лише на своїх) і створює конфлікт залежностей.
• Плагін додає скрипт, що розраховує на глобальні jQuery у контекстах, де їх немає (або підключає старий jQuery).
• «Оптимізаційні» плагіни конкатенують/мінімізують адмін-скрипти та випадково змінюють порядок залежностей.

2) REST API та проблеми з nonce/авторизацією

Дії редактора викликають ендпоінти на кшталт /wp-json/wp/v2/posts/<id>. Якщо ці виклики падають, ви побачите «The response is not a valid JSON response», «Updating failed» або нескінченний спіннер.

Поширені причини:

• Сек’юріті-плагін блокує або переписує REST-маршрути.
• WAF/CDN блокує POST-запити з JSON-плейлоадами або обрізає заголовки.
• Плагін виводить пробіли/HTML-попередження перед JSON, роблячи відповідь некоректною.

3) PHP-фатали та вичерпання пам’яті

Користувачі бачать це як порожній екран, «The site is experiencing technical difficulties» або часткове завантаження UI редактора. У логах часто:

• Allowed memory size exhausted
• Fatal error: Uncaught Error від плагіна, який очікує відсутній клас/функцію
• Type errors після оновлення PHP

4) Проблеми з базою даних та зберіганням (так, зі сховищем)

«Збої» редактора можуть бути таймаутами. Якщо збереження поста викликає повільні запити, заблоковані таблиці або перевантажене сховище, редактор стає ненадійним. Автозбереження особливо чутливе, бо відбувається часто і користувачі помічають кожне тремтіння.

5) CDN, кешування і ілюзія «корисності»

Адмінку зазвичай не слід кешувати на краю. Але трапляються неправильні налаштування: закешовані REST-відповіді, кешовані сторінки для авторизованих користувачів або застарілі JS-бандли. Редактор завантажує невідповідні ресурси і падає.

Короткий жарт #2: Нічого так не говорить про «оптимізацію продуктивності», як кешувати адмін-панель і потім годинами пояснювати, чому реальність не збігається.

Практичні завдання з командами: ізолювати, підтвердити, вирішити

Ці завдання передбачають SSH-доступ і стандартний Linux-стек хостингу. Якщо у вас керований хостинг без shell, адаптуйте логіку: точки прийняття рішень залишаються тими самими.

Правила взаємодії: міняйте одну змінну за раз, фіксуйте докази (фрагменти логів, HTTP-коди, часові позначки) і припиніть гадання. Гадання породжує два інциденти замість одного.

Завдання 1: Підтвердьте версію WordPress і список плагінів

cr0x@server:~$ cd /var/www/example.com/htdocs && wp core version && wp plugin list --status=active
6.6.2
+-------------------------+----------+-----------+---------+
| name                    | status   | update    | version |
+-------------------------+----------+-----------+---------+
| wordfence               | active   | none      | 7.11.6  |
| wp-rocket               | active   | available | 3.16.1  |
| advanced-custom-fields  | active   | none      | 6.3.6   |
| custom-block-library    | active   | none      | 2.4.0   |
+-------------------------+----------+-----------+---------+

Що це означає: тепер ви знаєте рухомі частини і чи правда, що «ми нічого не змінювали».

Рішення: якщо для плагіна оптимізації/сек’юріті є доступне оновлення, розглядайте його як підозрюваного (не автоматично як виправлення, але як підозру).

Завдання 2: Відтворіть з вимкненими плагінами (найшвидший важіль ізоляції)

cr0x@server:~$ cd /var/www/example.com/htdocs && wp plugin deactivate --all
Deactivated 'wordfence' plugin.
Deactivated 'wp-rocket' plugin.
Deactivated 'advanced-custom-fields' plugin.
Deactivated 'custom-block-library' plugin.
Success: Deactivated 4 of 4 plugins.

Що це означає: ви прибрали більшість поведінки сторонніх компонентів. Якщо редактор і досі «падає», проблема, ймовірно, в темі, ядрі, PHP або інфраструктурі.

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

Завдання 3: Повторно вмикайте плагіни бінарним пошуком

cr0x@server:~$ cd /var/www/example.com/htdocs && wp plugin activate advanced-custom-fields custom-block-library
Plugin 'advanced-custom-fields' activated.
Plugin 'custom-block-library' activated.
Success: Activated 2 of 2 plugins.

Що це означає: ви звужуєте коло. Протестуйте редактор. Якщо він падає, винуватець у цьому наборі.

Рішення: якщо сталося падіння, деактивуйте один із двох і повторно протестуйте, щоб знайти конкретний плагін.

Завдання 4: Переключіться на дефолтну тему (теми теж можуть отруювати адмін)

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

Що це означає: ви прибрали логіку enqueue на рівні теми, кастомні стилі редактора та побічні ефекти functions.php.

Рішення: якщо редактор стабільний лише на дефолтній темі, ваш «конфлікт плагінів» може бути кодом теми або взаємодією тема-плагін.

Завдання 5: Увімкніть WordPress debug без спаму на екрані

cr0x@server:~$ cd /var/www/example.com/htdocs && wp config set WP_DEBUG true --raw && wp config set WP_DEBUG_LOG true --raw && wp config set WP_DEBUG_DISPLAY false --raw
Success: Updated the constant 'WP_DEBUG' in the 'wp-config.php' file with the raw value 'true'.
Success: Updated the constant 'WP_DEBUG_LOG' in the 'wp-config.php' file with the raw value 'true'.
Success: Updated the constant 'WP_DEBUG_DISPLAY' in the 'wp-config.php' file with the raw value 'false'.

Що це означає: помилки підуть у wp-content/debug.log замість того, щоб ламати JSON-відповіді, друкуючи попередження в них.

Рішення: відтворіть збій один раз, а потім одразу перегляньте лог.

Завдання 6: Перевірте WordPress debug log за точним часом

cr0x@server:~$ cd /var/www/example.com/htdocs && tail -n 60 wp-content/debug.log
[27-Dec-2025 14:18:02 UTC] PHP Warning:  Cannot modify header information - headers already sent by (output started at /var/www/example.com/htdocs/wp-content/plugins/custom-block-library/includes/debug.php:12) in /var/www/example.com/htdocs/wp-includes/rest-api/class-wp-rest-server.php on line 1898
[27-Dec-2025 14:18:02 UTC] PHP Notice:  Trying to access array offset on value of type null in /var/www/example.com/htdocs/wp-content/plugins/custom-block-library/includes/rest.php on line 77

Що це означає: «headers already sent» — класичний вбивця редактора, бо REST-відповіді мають бути чистим JSON з правильними заголовками. Плагін вивів дані занадто рано.

Рішення: вимкніть цей плагін негайно або запатчуйте вивід. Не «збільшуйте пам’ять» в надії, що це зникне.

Завдання 7: Перевірте логи PHP-FPM і вебсерверу на предмет фаталів і таймаутів

cr0x@server:~$ sudo tail -n 80 /var/log/php8.2-fpm.log
[27-Dec-2025 14:18:02] WARNING: [pool www] child 18422 said into stderr: "PHP Fatal error:  Allowed memory size of 268435456 bytes exhausted (tried to allocate 20480 bytes) in /var/www/example.com/htdocs/wp-content/plugins/advanced-custom-fields/pro/fields/class-acf-field-flexible-content.php on line 312"

Що це означає: редактор досяг ліміту пам’яті під час шляху рендерингу/збереження. Це може проявлятися як застряглий індикатор або загальна невдача.

Рішення: або підвищте пам’ять відповідально (і вимірюйте), або зменшіть поведінку, що споживає пам’ять (конфіг ACF, блок-патерни, важкі мета-бокси). Також перевірте, чи немає витоку пам’яті/регресії після оновлень.

Завдання 8: Перевірте здоров’я REST API зі сторони сервера (щоб обійти шум браузера)

cr0x@server:~$ curl -s -D - https://example.com/wp-json/ -o /dev/null | head
HTTP/2 200
content-type: application/json; charset=UTF-8
x-robots-tag: noindex

Що це означає: індексний ендпоінт REST відповідає JSON і 200. Базова маршрутизація жива.

Рішення: якщо бачите 403/503 або content-type HTML, підозрюйте правила WAF, сторінки обслуговування або корупцію виводу PHP.

Завдання 9: Перевірте, чи admin-ajax повертає помилки (поширено для Classic Editor)

cr0x@server:~$ curl -s -D - -X POST https://example.com/wp-admin/admin-ajax.php -d 'action=heartbeat' -o /dev/null | head
HTTP/2 200
content-type: text/html; charset=UTF-8

Що це означає: heartbeat відповідає. Для детальнішої інформації потрібні auth-куки, але 500 тут — велика червона риска.

Рішення: якщо 500 — йдіть прямо в PHP-логи; якщо 403 — підозрюйте сек’юріті/WAF/зміни прав.

Завдання 10: Знайдіть повільні запити і невдалі ендпоінти в access логах

cr0x@server:~$ sudo awk '$9 ~ /500|502|503|504/ {print $4, $5, $7, $9}' /var/log/nginx/access.log | tail -n 20
[27/Dec/2025:14:18:02 +0000] "/wp-json/wp/v2/posts/219?context=edit" 500
[27/Dec/2025:14:18:03 +0000] "/wp-admin/post.php?post=219&action=edit" 200

Що це означає: сторінка редактора завантажується (200), але REST-запит за даними поста падає (500). Оце й причина «завалу» UI.

Рішення: дебагайте помилку маршруту REST у PHP (плагіни, фільтри теми, вивід), а не HTML-сторінку.

Завдання 11: Перевірте навантаження cron/heartbeat WordPress (іноді це не збій, а навантаження)

cr0x@server:~$ cd /var/www/example.com/htdocs && wp cron event list --due-now | head
+---------------------+-------------------+------------+---------------------+
| hook                | next_run_gmt      | recurrence | args                |
+---------------------+-------------------+------------+---------------------+
| wp_version_check    | 2025-12-27 14:20  | twice_daily| []                  |
| wordfence_daily_cron| 2025-12-27 14:20  | daily      | []                  |
+---------------------+-------------------+------------+---------------------+

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

Рішення: якщо редагування падає в конкретні вікна, зіставте з cron-важкими вікнами; розгляньте планування завдань і обмеження сканів безпеки.

Завдання 12: Перевірте конфігурацію PHP щодо пам’яті і таймаутів

cr0x@server:~$ php -i | egrep 'memory_limit|max_execution_time|max_input_vars' | head -n 20
memory_limit => 256M => 256M
max_execution_time => 30 => 30
max_input_vars => 1000 => 1000

Що це означає: 256M може бути достатньо або ні залежно від стеку плагінів; max_input_vars=1000 може ламає великі форми мета-боксів.

Рішення: якщо бачите фатали пам’яті — підвищуйте memory_limit (і налаштування PHP-FPM) контрольовано; якщо збереження великих форм падає — збільшіть max_input_vars і перетестуйте.

Завдання 13: Визначте, чи плагін оптимізації змінює адмін-ресурси

cr0x@server:~$ cd /var/www/example.com/htdocs && wp option get wp_rocket_settings | head
a:5:{s:9:"minify_js";i:1;s:15:"combine_js";i:1;s:12:"exclude_js";a:0:{}s:17:"cache_logged_user";i:1;s:17:"cache_ssl";i:1;}

Що це означає: налаштування вказують на мінімізацію/об’єднання JS і кешування для увійшлих користувачів. Це ризикована комбінація для стабільності wp-admin/редактора.

Рішення: відключіть мініфікацію/об’єднання для адмін/editor маршрути, і не кешуйте сторінки для авторизованих користувачів на сторінковому рівні.

Завдання 14: Підтвердіть, що ви не подаєте змішані або застарілі ресурси після деплою

cr0x@server:~$ cd /var/www/example.com/htdocs && wp core verify-checksums
Success: WordPress installation verifies against checksums.

Що це означає: файли ядра цілі. Якщо редактор і досі ламається, зосередьтеся на плагінах/темах/mu-plugins і кеш-шафлах.

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

Завдання 15: Перевірте must-use плагіни і drop-in файли (приховані впливальні)

cr0x@server:~$ cd /var/www/example.com/htdocs && wp plugin list --status=must-use && ls -1 wp-content | egrep 'mu-plugins|object-cache.php|advanced-cache.php'
+-------------------+----------+--------+---------+
| name              | status   | update | version |
+-------------------+----------+--------+---------+
| platform-mu-stack | must-use | none   | 1.4.2   |
+-------------------+----------+--------+---------+
advanced-cache.php
mu-plugins
object-cache.php

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

Рішення: перегляньте код MU-плагіна і кеш-дропіни, якщо звичайне вмикання/вимикання плагінів не змінює поведінки.

Завдання 16: Перевірте стан сховища і файлової системи, коли збереження займає занадто багато часу

cr0x@server:~$ iostat -xz 1 3
Linux 6.5.0 (web01) 	12/27/2025 	_x86_64_	(4 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          12.31    0.00    4.15    9.72    0.00   73.82

Device            r/s     rkB/s   rrqm/s  %rrqm   r_await rareq-sz     w/s     wkB/s   wrqm/s  %wrqm   w_await wareq-sz  aqu-sz  %util
nvme0n1          8.00    512.00     0.00   0.00    3.20    64.00   110.00   4096.00    18.00  14.06   45.10    37.24    5.12  92.00

Що це означає: високий %util і велике w_await вказують на затори на запис. Збереження поста й автозбереження — це операції запису.

Рішення: якщо збереження редактора збігається з високою затримкою запису, досліджуйте I/O бази даних, повільні запити, завдання резервного копіювання або «шумних сусідів». Не звинувачуйте JavaScript у проблемі, яка фактично є чергою диска.

Три корпоративні міні-історії з реальних інцидентів

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

Компанія впроваджувала оновлений редакційний робочий процес. Нові блоки, кілька кастомних типів записів і «малесенький» плагін, що додавав бічну панель для метаданих відповідності. Редактор почав падати лише на одному сайті мережі multisite. Зрозуміло, усі припустили, що це «через контент», бо це відбувалося на постах з великою кількістю embed-ів.

Вони провели півдня, витягуючи «погані пости», обрізаючи HTML, видаляючи embed-и і тестуючи різні браузери. Нічого не було послідовним. Збій був випадковим: іноді при завантаженні, іноді при вставці блоку, іноді через кілька хвилин. Класичний інцидент, коли команда починає звинувачувати користувача, бо це емоційно заспокоює.

Неправильне припущення: «Якщо це плагін, він би ламав усюди». Насправді плагін мав сайт-специфічну опцію, що вмикала debug-вивід у продакшні. Він друкував один рядок перед REST-відповідями. Не достатньо, щоб показати його на сторінці, але достатньо, щоб пошкодити JSON.

Коли вони одночасно переглянули debug.log і access логи вебсерверу, стало очевидно: кожен збій редактора збігався з REST 500 і попередженням «headers already sent», що вказувало на compliance-плагін. Вимкнули плагін для того сайту — редактор відразу стабілізувався. Потім виправили плагін, щоб не echo/print у продакшн шляхах, і випустили міграцію конфігурації, яка вимикала debug-флаг.

Висновок: ніколи не робіть припущень щодо масштабу проблеми на основі «це плагін». Плагіни можуть поводитися по-різному для різних сайтів, ролей, типів контенту й середовищ. Докази завжди перемагають припущення.

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

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

Тиждень це здавалося нормальним. Потім редактор почав час від часу кидати JavaScript-помилки. Не завжди однакові. Іноді блоки не вставлялися. Іноді медіабібліотека не відкривалася. Публікація стала рулеткою. Тікети підтримки приймалися з передбачуваною ритмікою: достатньо болісно, щоб створити проблему, але не достатньо, щоб примусити повний відкат.

Причина не в самій «мінімізації». Проблема була в порядку залежностей і застарілих кешів. Плагін оптимізації створював комбінований адмін-бандл, що іноді повертав застарілу версію після оновлення плагіна, тоді як інший плагін очікував новішу збірку. Блоковий редактор завантажував невідповідні пакети і ламавався на півдорозі рендерингу.

Фікс був нудним і негайним: перестати оптимізувати wp-admin як публічну маркетингову сторінку. Виключили admin/editor маршрути з об’єднання/мінімізації і перестали кешувати увійшлих користувачів на рівні сторінки. Після цього фронтенд усе ще можна оптимізувати безпечно — там інвалідизація кешів передбачувана і вплив відмов менший.

Висновок: робота з продуктивністю, яка ігнорує режими відмов, — це інженерія інцидентів у кращому випадку. Оптимізуйте фронтенд; залишайте адмін детермінованою.

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

Великий внутрішній новинний портал мав сувору політику змін для оновлень WordPress: оновлення плагінів групувалися, деплоїлися на staging і тестувалися коротким, але послідовним скриптом: відкрити редактор, вставити блоки, завантажити медіа, автозберегти, опублікувати і перевірити ревізії. Ніяких героїв, лише рутинна перевірка.

Одного ранку редактор застряг на завантаженні. Інженер на чергуванні не панікував і не почав випадково перемикати налаштування. Вони перевірили нотатки останнього деплою, побачили оновлення сек’юріті-плагіна і слідували встановленому плану: відтворити, перевірити REST-виклики, прочитати логи і порівняти зі staging.

Staging був нормальний. Production — ні. Це розходження було важливим. Вони переглянули логи WAF і знайшли нове правило, яке блокувало POST REST-запити з певними HTML-патернами. Оновлення сек’юріті-плагіна було співпадінням — спокусливо, але неправильним висновком. Нудна практика «записувати, що змінилося» запобігла невірному відкату.

Вони відкоригували правило WAF для автентифікованого трафіку wp-admin і підтвердили відновлення редактора. Постмортем був короткий, не гучний і корисний. Політика змін не запобігла інциденту, але не дозволила команді звинуватити невірний компонент і марнувати день.

Висновок: дисципліноване відстеження змін і повторюваний тестовий скрипт — це не бюрократія. Це спосіб зменшувати масштаб інцидентів.

Поширені помилки: симптом → корінна причина → виправлення

Ось патерни, які я бачу регулярно. Вони марнують час, бо симптоми вводять в оману.

1) «The response is not a valid JSON response» при оновленні

• Симптом: редактор показує помилку JSON; у Network REST-запит повертає HTML або зайві символи.
• Корінна причина: плагін/тема виводить warnings/notices/echo перед JSON; або сек’юріті-шар інжектить сторінку-челендж.
• Виправлення: встановіть WP_DEBUG_DISPLAY false; вимкніть проблемний плагін; перевірте логи на «headers already sent»; додайте REST у білий список у WAF для автентифікованих користувачів.

2) Білий екран або «critical error» лише на сторінках редактора

• Симптом: wp-admin завантажується, але маршрут редактора порожній.
• Корінна причина: PHP-фатал у мета-боксі, рендерері кастомного поля або під час реєстрації блоку; часто тригериться лише для певного типу запису.
• Виправлення: tail PHP-FPM лог, знайдіть файл/рядок фаталу, вимкніть плагін і перевірте сумісність з версією PHP.

3) Редактор завантажується, але зависає після кліку «Add block»

• Симптом: UI замерзає; Console показує TypeError у скрипті плагіна.
• Корінна причина: плагін інжектить адмін JS глобально, конфліктує з пакетами Gutenberg або розраховує на глобали.
• Виправлення: вимкніть підозрілий плагін; якщо підтримуєте його, виправте умови enqueue і залежності; уникайте бандлінгу конфліктних версій пакетів Gutenberg.

4) Автозбереження не вдалося, потім усе здається зламаним

• Симптом: індикатор автозбереження падає; іноді «Publishing failed».
• Корінна причина: REST-запити блокуються (403), nonce не збігається через кешування, або таймаути через повільну БД/сховище.
• Виправлення: не кешуйте admin/rest-відповіді; перевірте статуси REST; дослідіть I/O затримки і повільні запити.

5) Працює для адмінів, падає для редакторів/авторів

• Симптом: специфічні для ролей збої редактора або відсутні панелі.
• Корінна причина: кешовані неправильно перевірки прав; плагін обмежує REST-маршрути за ролями; кастомні зміни ролей конфліктують з очікуваннями плагінів.
• Виправлення: тестуйте з тією ж роллю; перевірте плагіни для ролей/прав; очистьте object cache; перевірте MU-плагіни, що впливають на автентифікацію.

6) Падає лише за CDN / лише в продакшні

• Симптом: staging OK; production редактор інтермітуючий ламається.
• Корінна причина: edge-кешування сторінок для увійшлих, правила WAF, некоректна Brotli/gzip, або кешування ресурсів що повертає невідповідні версії.
• Виправлення: обхід кешу для /wp-admin/, /wp-json/ при уведених сесіях; очищення кешу після деплою; перевірка заголовків.

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

A. Дисциплінований план ізоляції (рекомендовано)

1. Фіксуйте симптоми точно: який редактор (блоковий/класичний/білдер), який тип запису, яка роль, який браузер, яке точне повідомлення про помилку.
2. Відтворіть з відкритими DevTools: зафіксуйте Console помилки і невдалі Network виклики (ендпоінт + код статусу).
3. Вимкніть усі плагіни: підтвердьте, чи повертається стабільність.
4. Переключіться на дефолтну тему: підтвердьте, чи причетна тема.
5. Увімкніть плагіни пакетами: бінарний пошук до ідентифікації набору, потім конкретного плагіна.
6. Підтвердіть серверні докази: зіставте часову мітку збою з логами PHP-FPM і вебсерверу.
7. Підтвердіть цілісність REST: відповіді REST мають бути JSON, без попереджень і HTML-вставок.
8. Виправте або пом’якшіть: оновіть плагін, скоригуйте конфіг, виключіть адмін з оптимізації, підвищіть пам’ять або запатчуйте код.
9. Перевірте фікс скриптом: завантажити редактор, вставити блоки, завантажити медіа, автозберегти, опублікувати, редагувати знову.
10. Напишіть коротку нотатку про інцидент: що зламалося, як ви це довели, що змінили і як виявити наступного разу.

B. План відновлення, якщо не вдається зайти до wp-admin

1. SSH на сервер і вимкніть плагіни через WP-CLI.
2. Якщо WP-CLI недоступний, перейменуйте каталог plugins (останній засіб) або деактивуйте певні папки плагінів.
3. Спочатку стабілізуйте редактор, потім обережно поновлюйте компоненти.

C. Повторюваний smoke-test редактора (використовуйте після кожної зміни)

• Відкрийте існуючий пост з великою кількістю блоків.
• Додайте новий блок, перемістіть його, виконайте undo/redo.
• Завантажте зображення, вставте його, оновіть alt-текст.
• Зачекайте, поки спрацює автозбереження; підтвердіть відсутність помилок.
• Опублікуйте/оновіть; перевірте, чи пост завантажується на фронтенді.
• Відкрийте пост знову; перевірте, що ревізії є і редактор чисто завантажується.

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

1) Чи більш схильний блоковий редактор до конфліктів плагінів, ніж Classic Editor?

Так, бо це JS-важкий застосунок, що залежить від REST. Classic Editor більше оперує формами/AJAX. Різні режими відмов, та одна корінна причина: плагіни занадто широко підключаються до системи.

2) Якщо вимкнення всіх плагінів вирішує проблему, чи останній оновлений плагін завжди винуватець?

Ні. Оновлення корелюють з інцидентами, бо змінюють систему, але реальний тригер може бути в шарі кешу, апгрейді PHP або другому плагіні, що реагує на оновлення.

3) Чому редактор падає лише на одному пості?

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

4) Що зазвичай означає «invalid JSON response» на практиці?

Або сервер повернув HTML (сторінка-челендж WAF, сторінка попередження PHP), або він повернув JSON з додатковими символами до/після (PHP notices, випадковий echo). REST-клієнти суворі — і правильно.

5) Чи можуть розширення браузера викликати збої редактора WordPress?

Так. Менеджери паролів, блокувальники реклами і «приватні» розширення можуть блокувати скрипти або змінювати запити. Тому тест в інкогніто — швидка перевірка здорового глузду.

6) Чи варто підвищувати PHP memory_limit, щоб виправити збої редактора?

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

7) Чому воно працює на staging, але не в production?

У production зазвичай є edge-кеш, WAF-правила, реальний трафік, фонова робота і інший object cache. Staging спокійніший. Баги люблять спокій, бо там їх легше приховати.

8) Як знайти конфлікт, коли збій інтермітуючий?

Інструментуйте: логовуйте часові мітки, фіксуйте коди статусів у Network і зіставляйте з серверними логами. Інтермітуючі проблеми часто збігаються з простроченням кешу, cron-завданнями або піковим навантаженням.

9) Чи безпечно вимикати плагіни на живому сайті для дебагу?

Залежить від плагіна. Тимчасове вимкнення плагіна безпеки зазвичай безпечніше, ніж залишати редактор поламаним годинами. Але робіть це свідомо: анонсуйте, обмежте час і акуратно поверніть зміни.

10) Якщо винуватець — MU-плагін або кеш-дропін?

Тоді звичайне вмикання/вимикання плагінів не допоможе. Потрібно інспектувати wp-content/mu-plugins, object-cache.php і advanced-cache.php і координуватися з тим, хто керує платформним шаром.

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

Якщо ваш редактор WordPress падає, не сприймайте це як містичну UI-проблему. Ставтесь до неї як до інциденту в продакшні з зовнішнім впливом на користувачів.

1. Запустіть швидку діагностику: DevTools Console + Network, потім ізолюйте плагіни.
2. Увімкніть логування безпечно: лог до файлу, не на екран. Захистіть JSON-відповіді.
3. Доведіть винуватця: вимкніть усі плагіни, увімкніть пакетами, зіставте з рядками логів і HTTP-статусами.
4. Виправте клас проблеми: виключіть wp-admin з «оптимізації», додайте REST до білого списку для автентифікованих у WAF і тримайте реалістичні ліміти пам’яті.
5. Інституалізуйте процес: збережіть короткий smoke-test редактора і запускайте його після оновлень. Нудно — це добре. Нудно — стабільно.