Критична помилка WooCommerce після оновлення: як безпечно відкотити й відновити

Якщо ви читаєте це, ваш магазин, ймовірно, щойно зіграв свою роль: рутинне оновлення, оновлення файлів — і раптом WordPress показує страшенне «There has been a critical error on this website.» Замовлення зупиняються. Оформлення не працює. Маркетинг починає «просто перевіряє».

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

Зміст

Що насправді означає «critical error» у світі WooCommerce

Це повідомлення — ввічлива оболонка WordPress навколо фатальної помилки PHP. Це не діагноз; це ремінь безпеки. WordPress ловить фатал, уникає виведення стек-трейсу на вашому вітринному сайті й показує сторінку «critical error». За нею зазвичай ховається одне з наступного:

• Оновлення плагіна ввело несумісність (версія PHP, версія WordPress, інший плагін, хуки теми).
• Оновлення теми (або кастомний код теми) викликає видалені функції WooCommerce.
• Часткове оновлення залишило файли несумісними: половина коду нова, половина — стара.
• Opcode-кеш (OPcache) віддає застарілий код, тоді як файлову систему вже оновлено.
• Мігрування бази даних запустилося й упало посеред виконання, залишивши схему або опції неконсистентними.
• Зміна на стороні сервера збіглася з оновленням: модулі PHP, права файлів, диск заповнений або пошкоджений автозавантажувач.

Коли йде мова про WooCommerce, є ще один нюанс: оновлення WooCommerce інколи включають міграції бази даних. Зазвичай вони безпечні та ідемпотентні, але «зазвичай» — не те, що CFO захоче почути.

Одна парафразована ідея від Werner Vogels (CTO Amazon): будуйте системи з припущенням, що речі будуть падати, а потім проектуйте так, щоб радіус ураження був малим і відновлення — рутинним.

План швидкої діагностики (що перевіряти першим/другим/третім)

Це порядок, який повертає вас у робочий стан найшвидше в реальному продакшені. Мета — не зрозуміти все. Мета — відновити оформлення замовлень, а потім робити криміналістику.

Перше: підтвердіть, що це PHP-фатал і зафіксуйте сигнатуру

• Перевірте лог помилок вебсерверу (Nginx/Apache) і лог PHP-FPM на предмет свіжого фатала в час інциденту.
• Шукайте верхній кадр стеку, що вказує на wp-content/plugins/ або wp-content/themes/.
• Якщо логи недоступні, увімкніть безпечне логування WordPress (в файл, не виводячи на екран).

Друге: усуньте змінні, відключаючи найімовірнішого винуватця

• Вимкніть перший плагін, що оновлювався останнім.
• Якщо невідомо, що змінилося, вимкніть усі плагіни через WP-CLI або перейменуйте каталоги плагінів.
• Переключіться на дефолтну тему (Storefront/Twenty Twenty-*), якщо фатал вказує на тему.

Третє: перевірте стан бази даних і чи виконувалися міграції

• Перевірте, чи WooCommerce пропонує оновлення бази даних, чи застрягли заплановані дії, чи пошкоджені опції/транзієнти.
• Підтвердіть з’єднання з БД та стан реплікації, якщо застосовано.
• Зробіть знімок/резервну копію перед натисканням будь-якої кнопки «оновити базу даних».

Коли зупинитися й відновити зі знімка

Якщо сайт падає й ви не можете ізолювати фатал за 15–30 хвилин, відновіть останній відомо робочий знімок. Потім налагоджуйте на staging. Героїчне налагодження в продакшені — шлях стати уроком для інших.

Спочатку стабілізуйте: зупиніть кровотечу, не погіршуючи ситуацію

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

• Заморозьте зміни: призупиніть деплої, вимкніть автооновлення, зупиніть «допомагаючих» колег від натискання кнопок.
• Збережіть докази: збережіть логи, скопіюйте стек-трейси, зафіксуйте версії.
• Захистіть замовлення: якщо оформлення не працює, але адмін доступний, розгляньте режим технічного обслуговування з чітким банером, а не 500 помилкою.
• Резервна копія зараз: навіть якщо у вас вже є бекапи, зробіть свіжий знімок перед відкатом. Можуть знадобитися замовлення, створені в період простою, або часткові міграції.

Короткий жарт №1: автооновлення — як «сюрприз-рефактор», який ви не планували — захоплює саме тих, хто на виклику.

Логи та сигнали, що мають значення (і ті, що брешуть)

Відмови WordPress — шумні. Потрібні чисті сигнали.

Високосигнальні артефакти

• Лог помилок вебсерверу: скаже, чи загинув PHP, чи були таймаути чи проблеми з upstream.
• Лог PHP-FPM: ловить фатали, перевитрати пам’яті та падіння воркерів.
• WordPress debug.log: може зафіксувати попередження плагінів і трасування фаталів, якщо увімкнено.
• Логи стану WooCommerce: іноді містять проблеми міграцій і збої REST.
• Лог бази даних: дедлоки, заповнений диск, пошкоджені таблиці.

Низькосигнальні відволікання

• Помилки в консолі браузера: корисні для проблем з JS-оформленням, але не для PHP-критичних помилок.
• Коефіцієнти HIT кешу: під час збою кеш може маскувати радіус ураження або продовжувати віддавати зламані сторінки.
• «У мене на машині працює»: локальні середовища рідко відповідають продакшену щодо розширень PHP, лімітів пам’яті чи прав доступу до файлів.

Одна повторювана хитрість: «critical error», що з’являється лише для деяких користувачів, може бути спричинений кешуванням сторінки, яке віддає закешовану сторінку помилки, або різними PHP-пулами/серверами з різним кодом. Ставте неконсистентність як проблему гігієни розгортання першою чергою.

Стратегія відкату: плагін/тема/ядро без пошкодження даних

Відкат — це не одне й те саме. Визначте, що ви відкачуєте і який стан потрібно зберегти.

1) Відкат плагіна (WooCommerce чи іншого)

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

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

2) Переключення теми для ізоляції фаталів на рівні теми

Тема, що викликає видалені шаблонні функції WooCommerce, — поширене явище після оновлень WooCommerce. Переключення на Storefront (або дефолтну тему WP) — хірургічний спосіб підтвердити участь теми. Ви можете тримати плагіни увімкненими й повернути оформлення, поки команда розробників виправляє тему.

3) Відкат ядра WordPress (рідко необхідно, але можливо)

Оновлення ядра можуть вивести на поверхню латентні несумісності. Відкат ядра ризикованіший, бо сумісність плагінів очікує рух уперед. Я вдаюся до цього лише якщо (a) інцидент явно почався з оновлення ядра, (b) середовище інше стабільне, і (c) у мене є відомий робочий знімок для відновлення.

4) Повне відновлення зі знімка

Для магазинів із суттєвим трафіком «повне відновлення» часто — найшвидший безпечний шлях, якщо у вас дисципліноване створення знімків. Відновіть код + базу даних до відомої робочої точки, підніміть сайт, потім відтворіть відсутні замовлення, якщо потрібно. Ключ — розуміти ваш Recovery Point Objective (RPO): скільки даних ви готові втратити.

Відновлення бази даних: як не перетворити PHP-помилку на подію, що вбиває дохід

Більшість «critical error» у WooCommerce — на рівні коду. База даних часто цілком у порядку. Не робіть її проблемою.

Що може піти не так з базою даних під час оновлення

• Дрейф схеми: створено нові колонки/таблиці, старий код їх не очікує (зазвичай нормально), або новий код очікує їх, але вони не були створені через невдалу міграцію.
• Пошкодження опцій: серіалізована опція оновлена з несумісною структурою; PHP фаталить при unserialize чи доступі по ключу.
• Завал Action Scheduler: WooCommerce використовує Action Scheduler для фонового опрацювання. Якщо він заблокований (DB locks, таймаути), сайт може поводитися дивно, хоча фронтенд лишається фізично доступним.
• Проблеми з набором символів/порівнянням: рідко, але оновлення можуть зробити строгіші SQL-моди, виявивши погані запити в розширеннях.

Правила безпеки бази даних під час відновлення

• Знімок перед натисканням «Run database update.» Завжди. Без винятків.
• Надавайте перевагу діагностичним запитам тільки для читання. Перевірте наявність таблиць, кількість рядків, останні записи замовлень.
• Не поспішайте з «repair tables». Іноді треба, але це також шлях знищити докази й створити нові проблеми.
• Розумійте, що саме включає ваш бекап. Деякі «бекапи» пропускають тимчасові або великі таблиці. Замовлення WooCommerce живуть у posts/postmeta (або в HPOS-таблицях, якщо ввімкнено). Переконайтеся, що ваш бекап охоплює те, що приносить вам дохід.

Практичні завдання: 12+ реальних команд, виводів і рішень

Ці завдання припускають, що у вас є SSH-доступ до сервера і стандартний стек Linux + Nginx/Apache + PHP-FPM + MySQL/MariaDB. Налаштуйте шляхи під вашу дистрибуцію. Кожне завдання містить: команду, приклад виводу, що це значить, і рішення.

Завдання 1: Підтвердити поточні симптоми інциденту (HTTP-статус та відповідь)

cr0x@server:~$ curl -I -s https://store.example.com/ | head
HTTP/2 500
date: Fri, 27 Dec 2025 10:11:22 GMT
content-type: text/html; charset=UTF-8
server: nginx

Що це означає: Це серверна помилка, а не просто зламаний ресурс чи помилка JS.

Рішення: Перейдіть одразу до логів сервера/PHP. Не витрачайте час на браузер.

Завдання 2: Знайти фатальну помилку в логах Nginx

cr0x@server:~$ sudo tail -n 60 /var/log/nginx/error.log
2025/12/27 10:11:19 [error] 22190#22190: *8841 FastCGI sent in stderr: "PHP message: PHP Fatal error:  Uncaught Error: Call to undefined function wc_get_logger() in /var/www/html/wp-content/plugins/some-gateway/inc/init.php:41
Stack trace:
#0 /var/www/html/wp-settings.php(453): include_once()
#1 /var/www/html/wp-config.php(90): require_once('...')
#2 /var/www/html/wp-load.php(50): require_once('...')
#3 /var/www/html/wp-blog-header.php(13): require_once('...')
#4 /var/www/html/index.php(17): require('...')
#5 {main}
  thrown in /var/www/html/wp-content/plugins/some-gateway/inc/init.php on line 41" while reading response header from upstream, client: 198.51.100.19, server: store.example.com, request: "GET / HTTP/2.0", upstream: "fastcgi://unix:/run/php/php8.1-fpm.sock:", host: "store.example.com"

Що це означає: Плагін платіжного шлюзу викликав функцію WooCommerce, яка не завантажена (або сам WooCommerce зламаний/відключений/частково оновлений).

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

Завдання 3: Перевірити останні зміни файлів/пакетів (що оновлювалося?)

cr0x@server:~$ ls -lt /var/www/html/wp-content/plugins | head
total 92
drwxr-xr-x 10 www-data www-data 4096 Dec 27 10:02 woocommerce
drwxr-xr-x  8 www-data www-data 4096 Dec 27 10:02 some-gateway
drwxr-xr-x  7 www-data www-data 4096 Nov 18 09:40 wp-mail-smtp

Що це означає: WooCommerce і шлюз були змінені одночасно — ймовірно, вікно оновлення.

Рішення: Вимкніть спочатку шлюз (швидко), потім перевірте, чи WooCommerce завантажується. Якщо все ще зламано — відкотіть WooCommerce.

Завдання 4: Швидко вимкнути плагін, перейменувавши каталог

cr0x@server:~$ cd /var/www/html/wp-content/plugins
cr0x@server:~$ sudo mv some-gateway some-gateway.disabled
cr0x@server:~$ curl -I -s https://store.example.com/ | head
HTTP/2 200
date: Fri, 27 Dec 2025 10:13:01 GMT
content-type: text/html; charset=UTF-8
server: nginx

Що це означає: Плагін шлюзу спричинив фатал. Сайт знову віддає сторінки.

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

Завдання 5: Перевірити, що endpoint оформлення повертає 200 (не тільки головна)

cr0x@server:~$ curl -I -s https://store.example.com/checkout/ | head
HTTP/2 200
date: Fri, 27 Dec 2025 10:13:19 GMT
content-type: text/html; charset=UTF-8
server: nginx

Що це означає: Маршрут checkout рендериться на рівні HTTP. Це не гарантія успішної оплати, але ви вже не в ямі.

Рішення: Перейдіть до функціональної валідації (додавання в кошик, розрахунок доставки, доступність методів оплати) і моніторингу логів.

Завдання 6: Якщо доступний WP-CLI, перерахувати плагіни й підтвердити активні

cr0x@server:~$ cd /var/www/html
cr0x@server:~$ sudo -u www-data wp plugin list --status=active
+-------------------+--------+-----------+---------+
| name              | status | update    | version |
+-------------------+--------+-----------+---------+
| woocommerce       | active | available | 9.3.2   |
| akismet           | active | none      | 5.3     |
| wp-mail-smtp      | active | none      | 4.3.1   |
+-------------------+--------+-----------+---------+

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

Рішення: Нічого більше не оновлюйте поки що. Зафіксуйте стан, потім вирішіть, чи варто піднімати WooCommerce вперед на staging.

Завдання 7: Увімкнути безпечне логування WordPress (без показу помилок на екрані)

cr0x@server:~$ sudo -u www-data wp config set WP_DEBUG true --raw
cr0x@server:~$ sudo -u www-data wp config set WP_DEBUG_LOG true --raw
cr0x@server:~$ sudo -u www-data wp config set WP_DEBUG_DISPLAY false --raw
cr0x@server:~$ sudo -u www-data wp config set SCRIPT_DEBUG false --raw

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

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

Завдання 8: Прочитати WordPress debug log і виявити попередні повідомлення

cr0x@server:~$ sudo tail -n 80 /var/www/html/wp-content/debug.log
[27-Dec-2025 10:13:25 UTC] PHP Warning:  Undefined array key "country" in /var/www/html/wp-content/plugins/woocommerce/includes/class-wc-countries.php on line 133
[27-Dec-2025 10:13:26 UTC] PHP Notice:  Function wpdb::prepare was called incorrectly. The query does not contain the correct number of placeholders. in /var/www/html/wp-includes/class-wpdb.php on line 1777

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

Рішення: Відстежуйте їх як технічний борг; пріоритезуйте попередження, що впливають на checkout/податки/доставку.

Завдання 9: Перевірити версію PHP і завантажені модулі (перевірка сумісності)

cr0x@server:~$ php -v
PHP 8.1.27 (cli) (built: Nov 20 2025 12:12:11) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.1.27, Copyright (c) Zend Technologies
    with Zend OPcache v8.1.27, Copyright (c), by Zend Technologies

Що це означає: У вас PHP 8.1 з OPcache. Деякі старі плагіни все ще ламаються тут, особливо через застарілі функції.

Рішення: Якщо падаючий плагін старий, простий відкат може не допомогти; можливо, потрібна версія від вендора з підтримкою PHP 8.1+.

Завдання 10: Граціозно очистити PHP-FPM, щоб скинути OPcache (якщо підозрюєте застарілий код)

cr0x@server:~$ sudo systemctl reload php8.1-fpm
cr0x@server:~$ sudo systemctl status php8.1-fpm --no-pager | head -n 12
● php8.1-fpm.service - The PHP 8.1 FastCGI Process Manager
     Loaded: loaded (/lib/systemd/system/php8.1-fpm.service; enabled; vendor preset: enabled)
     Active: active (running) since Fri 2025-12-27 08:03:10 UTC; 2h 10min ago
       Docs: man:php-fpm8.1(8)

Що це означає: Перезавантаження пройшло успішно; воркери перезапустяться граціозно й оновлять стан OPcache.

Рішення: Якщо проблеми зникли після перезавантаження, ваше «оновлення» могло бути проблемою когерентності кешу. Виправте процес деплоя, щоб перезавантажувати PHP-FPM після змін коду.

Завдання 11: Перевірити місце на диску (оновлення дивно падають при його нестачі)

cr0x@server:~$ df -h /var/www/html | tail -n 1
/dev/vda1        40G   39G  1.1G  98% /

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

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

Завдання 12: Підтвердити власність і права файлів (щоб уникнути часткових оновлень)

cr0x@server:~$ stat -c "%U:%G %a %n" /var/www/html/wp-content/plugins/woocommerce | head -n 1
www-data:www-data 755 /var/www/html/wp-content/plugins/woocommerce

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

Рішення: Виправте власність перед повторним оновленням; інакше ви підписуєтесь на повторні відключення.

Завдання 13: Перевірити підключення до MySQL і базову працездатність

cr0x@server:~$ mysqladmin -uroot -p ping
Enter password:
mysqld is alive

Що це означає: БД доступна й відповідає.

Рішення: Продовжуйте з цілеспрямованими запитами; не припускайте корупцію БД, якщо проблема була фаталом PHP.

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

cr0x@server:~$ mysql -uroot -p -e "USE wordpress; SELECT ID, post_date, post_status FROM wp_posts WHERE post_type='shop_order' ORDER BY ID DESC LIMIT 5;"
Enter password:
+-------+---------------------+------------+
| ID    | post_date           | post_status|
+-------+---------------------+------------+
| 81231 | 2025-12-27 10:05:41 | wc-pending |
| 81230 | 2025-12-27 09:58:10 | wc-completed |
| 81229 | 2025-12-27 09:41:03 | wc-processing |
| 81228 | 2025-12-27 09:30:55 | wc-failed |
| 81227 | 2025-12-27 09:22:14 | wc-completed |
+-------+---------------------+------------+

Що це означає: Замовлення є в період інциденту (pending/failed можуть бути очікуваними, якщо оформлення зламалося посеред потоку).

Рішення: Скоординуйтеся з підтримкою: ідентифікуйте клієнтів, яких це зачепило, і звірте платежі. Не очищайте «failed» замовлення, поки не зрозумієте поведінку шлюзу.

Завдання 15: Змінити тему через WP-CLI (швидка ізоляція)

cr0x@server:~$ sudo -u www-data wp theme list --status=active
+-----------+--------+---------+
| name      | status | version |
+-----------+--------+---------+
| my-theme  | active | 3.1.0   |
+-----------+--------+---------+
cr0x@server:~$ sudo -u www-data wp theme activate storefront
Success: Switched to 'Storefront' theme.

Що це означає: Ви можете обійти фатали теми, не торкаючись плагінів.

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

Завдання 16: Якщо WP-CLI недоступний, відключити всі плагіни перейменуванням каталогу plugins

cr0x@server:~$ cd /var/www/html/wp-content
cr0x@server:~$ sudo mv plugins plugins.off
cr0x@server:~$ sudo mkdir plugins
cr0x@server:~$ sudo chown www-data:www-data plugins

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

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

Завдання 17: Перевірити статус оновлення бази даних WooCommerce (підказка про backlog Action Scheduler)

cr0x@server:~$ sudo -u www-data wp option get woocommerce_db_version
9.3.2
cr0x@server:~$ sudo -u www-data wp option get woocommerce_version
9.3.2

Що це означає: Версія коду і версія БД збігаються. Це зменшує ймовірність того, що ви в напівміграційному стані.

Рішення: Зосередьтеся на сумісності розширень, а не на відновленні БД — якщо тільки не бачите відсутніх таблиць або застряглих фоновых задач.

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

Міні-історія 1: Аварія через хибне припущення

Компанія: середній ритейлер з WooCommerce-магазином, що має стабільний щоденний об’єм і кілька сезонних піків. У них був пристойний хостинг і команда. Не «move fast and break things», скоріше «рухаємося обережно й все одно ламаємося, але з нарадами».

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

У їхньому середовищі хост нещодавно оновив PHP з 7.4 до 8.1. Ніхто не пов’язав це зі сторінкою, бо сайт «працював» тижнями. Оновлення плагіна шлюзу ввело шлях коду з застарілою поведінкою, яку PHP 8.1 обробив суворіше. Не кожна сторінка стикалася з цим. Checkout — так, при певних умовах кошика.

Команда ганялася за шаблонами WooCommerce, потім за кешуванням, потім «можливо Stripe впав». Тим часом клієнти могли переглядати товари, але не платити — найдорожчий тип «майже працює». Остаточне виправлення було елементарним: відкотити плагін шлюзу й зафіксувати його версію, яку підтримує вендор.

Але важливіше було те, що змінили надалі: вони додали звіт про середовище перед оновленням (версія PHP, розширення, ліміти пам’яті) і перестали довіряти банерам сумісності як заміні тестів. Банери сумісності — маркетинг, не контракт.

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

Інша компанія, схожий стек. Їхній консультант з продуктивності налаштував агресивне кешування: full-page cache на краю, object cache в Redis, OPcache максимально ввімкнений, і процес деплоя, що «міняє тільки потрібне». Переклад: оновлення коду не перезавантажували PHP-FPM, бо «швидше».

Оновили WooCommerce. Файли змінилися. Edge-кеш очистився правильно. Але OPcache продовжував віддавати старий байткод для деяких файлів, тоді як нові файли лежали на диску для інших. Класичний split-brain між «що каже ФС» і «що реально виконує PHP». В результаті — фатал через відсутні методи класу, які насправді існували… у новому коді, а не в кешованому байткоді.

Вони спробували відкотити плагін, копіювавши старі файли назад. Це погіршило ситуацію, бо OPcache отримав хаотичну суміш старого й нового байткоду. Кожне оновлення давало новий сюрприз. Команда описувала це як «заселений привидами». Я описав це як «передбачувано, просто не для вас».

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

Урок: оптимізації, що уникають перезавантажень, працюють поки працюють. Коли ні — вони множать час простою.

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

Ця історія менш драматична — у тому й суть. B2B-продавець запускав WooCommerce з невеликим набором ретельно підібраних розширень. У них був staging, що копіював продакшен: та сама версія PHP, той самий object cache, та сама тема і передочищена копія продакшен-бази, оновлена щотижня.

Перед оновленнями вони виконували чеклист: знімок продакшену, оновлення staging, прогін невеликого тестового набору (login, add-to-cart, checkout з тестовим шлюзом, редагування замовлення в адмінці), потім планували оновлення продакшену в низький трафік. Нічого фантастичного. Просто послідовно.

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

«Економія» була не лише в уникненні простою. Це було уникнення податку паніки: екстрені наради, нічні відновлення і поступова втрата довіри клієнтів. Їхня практика була нудною — тому й працювала. Більшість надійності — нудна. Ось чому вона рідкісна.

Цікаві факти та історичний контекст

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

1. WooCommerce починався як плагін від WooThemes і пізніше став частиною екосистеми Automattic, що вплинуло на ритм релізів і патерни інтеграції.
2. WordPress ввів екран «critical error», щоб зменшити витік інформації від фаталів і направляти адміністраторів через email-посилання для відновлення, змінивши спосіб налагодження з «white screen» на лог-орієнтований відгук.
3. Епоха «White Screen of Death» була не просто драмою — часто це були фатали PHP з display_errors вимкненим, що змушувало адміністраторів вчитися працювати з логами перш за все.
4. WooCommerce використовує Action Scheduler (його ж використовують й інші плагіни) для фонового опрацювання; коли він забивається, симптоми виглядають як «WooCommerce зламався», хоча фронтенд може рендеритися.
5. PHP 8.x посилив поведінку щодо нотисів і застарілих конструкцій, тож плагіни, що «працювали роками», можуть раптово впасти після оновлення сервера навіть без оновлення коду.
6. Оновлення WordPress звичайно атомарні на рівні пакета, а не файлової системи; якщо диск заповнюється посеред оновлення, можна отримати неповні каталоги й відсутні файли.
7. OPcache створив новий клас відмов: застарілий байткод після деплоя, якщо не перезавантажити воркерів.
8. WooCommerce розвивав модель зберігання даних з часом (включаючи опційний high-performance order storage); міграції можуть бути безпечні, але все одно потребують плану відкату.

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

Цей розділ навмисно конкретний. Загальні поради — як отримувати повторні інциденти.

1) Симптом: «Critical error» одразу після оновлення платіжного/доставного розширення

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

Виправлення: Вимкніть розширення, перейменувавши його каталог. Відновіть сайт. Потім встановіть сумісну версію на staging і знову увімкніть.

2) Симптом: Сайт працює на одному сервері, але не на іншому (за балансувальником)

Корінна причина: Частковий реліз по вузлах, несумісні файли плагінів або різний стан PHP-FPM/OPcache.

Виправлення: Перевірте версії релізів на всіх вузлах, потім перезавантажте PHP-FPM скрізь. Використовуйте атомарні деплої та узгоджене очищення кешів.

3) Симптом: Адмін панель працює, фронтенд 500s

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

Виправлення: Переключіться на Storefront; якщо це виправляє — виправляйте шаблонні перевизначення. Якщо ні — відключіть спочатку фронтенд-орієнтовані плагіни (кешування, оптимізації, конструктора сторінок).

4) Симптом: «Critical error» з’являється, потім зникає через кілька хвилин

Корінна причина: Невідповідність кешів, поступове очищення OPcache, завершення фонової задачі або поступові рестарти.

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

5) Симптом: Екран оновлень зависає; після цього сайт зламаний і файли відсутні

Корінна причина: Диск заповнений, неправильні права або мережеве переривання посеред оновлення, що призвело до неповних файлів плагінів/ядра.

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

6) Симптом: Оформлення завантажується, але платежі не проходять або замовлення застрягли в pending

Корінна причина: Плагін шлюзу вимкнений/відкатаний, змінені webhook-ендпоінти або backlog Action Scheduler, що заважає завершенню замовлень.

Виправлення: Перевірте статус плагіна шлюзу й логі webhook-ів; перегляньте черги Action Scheduler; звірте pending-замовлення з логами платіжного провайдера.

7) Симптом: Після відкату WooCommerce знову просить виконати оновлення бази даних

Корінна причина: Несумісність коду й БД; відкат коду повернув старий код, але версія БД залишилась новішою, або оновлення не завершилося.

Виправлення: Відновіть знімок БД, що відповідає коду, або підніміть код до версії, яка відповідає БД. Не робіть постійних «вгору-вниз» версій; оберіть консистентну пару.

Контрольні списки / покроковий план (безпечний для продакшену)

Чеклист реагування на інцидент (перші 30 хвилин)

1. Підтвердити вплив: перевірити головну сторінку + checkout + адмінку. Зберегти HTTP-статус.
2. Заморозити зміни: призупинити автооновлення і деплої поки не стабілізуєтеся.
3. Забрати сигнатуру фаталу: логи вебсерверу + PHP-FPM навколо часу інциденту.
4. Зробити знімок зараз: файлову систему + базу даних, навіть якщо плануєте відкат.
5. Вимкнути останній змінений плагін: перейменуйте каталог; повторно протестуйте.
6. Якщо неясно: вимкніть усі плагіни; повторно протестуйте; потім поступово повертайте плагіни.
7. Якщо підозра на тему: переключіть на Storefront; повторно протестуйте checkout.
8. Координація очищення: перезавантажте PHP-FPM (OPcache), обережно очистіть full-page cache.
9. Перевірити замовлення: переконатися, що створення замовлень працює; виявити застряглі статуси.
10. Комунікація: статус-сторінка/внутрішні комунікації: що зламалося, що пом’якшено, що далі.

Чеклист безпечного відкату (орієнтований на плагіни)

1. Зафіксуйте версію плагіна перед відкатом (з README у каталозі або через WP-CLI).
2. Перевірте вільне місце на диску й права файлів.
3. Вимкніть плагін (перейменуйте каталог), щоб швидко відновити сервіс.
4. Відновіть попередню версію плагіна з вашого артефактного сховища/бекапу (не з випадкових копій).
5. Перезавантажте PHP-FPM, щоб уникнути застарілого OPcache.
6. Увімкніть плагін і протестуйте критичні потоки у контрольованому режимі.
7. Моніторьте логи 15–30 хвилин після відновлення.

Чеклист безпечного відновлення (повне відновлення зі знімка)

1. Визначте останню відому добру точку відновлення та час початку простою.
2. Вирішіть RPO: чи погоджуєтеся втратити замовлення між точкою відновлення і зараз?
3. Експортуйте замовлення, створені після точки відновлення, якщо можливо (або плануйте ручну звірку).
4. Відновіть знімок бази даних першим (або в консистентній парі з файловою системою).
5. Відновіть файлову систему (wp-content, і ядро, якщо ви його знімали) відповідно до БД.
6. Перезавантажте PHP-FPM і вебсервер.
7. Перевірте end-to-end оформлення замовлення з тестовими транзакціями.
8. Зіставте замовлення/платежі за відсутній період.

Короткий жарт №2: Єдине гірше, ніж відсутність бекапу — виявити, що ваш «бекап» — мотиваційний постер з іконкою ZIP.

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

Після відновлення велике бажання — видихнути й рухатися далі. Втримайтеся. Відновлення без профілактики — просто планування наступного простою.

1) Проводьте оновлення в staging, яке реально відповідає продакшену

Staging, що працює на PHP 7.4, а продакшен — на 8.1, не є staging. Це театр. Узгодьте:

• версію PHP і розширення
• движок/версію БД і SQL-мод
• поведінку object cache (Redis/Memcached)
• налаштування OPcache
• тему і must-use плагіни

2) Ставтеся до оновлень WooCommerce як до «релізів застосунку»

WooCommerce — не плагін контактної форми. Це ваш двигун доходу. Отже:

• вікна технічного обслуговування для великих оновлень
• рев’ю чек-листів змін як release notes, а не як розсилку
• плани відкату і роллафорварду задокументовані
• післяоновлювальні скрипти перевірки (smoke tests) виконуються щоразу

3) Контролюйте дрейф версій і припиніть рулетку плагінів

Занадто багато магазинів працюють як «ринок плагінів» у продакшені: 40+ плагінів, кожен зі своїм графіком і якістю підтримки. Рівень відмов передбачуваний. Зменшіть його:

• видаляйте плагіни, які не потрібні категорично
• надавайте перевагу добре підтримуваним вендорам із чіткими заявами про сумісність
• фіксуйте версії й оновлюйте пакетами з відомими робочими комбінаціями

4) Зробіть деплої атомарними й усвідомленими щодо кешу

Якщо ви оновлюєте код, потрібно контролювати:

• Атомарність файлової системи: деплой у новий каталог, потім переключення симлінка, або інший спосіб уникнути часткових станів файлів.
• Консистентність OPcache: перезавантажуйте PHP-FPM після деплоя або використовуйте безпечний механізм інвалідації кешу.
• Очищення edge/full-page кешу: очищуйте після деплоя, а не перед ним, і уникайте кешування відповідей з помилками.

5) Моніторте правильні речі

Якщо ви моніторите лише «HTTP 200 на головній», пропустите дорогі збої. Моніторте:

• коефіцієнт успішності checkout endpoint
• частоту створення замовлень і завершення платежів
• кількість фатальних помилок PHP у логах (алерт на спайки)
• дедлоки/таймаути бази даних
• навантаження черг (Action Scheduler)

Питання й відповіді (FAQ)

1) Варто відкотити WooCommerce чи розширення, що оновилось?

Спочатку відкатайте (або вимкніть) розширення, якщо стек-трейс фаталу вказує на нього. WooCommerce — платформа; розширення — найпоширеніші винуватці. Якщо фатал у файлах ядра WooCommerce, розгляньте відкат WooCommerce або відновлення знімка.

2) Чи можна виправити «critical error», вимкнувши всі плагіни?

Так, і це часто найшвидший метод ізоляції. Це руйнівно, але повертає робочу адмінку. Потім вмикайте плагіни пакетами, поки помилка не з’явиться знову. Робіть це методично, а не емоційно.

3) Чому оновлення в адмінці пройшло успішно, а сайт зламався?

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

4) Чи потрібно запускати оновлення бази даних WooCommerce після оновлення?

Іноді так. Але зробіть знімок перед цим. Якщо ви вже відкотили код, не запускайте forward-міграції на відкатаному коді. Узгоджуйте версії коду й БД.

5) Якщо я не можу потрапити у wp-admin, як вимкнути плагіни?

Перейменуйте каталог плагінів через SSH (wp-content/plugins → plugins.off) або перейменуйте підозрілий каталог плагіна. Це змусить WordPress вважати плагіни неактивними без доступу до wp-admin.

6) Чи може кешування спричинити «critical error»?

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

7) Після вимкнення зламаного плагіна оформлення працює, але платежі ні. Що далі?

Це очікувано, якщо платіжний шлюз — зламаний плагін. Відновіть сервіс спочатку (навіть як «тільки перегляд»), потім підберіть сумісну версію шлюзу й перевірте webhook-и. Тим часом звірте pending-замовлення з логами платіжного провайдера.

8) Чи безпечно відновити тільки файли, а не базу даних?

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

9) Який найшвидший спосіб знайти проблемний плагін?

Стек-трейс фаталу зазвичай називає його. Шукайте шляхи під wp-content/plugins/ у логах. Якщо логів нема, вимкніть усі плагіни, потім включайте їх по одному, поки помилка не повернеться. Грубо, але надійно.

10) Чи залишати WP_DEBUG увімкненим після виправлення?

Ні. Вимкніть його (або принаймні логування), коли стабілізуєтесь, якщо немає ротації логів і вагомої причини. Логи ростуть, диски заповнюються. Заповнені диски — як «дрібні попередження» перетворюються на «серйозні відмови».

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

Якщо ваш WooCommerce-магазин показав критичну помилку після оновлення, виграшний хід — нудний і повторюваний:

1. Отримайте сигнатуру фаталу з логів сервера/PHP. Не гадати.
2. Вимкніть винуватця (зазвичай розширення), щоб швидко відновити сервіс.
3. Перезавантажте PHP-FPM, щоб уникнути OPcache-артефактів після змін коду.
4. Перевірте оформлення і запис замовлень, а не тільки головну сторінку.
5. Лише потім переходьте до глибшої роботи: відтворення в staging, фіксація версій і профілактика.

А завтра — коли ніхто не кричить — побудуйте запобіжні огорожі: staging, що нагадує продакшен, знімки перед оновленнями, атомарні деплої і моніторинг, який розуміє ваш бізнес (замовлення), а не лише сервери (ping). Ось як зробити оновлення WooCommerce знову нудними.