Плагін WordPress зламав сайт: відключіть його через FTP/SSH і швидко відновіть роботу

December 25, 2025 • February 3, 2026 • Читання: 5 хв • Views: 7

Було корисно?

Ваш сайт працював нормально. Потім ви оновили «ще один маленький плагін». Тепер ви дивитесь на помилку 500, білий екран або wp-admin, який ввічливо відмовляється завантажуватися. Бізнес просить ETA. Pager знову подає той звук. Ласкаво просимо.

Це керівництво з відновлення для тих, кому потрібен сайт назад зараз, без ускладнення постмортему. Ми відключимо проблемний плагін через файлову систему (FTP/SSH), підтверджуємо, що саме сталося, і встановимо запобіжні заходи, щоб наступне оновлення не перетворилося на інцидент.

Швидкий план діагностики (перші 10 хвилин)

Ви намагаєтеся відповісти на одне питання: Чи сайт паде через фатальну помилку PHP, через недоступну базу даних, чи через те, що WordPress застряг у поганому стані (режим обслуговування, автозавантажені опції, конфлікт плагінів)?

Не «пробуйте випадкові виправлення». Саме так виходить робочий сайт без розуміння причини, що ввічливо означає «повторний інцидент». Ось порядок, який швидко знаходить вузьке місце.

1) Підтвердіть режим відмови ззовні

Якщо ви бачите HTTP 500/502/503: підозрюйте фатальні помилки PHP, тайм-аути верхнього рівня або режим обслуговування.
Якщо ви бачите білий екран (без HTML): класична фатальна помилка PHP або вичерпання пам’яті.
Якщо wp-admin завантажується, але дії завершуються невдачею: записи в базу даних, права доступу, проблеми з nonce/сесіями або конкретний хук плагіна.
Якщо не працює лише головна сторінка: тема, кешувальний шар, плагін конструктора сторінок або конкретний маршрут.

2) Перевірте серверні логи перед втручанням у WordPress

Логи покажуть, чи маєте ви справу з фаталом плагіна, проблемою прав доступу або чимось нижчого рівня (PHP-FPM не працює, диск заповнений). Якщо ви не можете швидко знайти логи, ви все ще можете відключити плагіни через файлову систему як грубу міру — але краще, коли можна назвати підозрюваного.

3) Вимкніть підозрілий плагін (спочатку одиночний)

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

4) Очистіть кеші і підтвердіть здоров’я PHP

Object cache, page cache, CDN cache і PHP opcache можуть продовжувати віддавати зламану поведінку після того, як ви «виправили» файли. Підтвердіть через прямий запит, знову перевірте логи і лише потім оголосіть перемогу.

5) Стабілізуйте перед повторним увімкненням

Коли сайт повернувся, ваше завдання змінюється: зберегти докази (логи), запобігти автооновленням, що повторно зламають ситуацію, і створити безпечний шлях для повторного введення плагіна або відкату.

Цитата, яку варто тримати на столі: Парафразована ідея — Gene Kranz: невдача неприйнятна; команди досягають успіху завдяки дисциплінованій підготовці і виконанню під тиском.

Що зазвичай ламається, коли плагін «ламає WordPress»

Плагіни WordPress — це не «розширення» в делікатному сенсі. Це шматки PHP, що виконуються в рамках життєвого циклу запиту з тими ж привілеями, що і ядро. Плагін може:

Викликати фатальну помилку (синтаксична помилка, відсутній клас/функція, невідповідність версії PHP).
Вичерпати пам’ять або тайм-аути (безкінечні цикли, великі автозавантажені опції, дорогі запити).
Пошкодити сесії в адмінці (кукі, nonces, редиректи).
Пошкодити правила перезапису або вивести некоректні заголовки.
Запустити зміни схеми БД, що застосувалися частково.

Два великих «підводних каменя», що роблять інциденти з плагінами випадковими:

Автозавантажені опції: Деякі плагіни зберігають великі дані в wp_options з autoload = 'yes'. Це означає, що WordPress підтягує їх у пам’ять на багатьох запитах. Все сповільнюється, а потім падає.
Порядок завантаження та хуки: Ваш сайт може ламатися лише для залогінених користувачів або лише в cron, бо саме там спрацьовує хук плагіна.

Жарт #1: Оновлення плагіна — це як «тільки швидка зміна» в п’ятницю — технічно можливо, духовно не надто розумно.

Шлях відновлення A: відключення плагіна через FTP / файловий менеджер

Якщо у вас є FTP або файловий менеджер хостингу, але немає shell, ви все ще можете швидко відновити роботу. Мета — змусити WordPress припинити завантажувати код плагіна. WordPress завантажує плагіни, скануючи директорії під wp-content/plugins. Якщо ім’я директорії змінено, WordPress вважає його відсутнім і деактивує плагін.

Відключити один плагін (рекомендовано)

Підключіться через FTP / відкрийте файловий менеджер хостингу.
Перейдіть до: public_html/wp-content/plugins/ (ваш корінь може відрізнятися).
Знайдіть папку плагіна, що оновлювався або викликає підозру.
Перейменуйте її, наприклад:
- elementor → elementor.disabled
- woocommerce → woocommerce.off
Оновіть сайт і wp-admin.

Що це робить: WordPress бачить, що плагін відсутній і позначає його як деактивований. Це грубо, але працює навіть коли PHP «горить».

Відключити всі плагіни (ядерне рішення, але швидко)

Зайдіть у wp-content/.
Перейменуйте plugins → plugins.disabled.
Оновіть. Якщо сайт повернувся, ви довели, що інцидент пов’язаний з плагінами.
Створіть нову порожню директорію plugins (WordPress очікує її), потім переміщуйте плагіни назад по одному.

Коли FTP-відновлення не вдається

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

система деплойменту перезаписує файли
файлова система доступна лише для читання / проблеми з правами
кілька копій WordPress і ви редагуєте не ту

У такому випадку вам потрібен SSH або підтримка хостингу, щоб підтвердити реальний document root і власність файлів.

Шлях відновлення B: відключення плагіна через SSH (і чому це краще)

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

Мінімальний план SSH

Знайдіть кореневий каталог WordPress.
Підтвердіть директорію плагінів і ім’я папки плагіна.
Перейменуйте папку плагіна (або каталог plugins), щоб відключити.
Перевірте логи, щоб упевнитися, що фатал зупинився.
Оновіть за допомогою curl і підтвердіть HTTP-статус та вміст.

Чому перейменування працює надійно

WordPress зберігає «активні плагіни» в базі даних, але все одно перевіряє, чи існує файл плагіна. Якщо папки немає, WordPress не може її підключити і деактивує на наступному завантаженні. Перейменування фактично створює «повітряну щілину» між WordPress і зламаним PHP.

Шлях відновлення C: WP-CLI деактивація (найчистіший варіант)

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

Перевірте відновлення як SRE (не довіряйте лише головній сторінці)

Повернути головну сторінку — приємно. Це ще не «відновлення». Справжня перевірка включає:

wp-admin завантажується і вхід працює
запит з обходом кешу повертає 200
логи помилок перестали показувати фатали
форми оформлення/контакти все ще надсилаються
cron не штовхає масово помилок

Також: зробіть снапшот (резервну копію) після стабілізації. Не раніше. Бекап зламаного стану — це сувенір, а не рішення.

Практичні завдання з командами: що означає вивід і що робити далі

Нижче — практичні завдання, які можна виконати через SSH. Кожне містить (1) команду, (2) приклад виводу, (3) що означає вивід і (4) рішення, яке ви приймаєте далі.

Завдання 1: Переконайтесь, що ви в правильному корені WordPress

cr0x@server:~$ cd /var/www/example.com/public_html && ls -la
total 248
drwxr-xr-x  7 www-data www-data   4096 Dec 27 09:10 .
drwxr-xr-x  3 root     root       4096 Dec 20 11:02 ..
-rw-r--r--  1 www-data www-data    420 Nov  3 10:21 index.php
-rw-r--r--  1 www-data www-data  19935 Nov  3 10:21 wp-blog-header.php
-rw-r--r--  1 www-data www-data   3516 Nov  3 10:21 wp-config.php
drwxr-xr-x  9 www-data www-data   4096 Dec 10 12:01 wp-content
drwxr-xr-x  8 www-data www-data   4096 Nov  3 10:21 wp-admin
drwxr-xr-x 25 www-data www-data   4096 Nov  3 10:21 wp-includes

Значення: Наявність wp-config.php, wp-admin і wp-includes сильно вказує, що ви в правильному місці.

Рішення: Продовжуйте. Якщо ви не бачите цих файлів — зупиніться і знайдіть реальний document root. Відключення плагінів у неправильному каталозі — це спосіб «нічого не виправити» за годину.

Завдання 2: Визначте останні змінені директорії плагінів (часто підозрювані)

cr0x@server:~$ cd /var/www/example.com/public_html/wp-content/plugins && ls -lt | head
total 64
drwxr-xr-x 12 www-data www-data 4096 Dec 27 09:02 some-plugin
drwxr-xr-x 10 www-data www-data 4096 Dec 27 08:58 cache-tool
drwxr-xr-x  8 www-data www-data 4096 Dec 10 12:00 seo-pack
drwxr-xr-x 15 www-data www-data 4096 Dec  1 15:22 woocommerce

Значення: Плагіни, оновлені нещодавно, піднімаються вгору списку. Ця мітка часу часто збігається з часом збоїв.

Рішення: Почніть з відключення найбільш недавно зміненого плагіна, що відповідає вікну змін.

Завдання 3: Відключити один плагін перейменуванням його директорії

cr0x@server:~$ mv /var/www/example.com/public_html/wp-content/plugins/some-plugin /var/www/example.com/public_html/wp-content/plugins/some-plugin.disabled

Значення: Відсутність виводу для mv — норма. Якщо команда видасть помилку, ви побачите проблеми з правами або відсутнім шляхом.

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

Завдання 4: Відключити всі плагіни перейменуванням каталогу plugins

cr0x@server:~$ cd /var/www/example.com/public_html/wp-content && mv plugins plugins.disabled && mkdir plugins

Значення: WordPress вважатиме всі плагіни відсутніми; створення порожньої директорії plugins уникне попереджень і збереже можливість майбутніх інсталяцій.

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

Завдання 5: Curl сайту і підтвердіть статус без кешу браузера

cr0x@server:~$ curl -sS -D- -o /dev/null https://example.com/ | head -n 12
HTTP/2 200
date: Sat, 27 Dec 2025 09:12:10 GMT
content-type: text/html; charset=UTF-8
cache-control: no-cache, must-revalidate, max-age=0
server: nginx

Значення: HTTP 200 свідчить, що веб-рівень і PHP відповідають. Заголовки також підказують, чи є кешування в грі.

Рішення: Якщо ви все ще бачите 500/502/503 — негайно перевірте логи. Якщо 200, але вміст не той, підозрюйте кешування або часткові збої.

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

cr0x@server:~$ sudo tail -n 60 /var/log/nginx/error.log
2025/12/27 09:03:44 [error] 22110#22110: *881 FastCGI sent in stderr: "PHP message: PHP Fatal error:  Uncaught Error: Call to undefined function some_plugin_init() in /var/www/example.com/public_html/wp-content/plugins/some-plugin/some-plugin.php:42
Stack trace:
#0 /var/www/example.com/public_html/wp-settings.php(453): include_once()
#1 /var/www/example.com/public_html/wp-config.php(92): require_once('...')
#2 /var/www/example.com/public_html/wp-load.php(50): require_once('...')
#3 /var/www/example.com/public_html/wp-blog-header.php(13): require_once('...')
#4 /var/www/example.com/public_html/index.php(17): require('...')
#5 {main}
  thrown" while reading response header from upstream, client: 203.0.113.10, server: example.com, request: "GET / HTTP/2.0"

Значення: Це явна вказівка: невизначена функція в файлі плагіна. Часто викликано відсутньою залежністю, частковим оновленням або несумісністю версії PHP.

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

Завдання 7: Перевірте місце на диску (повні диски викликають «випадкові» помилки PHP)

cr0x@server:~$ df -h /var/www
Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1        40G   39G  420M  99% /

Значення: 99% використання — це зона інцидентів. Оновлення можуть завершитися неудачею під час розпаковки, логи не можуть писатися, PHP сесії не зберігаються. Все стає хитким.

Рішення: Спочатку звільніть місце. Інакше ви «виправите» плагін, а через п’ять хвилин все знову впаде.

Завдання 8: Шукайте застряглий файл режиму обслуговування

cr0x@server:~$ ls -la /var/www/example.com/public_html/.maintenance
-rw-r--r-- 1 www-data www-data 55 Dec 27 09:01 /var/www/example.com/public_html/.maintenance

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

Рішення: Видаліть його, якщо ви не виконуєте активне оновлення.

cr0x@server:~$ rm -f /var/www/example.com/public_html/.maintenance

Завдання 9: Перевірте версію PHP щодо вимог плагіна

cr0x@server:~$ php -v
PHP 7.4.33 (cli) (built: Nov  8 2024 10:14:11) ( NTS )
Copyright (c) The PHP Group
Zend Engine v3.4.0, Copyright (c) Zend Technologies

Значення: Багато сучасних плагінів вимагають PHP 8.x. Якщо оновлення плагіна розраховано на PHP 8, а у вас 7.4 — фатали можуть виникнути миттєво.

Рішення: Якщо плагін вимагає новішу версію PHP — тримайте його відключеним і плануйте впорядковане оновлення PHP (або відкат версії плагіна). Не «швидко оновлюйте PHP» під час інциденту, якщо не любите довгі вечори.

Завдання 10: Перевірте власність/права файлів (неправильні оновлення часто лишають файли root-owned)

cr0x@server:~$ find /var/www/example.com/public_html/wp-content/plugins -maxdepth 2 -type f -name '*.php' -printf '%u %g %p\n' | head
root root /var/www/example.com/public_html/wp-content/plugins/some-plugin/some-plugin.php
www-data www-data /var/www/example.com/public_html/wp-content/plugins/seo-pack/seo-pack.php

Значення: Файл плагіна, власником якого є root у дереві, зазвичай належному www-data, свідчить, що хтось виконав оновлення як root (або інструмент розпаковки зробив це). WordPress потім може не змогти перезаписати або очистити файли.

Рішення: Виправте власність для проблемного плагіна або всього дерева (обережно), потім повторіть оновлення через належний механізм.

cr0x@server:~$ sudo chown -R www-data:www-data /var/www/example.com/public_html/wp-content/plugins/some-plugin.disabled

Завдання 11: Підтвердіть підключення до БД з конфігурації WordPress (без виводу секретів)

cr0x@server:~$ grep -E "DB_NAME|DB_USER|DB_HOST" /var/www/example.com/public_html/wp-config.php
define( 'DB_NAME', 'wpdb' );
define( 'DB_USER', 'wpuser' );
define( 'DB_HOST', '127.0.0.1' );

Значення: Ви перевіряєте хост БД і що дивитесь на правильний конфіг для цього сайту.

Рішення: Якщо симптом нагадує відмову БД («Error establishing a database connection»), протестуйте сервіс БД далі.

Завдання 12: Перевірте стан MySQL/MariaDB на хості

cr0x@server:~$ sudo systemctl status mariadb --no-pager | sed -n '1,12p'
● mariadb.service - MariaDB 10.6.16 database server
     Loaded: loaded (/lib/systemd/system/mariadb.service; enabled; vendor preset: enabled)
     Active: active (running) since Sat 2025-12-27 08:10:03 UTC; 1h 2min ago
       Docs: man:mariadbd(8)
             https://mariadb.com/kb/en/library/systemd/
   Main PID: 982 (mariadbd)
     Status: "Taking your SQL requests now..."

Значення: БД працює. Це не доводить, що запити швидкі, але виключає «БД впала» зі списку причин.

Рішення: Якщо сайт все ще не працює, поверніть увагу до PHP, плагінів і кешування.

Завдання 13: Знайдіть фатал плагіна в PHP-логах (якщо окремі)

cr0x@server:~$ sudo tail -n 60 /var/log/php8.1-fpm.log
[27-Dec-2025 09:03:44] WARNING: [pool www] child 22134 said into stderr: "PHP Fatal error:  Uncaught Error: Call to undefined function some_plugin_init() in /var/www/example.com/public_html/wp-content/plugins/some-plugin/some-plugin.php:42"

Значення: Підтверджує, що фатал на рівні PHP-FPM, а не лише припущення Nginx.

Рішення: Тримайте плагін відключеним і виправляйте корінь несумісності (версія плагіна, залежність, версія PHP).

Завдання 14: Переконайтесь, що WordPress відповідає локально (обійти CDN/DNS)

cr0x@server:~$ curl -sS -H 'Host: example.com' http://127.0.0.1/ | head -n 5
<!doctype html>
<html lang="en-US">
<head>
<meta charset="UTF-8">

Значення: Сервер-джерело рендерить HTML локально. Якщо зовнішні користувачі все ще бачать помилки, проблема може бути в кеші CDN, правилах WAF або health-check балансувальника.

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

Завдання 15: Використайте WP-CLI для переліку плагінів (якщо можливо)

cr0x@server:~$ cd /var/www/example.com/public_html && sudo -u www-data wp plugin list
+-------------------+----------+-----------+---------+
| name              | status   | update    | version |
+-------------------+----------+-----------+---------+
| seo-pack          | inactive | none      | 3.2.1   |
| cache-tool        | inactive | available | 2.9.0   |
| some-plugin       | inactive | none      | 1.4.0   |
+-------------------+----------+-----------+---------+

Значення: Ви бачите, що активне/неактивне і які є оновлення. Після перейменування папки WP-CLI може показати плагін як відсутній або неактивний залежно від стану.

Рішення: Використовуйте WP-CLI для обережного повторного увімкнення плагінів пізніше, по одному, спостерігаючи логи.

Завдання 16: Чисто деактивуйте плагін за допомогою WP-CLI

cr0x@server:~$ cd /var/www/example.com/public_html && sudo -u www-data wp plugin deactivate some-plugin
Plugin 'some-plugin' deactivated.
Success: Deactivated 1 of 1 plugins.

Значення: Тепер WordPress погоджується, що плагін неактивний. Це чистіше, ніж перейменування директорії, коли ви маєте можливість його виконати.

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

Завдання 17: Перевірте автозавантажені опції, що виросли (поширена причина «все дуже повільно»)

cr0x@server:~$ cd /var/www/example.com/public_html && sudo -u www-data wp db query "SELECT option_name, LENGTH(option_value) AS bytes FROM wp_options WHERE autoload='yes' ORDER BY bytes DESC LIMIT 10;"
+---------------------------+--------+
| option_name               | bytes  |
+---------------------------+--------+
| some_plugin_cache_blob    | 524288 |
| rewrite_rules             | 182944 |
| wp_user_roles             |  32768 |
+---------------------------+--------+

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

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

Завдання 18: Швидко перевірте ліміт пам’яті PHP (симптом: білий екран або “Allowed memory size exhausted”)

cr0x@server:~$ php -r 'echo ini_get("memory_limit").PHP_EOL;'
128M

Значення: 128M може бути замало для важких плагінів/будівників сторінок. Але підняття пам’яті — це пластир, а не діагноз.

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

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

Цей розділ створений, щоб майбутній ви уникнув повторного інциденту. Це не теоретично; це відбувається тому, що WordPress — купа добрих намірів і include PHP.

1) Симптом: «Я перейменував папку плагіна, але нічого не змінилося»

Корінь проблеми: Ви редагували неправильний екземпляр WordPress (неправильний docroot), або job деплойменту відновив папку, або сайт обслуговується з іншого вузла.
Виправлення: Підтвердьте docroot (Завдання 1), підтвердьте локальний curl (Завдання 14) і перевірте, чи у вас балансування навантаження. Вносьте зміни на реальному origin або на всіх вузлах.

2) Симптом: «Сайт показує режим обслуговування назавжди»

Корінь проблеми: Застряглий файл .maintenance після невдалого оновлення.
Виправлення: Видаліть .maintenance (Завдання 8). Потім розберіться, чому оновлення впало (диск повний, права, тайм-аут).

3) Симптом: HTTP 502 Bad Gateway після оновлення плагіна

Корінь проблеми: PHP-FPM падає або тайм-аутиться через фатали, вичерпання пам’яті або довгі запити, спричинені плагіном.
Виправлення: Перегляньте Nginx error log і PHP-FPM лог (Завдання 6, 13). Відключіть плагін; потім виправляйте ресурси PHP або код.

4) Симптом: wp-admin завантажується, але збереження налаштувань дає 500

Корінь проблеми: Плагін прив’язаний до POST-запитів адмінки і фатал відбувається лише на цьому шляху; або WAF блокує певні дані; або PHP max input vars/time.
Виправлення: Тримайте логи в режимі tail під час відтворення. Відключіть підозрілий плагін і повторіть. Якщо проблема лишається — перевірте WAF-логи і налаштування PHP.

5) Симптом: Все «вгору», але дуже повільно після оновлення плагіна

Корінь проблеми: Надміру великі автозавантажені опції, дорогі запити до БД або треш в object cache.
Виправлення: Перевірте розміри автозавантажених опцій (Завдання 17), перегляньте slow query log БД якщо є, і тимчасово відключіть кеш-плагіни для порівняння.

6) Симптом: Білий екран бачать тільки залогінені користувачі

Корінь проблеми: Плагін виконується лише для адмінки/панелі інструментів або для користувача; фатал приховано налаштуваннями виводу помилок.
Виправлення: Слідкуйте за логами під час доступу до wp-admin. Спочатку відключіть адмін-плагіни (безпека, редактори, будівники сторінок).

7) Симптом: Плагін не оновлюється, або оновлення «успішні», але повертаються

Корінь проблеми: Неправильна власність/права, або файли незмінні, або CI/деплой перезаписує дерево.
Виправлення: Перевірте власність (Завдання 10). Підтвердіть, чи файли WordPress керуються Git/деплоєм. Визначте один джерело істини: або система деплою, або WP updater, а не обидва.

8) Симптом: Ви виправили, а потім через кілька хвилин воно зламалось знову

Корінь проблеми: Автооновлення знову застосувало погану версію, cron знову щось ввімкнув, або кеш заповнився зламаним кодом з іншого вузла.
Виправлення: Тимчасово вимкніть автооновлення, перевірте cron-події і забезпечте, щоб усі вузли мали однаковий стан плагінів.

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

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

Середня компанія мала маркетинговий сайт на WordPress за CDN і керованим балансувальником навантаження. Сайт «упав» одразу після оновлення плагіна. Інженер на чергуванні зробив стандартне: SSH на сервер, перейменував папку підозрілого плагіна, оновив браузер.

Все ще падало. Та сама помилка 500.

Хибне припущення було тонким: вони вважали, що є один origin. Насправді було два. Один — старіший вузол, що лишився після міграції, все ще в пулі балансувальника. Плагін був відключений на вузлі, куди вони зашли (бо вони пам’ятали цей hostname), але трафік йшов до іншого вузла з зламаним кодом плагіна.

Вони довели це, зробивши curl до кожного вузла з Host-заголовком. Один вузол повернув 200, інший — 500. Після відключення плагіна на другому вузлі інцидент зник миттєво.

Пост-інцидентне виправлення було нудним і ефективним: видалити застарілі origin з пулу і документувати авторитетний інвентар. Також: перестати покладатися на «hostname, який ви пам’ятаєте». Продакшн не піклується про вашу пам’ять.

Міні-історія 2: Оптимізація, що обернулась проти підрядника

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

Потім прилетіло оновлення плагіна. Сайт почав видавати переривчасті 502. Не постійно — але достатньо, щоб довести до сказу. Плагін сам по собі не був єдиною причиною: кеш-слой кешував часткові помилкові відповіді й віддавав їх випадково. Тим часом демон object cache перезапускався під тиском пам’яті, викликаючи сплески запитів, поки кеші заново «прогріваються».

Команда спочатку намагалася «оптимізувати сильніше»: підвищити TTL кешу, додати виключення, частіше перезапускати сервіси. Це лише погіршило ситуацію, бо кожен перезапуск підсилював гуркіт незахищених запитів до PHP і БД.

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

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

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

Одного ранку оновлення плагіна пройшло в staging, але зламало продакшн — бо продакшн мав іншу мінорну версію PHP через забутий pin базового образу. Плагін використав фічу PHP, якої не було в проді. Миттєвий фатал.

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

Довгострокове виправлення: вирівняти базові образи staging/prod і додати пайплайн-чеки, що перевіряють паритет версії PHP. Та саме нудне правило — послідовні середовища і відрепетировані відкатні сценарії — зробило свою роботу.

Факти та історичний контекст (коротко, корисно, трохи сумно)

Факт 1: WordPress почався у 2003 як форк b2/cafelog, і його архітектура плагінів зростала разом з екосистемою — потужна, але без ізоляції.
Факт 2: Плагіни виконують PHP в процесі; немає межі ізоляції, як у моделі розширень браузера. Плагін може зламати ядро однією фатальною помилкою.
Факт 3: «White Screen of Death» став мемом WordPress, бо PHP-fatal часто давав порожній вихід, коли показ помилок вимкнений.
Факт 4: Автоматичні фонові оновлення для виправлень безпеки були введені, щоб зменшити лаг патчів, але вони також збільшили шанс того, що непідтримані зміни застосуються без нагляду.
Факт 5: Файл .maintenance існує спеціально, щоб уникнути несумісних станів під час оновлень, але він може застрягнути, якщо оновлення падає.
Факт 6: Багато відмов після «оновлення плагіна» насправді — це часткові розпакування через брак місця або проблеми з правами, що залишають відсутні класи PHP.
Факт 7: PHP 7.4 досяг кінця життєвого циклу в 2022, і плагіни поступово підвищують мінімальні вимоги, роблячи старі хостинг-стеки часовими бомбами.
Факт 8: WordPress зберігає «активні плагіни» в базі, але все одно перевіряє наявність файлів на диску, тому перейменування папки — надійний аварійний гальмо.
Факт 9: Несподівано поширений вбивця продуктивності — це роздута автозавантажена опція: її підхоплюють багато запитів і вона карає все однаково.

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

Чекліст 1: «Сайт зараз впав» (спочатку стабілізувати)

Захопіть симптом: HTTP-статус (200/500/502/503), повідомлення режиму обслуговування, білий екран, доступність wp-admin.
Перевірте логи: лог помилок вебсерверу і PHP-FPM на предмет фаталу у файлі плагіна.
Відключіть ймовірний плагін: перейменуйте його папку під wp-content/plugins.
Якщо не впевнені — відключіть усі плагіни: перейменуйте plugins на plugins.disabled і створіть порожню директорію plugins.
Видаліть застряглий режим обслуговування: видаліть .maintenance, якщо він є.
Перевірте через curl: підтвердіть HTTP 200 і базовий HTML від origin.
Підтвердіть вхід в wp-admin: якщо адмін працює, далі — контрольоване відновлення.

Чекліст 2: Контрольоване відновлення (не зламати знову)

Повертайте плагіни по одному: перемістіть одну папку назад (або активуйте через WP-CLI), потім тестуйте і дивіться логи.
Шукайте приховані помилки: тестуйте динамічні кінцеві точки (оформлення замовлення, контактна форма, пошук), а не лише головну сторінку.
Очищуйте кеші свідомо: page cache, object cache, CDN cache (в такому порядку). Спочатку підтвердіть правильність origin.
Тимчасово вимкніть автооновлення: забороніть системі повторно ввести погану версію.
Зберігайте докази: збережіть стек фаталу і версію плагіна; це знадобиться для відкату або підтримки вендора.

Чекліст 3: Профілактика (перетворіть біль на процес)

Тримайте staging в паритеті з production: та сама версія PHP, ті самі розширення, та сама кеш-стек.
Бекапи, відновлені на практиці: БД + uploads + код плагінів/тем, протестований відкат, а не просто «маємо бекапи».
Контроль змін для плагінів: плануйте оновлення, записуйте версії і уникайте «автооновлення всього», якщо немає м’язів для відкату.
Спостережливість: централізовані логи, читабельні error-логи і алерти на сплески 5xx і PHP-fatal.

Жарт #2: Найшвидший шлях вивчити внутрішню будову WordPress — це вихід плагіна. Другий за швидкістю — прочитати це до аварії.

FAQ

1) Якщо я перейменую папку плагіна, чи втрачу я налаштування плагіна?

Зазвичай ні. Більшість налаштувань плагіна живуть у базі даних. Перейменування лише не дозволяє коду завантажуватись. Деякі плагіни запускають рутини uninstall при деактивації; перейменування обходить це, що часто безпечніше під час відновлення.

2) Що робити, якщо wp-admin теж не працює і я не можу залогінитись?

Це нормально при фаталах плагіна, бо WordPress не може завантажитись. Використайте відключення через файлову систему (перейменування папки плагіна або plugins) або WP-CLI, якщо воно може запуститися.

3) Чи можна видалити папку плагіна?

Ні, перейменуйте її. Видалення руйнує докази і ускладнює відкат. Перейменування — зворотне і швидке.

4) Чи можна вимкнути плагін прямо в базі даних?

Можна, редагуючи опцію active_plugins, але це гострий інструмент. Якщо ви вже на SSH — перейменування папки безпечніше і швидше під тиском. Редагуйте БД тільки якщо розумієте серіалізовані PHP-масиви і маєте бекап.

5) Чому іноді відключення всіх плагінів не вирішує проблему?

Тому що плагін не був єдиною причиною. Поширені винуватці: застряглий .maintenance, зупинений PHP-FPM, заповнений диск, проблеми з підключенням до БД або фатали на рівні теми. Відключення плагінів — це тест, а не догма.

6) Я відключив плагін, але сайт все ще показує сторінку помилки. Що далі?

Перевірте, чи ви бачите кешовані помилкові відповіді (CDN/page cache). Підтвердіть локально від origin через curl. Потім очистіть кеші. Також упевніться, що ви змінили правильний вузол у балансуванні навантаження.

7) Як знайти, який плагін це зробив, якщо я не знаю?

Сортуйте директорії плагінів за часом модифікації (Завдання 2), потім перегляньте логи на предмет стека фаталу (Завдання 6). Якщо досі не зрозуміло — відключіть усі плагіни і вмикайте по одному, поки не відтвориться помилка.

8) Чи WP-CLI завжди безпечний під час інциденту?

Воно безпечне, якщо ви запускаєте його від імені правильного користувача і воно може завантажити WordPress. Якщо фатал відбувається до моменту bootstrap, WP-CLI також може впасти. Тримайте метод перейменування як запасний беззалежний варіант.

9) У чому різниця між 500 і 502 в цьому контексті?

500 часто означає, що вебсервер отримав відповідь, але це внутрішня помилка (або PHP згенерував фатал і сервер це відобразив). 502 часто означає, що зворотний проксі не отримав валідної відповіді від upstream PHP-FPM (падіння, тайм-аут, bad gateway). На практиці: перевіряйте логи в обох випадках.

10) Чи варто підвищувати ліміт пам’яті PHP, щоб це виправити?

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

Висновок: наступні кроки, що запобігають повторному болю

Щоб швидко відновити роботу: відключіть плагін, перейменувавши його папку (або весь каталог plugins), видаліть застряглий файл .maintenance, перевірте через curl і читайте логи, поки рядок фаталу не стане зрозумілим. Потім поверніть плагіни по одному, з відкритими логами, а не на відчуттях.

Наступні кроки, що дійсно змінюють ситуацію:

Припиніть рулетку автооновлень: плануйте оновлення і вимагавайте план відкату.
Зробіть staging відповідним продакшну: паритет версій PHP запобігає «працювало в staging» омані.
Поліпшіть спостережливість: централізовані логи і алерти на 5xx роблять загадкові збої короткими інцидентами.
Тренуйте відкат: найкращий час навчитися процедурам відновлення — не під час інциденту з впливом на дохід.

Схожі статті

WordPress застряг у режимі обслуговування: як безпечно видалити та запобігти повторенням