Уявіть: ви дописали пост, натиснули «Опублікувати», а WordPress видає червону плашку з помилкою. Оновити сторінку? Та сама помилка. Перезайти в адмінку? Без змін. Пост висить у чернетках, а час підтискає.

Помилка оновлення (Updating Failed) або публікації (Publishing Failed), одна з тих проблем, які ставлять у глухий кут: повідомлення не каже, що саме зламалося. Але за роки роботи з WordPress ми вивели чітку послідовність діагностики. У більшості випадків причина лежить на поверхні, а виправлення займає пару хвилин.

У цьому матеріалі, 7 перевірених способів: від найпростіших (інтернет і URL сайту) до точкового налагодження через wp-config і роботи з плагінами. Кожен крок, із конкретними діями та скриншотами з адмінки.

💡 Швидкий огляд:

• Перевірити інтернет-з'єднання та URL сайту в налаштуваннях
• Відкрити «Інструменти → Стан сайту» та перевірити статус REST API
• Увімкнути режим налагодження через WP_DEBUG у wp-config.php
• Видалити тимчасовий файл .maintenance із сервера через FTP
• Деактивувати всі плагіни разом і вмикати по одному, виявляючи конфлікт
• Тимчасово замінити Gutenberg на Classic Editor, щоб виключити конфлікт із блочним редактором
• Якщо нічого не спрацювало, звернутися до хостера або спільноти WordPress

1. Перевірте інтернет-з'єднання та URL сайту

Найпростіша, і тому часто пропущена, причина: WordPress втрачає зв'язок із сервером посеред запиту.

Відкрийте сусідню вкладку браузера та зайдіть на будь-який сайт. Сторінка завантажилася? Інтернет працює. Ні, відновіть з'єднання та спробуйте опублікувати пост заново.

Якщо інтернет у порядку, наступний підозрюваний, налаштування URL. За роки міграцій, зміни доменів та експериментів з HTTPS адреси в «Налаштування → Загальні» іноді розходяться з реальністю. Перейдіть туди та звірте два поля: Адреса WordPress (URL) і Адреса сайту (URL). Вони мають збігатися з фактичною адресою, за якою ви заходите в адмінку.

Якщо обидві адреси правильні, а помилка не зникає, йдемо глибше.

2. Перевірте статус REST API

WordPress REST API — це механізм, через який редактор Gutenberg спілкується із сервером. Коли REST API не відповідає або повертає помилку, кнопка «Опублікувати» перестає працювати.

На щастя, у WordPress 5.2 і новіших є вбудований інструмент діагностики. Зайдіть в Інструменти → Стан сайту (Site Health). Прогортайте до секції «Рекомендовані покращення» та знайдіть рядок «The REST API encountered an unexpected result» або аналогічну помилку.

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

• Плагіні безпеки, що блокує REST-запити (Wordfence, iThemes/Solid Security з агресивними налаштуваннями файрвола);
• Кастомному коді в functions.php, який випадково ламає REST-ендпоїнти;
• Плагіні кешування, що віддає закешовану відповідь REST API.

Вимкніть підозрілий плагін і перевірте стан REST API на тій самій сторінці.

3. Увімкніть режим налагодження WordPress

Коли проблема не на поверхні, її потрібно «підсвітити», для цього в WordPress передбачено вбудований режим налагодження.

Вам знадобиться доступ до файлів сайту. Підійде FTP-клієнт (FileZilla, WinSCP) або файловий менеджер у панелі хостингу. Перед будь-якими правками файлів зробіть бекап. Помилка в wp-config.php може покласти сайт, а резервна копія поверне все за хвилину.

Порядок дій:

• Підключіться до сервера через FTP, знайдіть кореневу папку WordPress (там же, де лежать wp-content, wp-admin і wp-includes).
• Знайдіть файл wp-config.php і завантажте його на комп'ютер.
• Відкрийте файл у текстовому редакторі (Notepad++, Sublime Text, не Word і не Блокнот, які ламають кодування).
• У самий низ, перед рядком /* That's all, stop editing! Happy publishing. */, додайте:

1
define('WP_DEBUG', true);
2
define('WP_DEBUG_LOG', true);
3
define('WP_DEBUG_DISPLAY', false);

Перший рядок вмикає налагодження, другий, записує помилки у файл wp-content/debug.log (не показуючи відвідувачам), третій, приховує помилки з екрана сайту.

Збережіть файл і завантажте назад на сервер із заміною. Тепер спробуйте опублікувати пост. Якщо помилка зникла, причина була в попередженні PHP, яке глушило REST-відповідь. Відкрийте wp-content/debug.log через той самий FTP і знайдіть записи з PHP Notice або PHP Warning, вони вкажуть на плагін-винуватця.

Коли закінчите, обов'язково вимкніть WP_DEBUG, замінивши true на false, інакше debug.log зростатиме нескінченно.

Якщо помилка залишилася, йдемо далі.

4. Видаліть файл.maintenance

WordPress створює тимчасовий файл .maintenance у корені сайту під час оновлень ядра, плагінів і тем. Він переводить сайт у режим обслуговування, відвідувачі бачать повідомлення «Технічні роботи, зайдіть пізніше».

Іноді оновлення завершується, а .maintenance залишається. WordPress думає, що обслуговування ще триває, і блокує публікацію.

Знову відкрийте FTP, зайдіть у кореневу папку та знайдіть файл .maintenance (з крапкою на початку, він прихований; у FileZilla увімкніть показ прихованих файлів через «Сервер → Примусово показувати приховані файли»).

Видаліть .maintenance і одразу перевірте публікацію, ефект тримається близько 10 хвилин (WordPress перестворює файл, якщо оновлення ще активне). Якщо помилка зникла, а через 10 хвилин повернулася, значить, фонове оновлення все ще висить. Зачекайте або доведіть його до завершення через «Плагіни → Встановлені» (там буде статус оновлення).

5. Знайдіть конфліктний плагін

Найчастіша причина помилок публікації, конфлікт плагінів. Один плагін ламає REST API, інший втручається в процес збереження, третій конфліктує з Gutenberg.

Швидкий спосіб знайти винного, масова деактивація з послідовним увімкненням:

• Перейдіть у Плагіни → Встановлені плагіни.
• Позначте галочкою «Плагін» у шапці таблиці, виберуться всі.
• У випадному списку «Дії» виберіть «Деактивувати» та натисніть «Застосувати».

Тепер усі плагіни вимкнені. Спробуйте опублікувати пост. Вийшло? Чудово, причина в одному з плагінів. Вмикайте їх по одному та після кожного перевіряйте публікацію. Щойно помилка повернулася, ви знайшли винуватця.

Що робити з проблемним плагіном:

• Оновіть його до останньої версії (розробник міг уже виправити баг).
• Напишіть у підтримку плагіна з деталями: версія WordPress, версія плагіна, за яких дій виникає помилка.
• Тимчасово замініть аналогом, поки розробник не випустить фікс.

6. Тимчасово замініть Gutenberg на Classic Editor

Блочний редактор Gutenberg з'явився у WordPress 5.0 і відтоді пройшов довгий шлях. Але конфлікти з окремими плагінами та темами досі трапляються, особливо зі старими page builder'ами (WPBakery, старі версії Elementor) і плагінами, які не адаптовані під REST API.

Класичний редактор не використовує REST API для збереження, він працює через старий admin-ajax.php. Тому його встановлення, швидкий тест: якщо помилка зникає, проблема саме у зв'язці Gutenberg + якийсь плагін.

Встановіть Classic Editor, офіційний плагін від команди WordPress:

• Плагіни → Додати новий.
• У пошуку наберіть «Classic Editor».
• Натисніть «Встановити», потім «Активувати».

Після активації спробуйте опублікувати пост через класичний редактор. Працює? Значить, конфлікт на стороні Gutenberg.

Важливо: це діагностичний, а не постійний крок. Classic Editor вимикає блочний редактор, ви втрачаєте всі можливості Gutenberg: блоки, шаблони, вбудоване форматування. Коли знайдете плагін-винуватця (методом із кроку 5), видаліть Classic Editor і поверніться до Gutenberg уже з виправленим оточенням.

7. Зверніться по допомогу

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

Ось куди звертатися, в порядку ефективності:

Хостинг-провайдер. Напишіть у техпідтримку з деталями: версія WordPress, версія PHP, які плагіни активні, за якої дії виникає помилка. У хостера є доступ до серверних логів, часто вони бачать причину за хвилину (закінчився дисковий простір, PHP-модуль вимкнено, ліміт пам'яті).

Форуми WordPress. Офіційний форум підтримки WordPress.org, живе співтовариство, де відповідають розробники ядра та автори плагінів. Відкрийте тему, додайте скриншоти та вивід debug.log.

Після читання цього матеріалу у вас є повний ланцюжок діагностики: від клацання мишею до правки серверних файлів. У 9 випадках із 10 проблема вирішується на кроках 1-5, без FTP і wp-config.

Нижче, відповіді на найчастіші запитання та відео для закріплення матеріалу.

⁉️🤔 Часті запитання

Чому помилка виникає одразу після оновлення WordPress?

Найімовірніше, один із плагінів несумісний із новою версією ядра або новою версією PHP, яку хостинг активував разом з оновленням. Пройдіть крок 5 (масова деактивація), ви швидко знайдете винуватця.

Чи можна просто перевстановити WordPress і не розбиратися?

Перевстановлення ядра через «Оновлення → Встановити заново» безпечне й не чіпає контент/плагіни. Але якщо помилка викликана конфліктом плагінів, перевстановлення ядра не допоможе. Краще витратити 5 хвилин на діагностику за кроками вище, ніж наосліп перебирати рішення.

Чому помилка з'являється лише на одному пості, а решта публікуються нормально?

Ймовірна причина, у вмісті самого поста. Якась комбінація блоків Gutenberg, вставлений iframe або скрипт викликає збій під час збереження. Спробуйте скопіювати вміст у новий пост і опублікувати. Якщо новий пост публікується, видаліть старий і працюйте з копією.

Чи потрібно тримати Classic Editor постійно після фіксу?

Ні. Classic Editor, тимчасове діагностичне рішення. Щойно ви знайшли та виправили конфліктний плагін, видаліть Classic Editor і поверніться до Gutenberg. Блочний редактор, стандарт WordPress, і відмовлятися від нього без серйозної причини не варто.

Що робити, якщо немає доступу до FTP?

Використовуйте файловий менеджер у панелі хостингу (cPanel → File Manager, ISPmanager → Файли). Функціонально він робить те саме. Якщо і його немає, зверніться в техпідтримку хостингу, вони допоможуть із доступом.

Який зі способів пробувати першим?

Універсальна формула: перевірте інтернет (10 секунд) → зазирніть у Site Health (30 секунд) → масово деактивуйте плагіни (1 хвилина). У більшості випадків на цьому етапі проблему вже вирішено.

Якщо помилка повертається після фіксу, значить, знайдено не корінь, а симптом. Увімкніть WP_DEBUG_LOG (крок 3) і зберіть повний лог, він покаже точний файл і рядок із помилкою. З цим логом можна йти в підтримку плагіна або на форум WordPress.

І головне: завжди тримайте свіжий бекап. Він перетворює будь-який збій із катастрофи на п'ятихвилинну затримку.