Тема WordPress зламала сайт: переключіть на дефолтну тему без wp-admin

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

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

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

І, звісно, wp-admin недоступний — бо те, що зламало сайт, це те саме, що wp-admin потребує для коректного відображення. Це не іронія. Це WordPress.

Що насправді відбувається, коли тема ламає WordPress

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

Звичайні механіки

Фатальна помилка в PHP теми (часто functions.php або вбудований фреймворк): PHP зупиняється і WordPress не може відрендерити ні фронтенд, ні адмінку.
Відсутні залежності: тема очікує плагін, розширення PHP або функцію з певної версії PHP.
Несумісність файлової системи: папку теми перейменовано, завантаження неповне, права неправильні або деплой залишив напівстаре/напівнове.
Шаблон вказує на тему, якої немає: WordPress зберігає вибір активної теми в базі даних; якщо вказано папку якої не існує, виникає хаос.
Кеш вас вводить в оману: кешована сторінка повертає стару робочу версію, тоді як адмінка все ще падає — або навпаки, саме так вас і розбудять о 02:13.

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

Цитата, яку варто запам’ятати, особливо коли хочеться поекспериментувати в продакшні: «Парафразована ідея» — Джин Кренц: будь жорстким і компетентним; тримай дисципліну під тиском.

Жарт №1: зламана тема — як погана стрижка — можна робити вигляд, що все нормально, але клієнти все одно помітять.

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

Якщо у вас є п’ять хвилин перед ескалацією, не блукайте. Запустіть цей план. Ви намагаєтеся відповісти на одне питання: Це помилка на рівні теми PHP, чи інфраструктурний вузький горлечко маскується під неї?

Перше: підтвердіть, що це саме тема, а не платформа

Перевірте логи вебсерверу на PHP fatal (Nginx/Apache + PHP-FPM). Якщо в трасі стеку є файл теми — діагностика завершена.
Перевірте HTTP-статус і тіло відповіді. 500 з «critical error» або порожній вивід сильно вказує на PHP fatal. 502/504 натякає на upstream (PHP-FPM) крах або таймаут, що може бути спричинено темою.
Перевірте статус PHP-FPM / slowlog. Тема може викликати безконтрольне навантаження CPU або рекурсію, поки не настануть таймаути.

Друге: перевірте вибір активної теми

Запитайте wp_options за template і stylesheet. Якщо вони вказують на директорію теми, якої немає, виправте це в першу чергу.
Перевірте встановлені теми через WP-CLI (якщо доступний). Якщо WP-CLI не може bootstrap’нутися, переходьте до редагування БД або перейменування файлів.

Третє: відновіть сервіс найменш інвазивним способом

WP-CLI: активуйте дефолтну тему (швидко, чисто, відкат можливий).
Відредагуйте БД: два параметри теми (працює навіть якщо PHP занадто зламаний для WP-CLI).
Перейменуйте теку зламаної теми (грубо, але змушує WordPress обрати fallback).

Правило рішення: якщо ви можете запустити WP-CLI без вильоту — використовуйте його. Якщо bootstrap WordPress вибухає — йдіть одразу в базу. Якщо у вас немає доступу до бази — перейменуйте файли теми. Не витрачайте 40 хвилин на «ще одну спробу», поки сайт лежить.

Цікаві факти та контекст (так, теми мають історію)

Вибір теми зберігається в базі даних: WordPress зберігає його в опціях з іменами template та stylesheet. Ось чому відсутня папка може вивести сайт з ладу.
Дефолтні теми «Twenty *» — не для краси: це підтримувальна база для сумісності та відновлення. Вони — еквівалент запасного колеса у WordPress.
WordPress додав механізм «захисту від фатальної помилки», який іноді може відключити зламаний плагін/тему та надіслати адміну листа. Це корисно, але не гарантовано — особливо якщо пошта не працює або помилка відбувається занадто рано.
Механізм дочірньої теми — це просто вказівки на директорії: «батько» вказується всередині style.css дочірньої теми. Відсутність батька може повалити всю тему.
Ранні екосистеми тем заохочували вбудовування всього підряд (власні фреймворки, конструктори сторінок). Саме тому сучасні збої тем часто виглядають як вибух залежностей.
WP-CLI існує тому, що керувати WordPress через веб-інтерфейс не масштабується. Воно вже давно є стандартом для SRE-процедур з WordPress.
Багато керованих хостів відключають прямі редагування файлів в адмінці заради безпеки. Плюс: менше самостійних помилок. Мінус: коли щось ламається, потрібні SSH/CLI навички.
Шари кешування можуть «зберегти» зламаний деплой на хвилини або години. Це робить інциденти заплутаними: деякі користувачі бачать робочий сайт, інші — звертаються до зламаного origin.

Перед тим як щось чіпати: доступи, резервні копії та захисні заходи

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

Що потрібно

SSH-доступ до сервера або контейнера з WordPress, або хоча б до shell на shared хостингу.
Доступ до бази даних (MySQL/MariaDB креденшали з wp-config.php або змінних середовища).
Встановлена відома хороша дефолтна тема (наприклад, twentytwentyfour, twentytwentythree). Якщо її немає і адмінка мертва — доведеться завантажити її вручну.
Достатні права для перейменування директорій у wp-content/themes або для запуску WP-CLI.

Запобіжні заходи, за які ви подякуєте собі

Знімок/резервна копія бази даних і wp-content перед змінами. Якщо немає можливості знімку — принаймні збережіть значення двох опцій перед редагуванням.
Менталітет «тільки читання» спочатку: підтвердіть, що активно, що є на диску, які помилки. Потім змініть одну річ.
Задокументуйте зміни (нотатка в тікеті, оновлення в чаті або локальний текстовий файл). Майбутнє «ви» — теж зацікавлена сторона.

Шлях A: виправлення через WP-CLI (найкращий варіант)

WP-CLI — найчистіший спосіб переключити активну тему, бо воно оновлює правильні опції і може перевірити, що встановлено. Хитрість: WP-CLI теж запускає bootstrap WordPress. Якщо фатальна помилка теми відбувається під час bootstrap, WP-CLI теж може впасти. Спробуйте все одно; якщо воно не вдасться, не боріться — змініть метод.

Як виглядає «успіх»

Ви можете виконати wp theme list без фатальної помилки.
Ви активуєте дефолтну тему і сайт повертається (навіть якщо непривабливий).
Ви підтверджуєте, що фронтенд і /wp-admin/ завантажуються.

Шлях B: виправлення через редагування бази даних (phpMyAdmin або CLI)

Якщо WordPress не може виконати достатньо PHP, щоб WP-CLI запустився, база даних — це ваша контрольна площина. WordPress читає ім’я активної теми з wp_options (або іншого префіксу), а потім завантажує відповідну директорію під wp-content/themes.

На практиці потрібно змінити дві опції:

template — ім’я директорії батьківської теми
stylesheet — ім’я директорії активної теми (дочірня тема, якщо використовується)

Встановіть обидві на назву дефолтної теми, наприклад twentytwentyfour. Якщо не впевнені, що встановлено — спочатку перелічіть директорії на диску.

Шлях C: виправлення переміщенням файлів теми (останній варіант, але ефективний)

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

Це не елегантно. Це ефективно. Операційна робота повна таких некомфортних істин.

Особливості Multisite та керованого хостингу

Multisite: теми, увімкнені для мережі, проти тем, активованих на сайті

У multisite теми «увімкнені» мережею, але окремі сайти вибирають, яку з увімкнених тем використовувати. Активна тема для кожного сайту зберігається в таблиці опцій цього сайту (наприклад, wp_2_options для site ID 2), якщо у вас немає незвичної мапи таблиць.

Правило рішення: якщо зламався тільки один сабсайт — редагуйте опції для цього blog ID, не головного сайту. Якщо вся мережа зламана — почніть з опцій головного сайту і перевірте, чи не причетний MU-плагін або мережеве налаштування.

Керований хостинг: обмежені shell-обліки та агресивний кеш

Деякі платформи дають WP-CLI, але не прямий MySQL CLI. Інші — phpMyAdmin, але без SSH. Деякі стоять за шарами кешу, які ігнорують ваші зміни, поки ви не очистите їх. Ваш метод залежить від доступних інструментів. Не будьте сентиментальними щодо інструментів.

Практичні завдання (12+): команди, результати та наступні рішення

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

Завдання 1: Переконайтеся, що ви на потрібному хості та в потрібній директорії

cr0x@server:~$ hostname -f; pwd; ls -la
wp01.prod.example.internal
/home/cr0x
total 32
drwxr-xr-x  4 cr0x cr0x 4096 Jan 12 09:10 .
drwxr-xr-x  3 root root 4096 Jan 10 18:22 ..
drwx------  2 cr0x cr0x 4096 Jan 12 09:10 .ssh
-rw-r--r--  1 cr0x cr0x  220 Jan 10 18:22 .bash_logout
-rw-r--r--  1 cr0x cr0x 3771 Jan 10 18:22 .bashrc
-rw-r--r--  1 cr0x cr0x  807 Jan 10 18:22 .profile

Що це означає: Ви не випадково оперуєте на staging або забутій віртуалці.

Рішення: Якщо хост неправильний — зупиніться. Якщо вірний — cd до WordPress docroot і працюйте звідти.

Завдання 2: Знайти корінь WordPress (docroot) швидко

cr0x@server:~$ sudo find /var/www -maxdepth 3 -name wp-config.php -print
/var/www/html/wp-config.php

Що це означає: Ви знайшли конфіг WordPress. Така директорія — майже завжди ваш root.

Рішення: cd /var/www/html і працюйте звідти.

Завдання 3: Перевірте, чи існують папки тем на диску

cr0x@server:~$ cd /var/www/html && ls -1 wp-content/themes
broken-agency-theme
twentytwentythree
twentytwentyfour

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

Рішення: Якщо дефолтної теми нема — можливо доведеться завантажити або встановити її через WP-CLI (якщо можливо) перед переключенням.

Завдання 4: Перевірте відповідь сайту і код стану від origin

cr0x@server:~$ curl -sS -D- -o /dev/null http://127.0.0.1/ | head
HTTP/1.1 500 Internal Server Error
Server: nginx
Date: Sat, 27 Dec 2025 10:42:18 GMT
Content-Type: text/html; charset=UTF-8
Connection: keep-alive

Що це означає: Це збій на стороні origin, не просто CDN-проблема. 500 вказує на PHP fatal або помилку додатку.

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

Завдання 5: Прочитайте лог вебсерверу, щоб знайти курильну зброю

cr0x@server:~$ sudo tail -n 30 /var/log/nginx/error.log
2025/12/27 10:42:17 [error] 22140#22140: *1047 FastCGI sent in stderr: "PHP message: PHP Fatal error:  Uncaught Error: Call to undefined function add_filter() in /var/www/html/wp-content/themes/broken-agency-theme/functions.php:19
Stack trace:
#0 /var/www/html/wp-settings.php(591): include()
#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/themes/broken-agency-theme/functions.php on line 19" while reading response header from upstream, client: 10.0.4.12, server: _, request: "GET / HTTP/1.1", upstream: "fastcgi://unix:/run/php/php8.2-fpm.sock:", host: "example.com"

Що це означає: Активна тема виконує код ще до повного завантаження WordPress або робить щось фундаментально неправильне. Трасування вказує на тему.

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

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

cr0x@server:~$ systemctl status php8.2-fpm --no-pager | sed -n '1,12p'
● php8.2-fpm.service - The PHP 8.2 FastCGI Process Manager
     Loaded: loaded (/lib/systemd/system/php8.2-fpm.service; enabled; vendor preset: enabled)
     Active: active (running) since Sat 2025-12-27 09:50:11 UTC; 52min ago
       Docs: man:php-fpm8.2(8)
   Main PID: 1183 (php-fpm8.2)
     Status: "Processes active: 2, idle: 6, Requests: 14321, slow: 0, Traffic: 0req/sec"

Що це означає: PHP-FPM працює. 500 скоріш за все рівень додатку, не мертвий бекенд.

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

Завдання 7: Спроба bootstrap WP-CLI (швидка перевірка здоров’я)

cr0x@server:~$ cd /var/www/html && wp core version
Error: PHP Fatal error:  Uncaught Error: Call to undefined function add_filter() in /var/www/html/wp-content/themes/broken-agency-theme/functions.php:19
Stack trace:
#0 /var/www/html/wp-settings.php(591): include()
#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-cli.php(134): require_once('...')
#4 /usr/local/bin/wp(4): include('...')
#5 {main}
  thrown in /var/www/html/wp-content/themes/broken-agency-theme/functions.php on line 19

Що це означає: WP-CLI не може запуститися, бо bootstrap WordPress завантажує зламану тему досить рано, щоб спричинити крах.

Рішення: Пропустіть WP-CLI для переключення. Використайте редагування БД або перейменування файлової системи.

Завдання 8: Витягніть креденшали БД з wp-config.php (не виводячи їх у scrollback)

cr0x@server:~$ cd /var/www/html && sudo sed -n "1,140p" wp-config.php | sed -n 's/.*DB_.*//p'

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

Рішення: Використайте безпечніший підхід: відкрийте файл у надійному редакторі локально або використайте вузькоспеціалізований grep і тримайте вивід приватним.

Завдання 9: Прочитайте префікс таблиць щоб не редагувати невірну таблицю

cr0x@server:~$ cd /var/www/html && grep -n "table_prefix" wp-config.php
78:$table_prefix = 'wp_';

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

Рішення: Використовуйте правильну назву таблиці. Вгадування — як «полагодити» нічого і втратити годину.

Завдання 10: Запитайте поточну активну тему в базі (спочатку лише читання)

cr0x@server:~$ mysql -u wpuser -p -h 127.0.0.1 wordpress -e "SELECT option_name, option_value FROM wp_options WHERE option_name IN ('template','stylesheet');"
Enter password:
+-------------+----------------------+
| option_name | option_value         |
+-------------+----------------------+
| template    | broken-agency-theme  |
| stylesheet  | broken-agency-theme  |
+-------------+----------------------+

Що це означає: WordPress явно налаштований використовувати зламану тему.

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

Завдання 11: Оновіть активну тему на дефолтну (фактичний фікс)

cr0x@server:~$ mysql -u wpuser -p -h 127.0.0.1 wordpress -e "UPDATE wp_options SET option_value='twentytwentyfour' WHERE option_name IN ('template','stylesheet'); SELECT option_name, option_value FROM wp_options WHERE option_name IN ('template','stylesheet');"
Enter password:
+-------------+------------------+
| option_name | option_value     |
+-------------+------------------+
| template    | twentytwentyfour |
| stylesheet  | twentytwentyfour |
+-------------+------------------+

Що це означає: База даних тепер вказує на twentytwentyfour.

Рішення: Повторно протестуйте сайт від origin. Якщо все ще падає — тема була не єдиною проблемою.

Завдання 12: Повторне тестування фронтенду і wp-admin від origin

cr0x@server:~$ curl -sS -D- -o /dev/null http://127.0.0.1/ | head -n 5
HTTP/1.1 200 OK
Server: nginx
Date: Sat, 27 Dec 2025 10:45:51 GMT
Content-Type: text/html; charset=UTF-8
Connection: keep-alive

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

Рішення: Перевірте /wp-admin/. Потім очистіть кеші, щоб користувачі перестали бачити застарілі помилки.

Завдання 13: Очистіть/зверніть загальні кеші (приклад серверного page cache)

cr0x@server:~$ sudo rm -rf /var/cache/nginx/*

Що це означає: Ви очистили кеш Nginx, якщо він використовується. Ваше середовище може відрізнятися.

Рішення: Якщо стоїте за реверс-проксі або CDN — також очистіть там через панель управління платформи.

Завдання 14: Якщо доводиться використовувати перейменування файлової системи (без доступу до БД)

cr0x@server:~$ cd /var/www/html/wp-content/themes && sudo mv broken-agency-theme broken-agency-theme.disabled

Що це означає: WordPress більше не може завантажити цю директорію теми.

Рішення: Перезавантажте сторінку. Якщо сайт повернувся — негайно встановіть валідну дефолтну тему через БД або WP-CLI, щоб не покладатися на неявний fallback.

Завдання 15: Підтвердіть, яку тему WordPress вважає активною (після відновлення)

cr0x@server:~$ mysql -u wpuser -p -h 127.0.0.1 wordpress -e "SELECT option_name, option_value FROM wp_options WHERE option_name IN ('template','stylesheet');"
Enter password:
+-------------+------------------+
| option_name | option_value     |
+-------------+------------------+
| template    | twentytwentyfour |
| stylesheet  | twentytwentyfour |
+-------------+------------------+

Що це означає: У вас явна стабільна конфігурація.

Рішення: Тепер можете відлагоджувати зламану тему офлайн або на staging.

Завдання 16: Увімкніть логування дебагу (коротко) щоб зловити залишкові помилки

cr0x@server:~$ cd /var/www/html && sudo grep -n "WP_DEBUG" wp-config.php
91:define('WP_DEBUG', false);
92:define('WP_DEBUG_LOG', false);
93:define('WP_DEBUG_DISPLAY', false);

Що це означає: Дебаг вимкнено, що нормально для продакшну.

Рішення: Якщо після переключення тем лишилися проблеми — тимчасово увімкніть WP_DEBUG_LOG і слідкуйте за wp-content/debug.log. Не вмикайте відображення помилок у продакшні.

Жарт №2: Увімкнення WP_DEBUG_DISPLAY у продакшні — це смілива стратегія, більшою мірою для людей, які люблять ділитися трасуваннями стеку з незнайомцями.

Контрольні списки / покроковий план

Чекліст для екстреного відновлення (ціль: 5–15 хвилин)

Підтвердіть симптом: фронтенд недоступний, адмінка недоступна, коди стану.
Перевірте логи на наявність файлу теми в трасі стеку.
Перелічіть встановлені теми на диску; підтвердіть наявність дефолтної теми.
Спробуйте WP-CLI (wp theme list). Якщо працює — активуйте дефолтну тему через WP-CLI.
Якщо WP-CLI не працює, відредагуйте опції в БД: встановіть template та stylesheet на дефолтну тему.
Повторно протестуйте від origin з curl: очікуйте 200.
Перевірте wp-admin (хоча б сторінку входу).
Очистіть кеші, які можуть продовжувати повертати помилки.
Повідомте статус: «Сервіс відновлено із запасною темою; розслідування триває.»

Стабілізація після відновлення (ціль: 30–90 хвилин)

Визначити точно, що змінилося (оновлення теми, оновлення PHP, оновлення плагіна, артефакт деплою).
Зберегти трасування фаталу і версію теми, яка його спричинила, у тікеті інциденту.
Відтворити в staging з тією ж версією PHP і набором плагінів.
Прийняти рішення: виправити тему, відкотити тему або замінити тему.
Додати перевірку перед деплоєм: чи може WordPress відрендерити /wp-login.php і домашню сторінку після зміни теми?

Профілактичні контролі (нудні, але ефективні)

Завжди тримайте як мінімум одну дефолтну тему Twenty встановленою.
Автоматизуйте бекапи БД і перевіряйте відновлення.
Використовуйте staging, який співпадає з продакшн-версією PHP.
Запускайте WP-CLI health команди в CI/CD (або хоча б на серверах деплою).
Відслідковуйте зміни тем і плагінів як код: журнал змін, схвалення, план відкату.

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

1) Симптом: порожня біла сторінка (фронтенд і адмін)

Корінна причина: Фатальна помилка PHP з відключеним відображенням помилок; код теми впав рано.

Виправлення: Перевірте Nginx/Apache + PHP-FPM логи. Переключіть тему через БД або WP-CLI. Потім дослідіть фатал у логах.

2) Симптом: «There has been a critical error on this website»

Корінна причина: Невпорядкована виняткова ситуація/фатал; режим відновлення WordPress може не запрацювати або лист не доходить.

Виправлення: Не чекайте листа від recovery. Примусово переключіть дефолтну тему; потім перевірте пошту і режим відновлення пізніше.

3) Симптом: 502/504 від проксі, періодична недоступність

Корінна причина: Тема викликає повільне виконання (безкінечний цикл, важкі запити), виснажуючи PHP-FPM воркери.

Виправлення: Переключіть на дефолтну тему і спостерігайте стабілізацію PHP-FPM. Потім профілюйте тему в staging; розгляньте slowlog.

4) Симптом: фронтенд працює, але /wp-admin/ зламаний

Корінна причина: Адмін завантажує інші шляхи коду; тема підключається до адмінки або завантажує зламані ресурси.

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

5) Симптом: після переключення сайт завантажується, але макет спотворений

Корінна причина: Специфічні віджети/налаштування кастомайзера і шорткоди теми не переносяться на дефолтну тему.

Виправлення: Прийміть це тимчасово. Ваша мета — відновлення сервісу. Заплануйте контрольований відкат теми або її виправлення.

6) Симптом: ви оновили `template`/`stylesheet`, але нічого не змінилося

Корінна причина: Невірний префікс таблиць, неправильна база даних, невідповідність blog ID у multisite або об’єктний кеш повертає застарілі опції.

Виправлення: Підтвердіть table_prefix, назву БД, а в multisite — wp_<blogid>_options. Скиньте object cache, якщо він використовується.

7) Симптом: директорія теми існує, але WordPress каже, що її немає

Корінна причина: Права/власник, різниця в регістрі імен, або артефакт розгортання зі симлінком.

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

8) Симптом: переключення теми викликає миттєві цикли перенаправлень

Корінна причина: Тема або плагін нав’язують канонічні URL або HTTPS неправильно; кеші підсилюють проблему.

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

Три корпоративні історії з практики

Інцидент через хибне припущення: «Це лише тема, що вона може зробити?»

Середня компанія вела маркетинговий сайт на стандартному стеці: Nginx, PHP-FPM, MariaDB. Маркетинг купив преміальну тему і запушив «невелике оновлення» прямо перед запуском кампанії. Ніхто не очікував драми, бо в їхній уяві теми — це «CSS та якісь шаблони».

Оновлення включало нову PHP-бібліотеку і почало викликати функції, доступні лише в новішій мінорній версії PHP. Продакшн відставав на одну версію, бо команда ops координувала велике вікно оновлення з кількома додатками. Тема не відпрацювала граціозно; вона кинула фатал під час ініціалізації і повалила фронтенд та wp-admin.

Початкова реакція була класичною: перезапустити PHP-FPM, перезапустити Nginx, очистити кеш. Це давало коливання, але не вирішувало проблему. Сайт повертався тимчасово, бо кешовані сторінки обслуговувались, потім знову падали, коли uncached URL доходили до PHP. Конфуз тривав, бо різні люди бачили різну поведінку залежно від того, які сторінки вони потрапляли.

Зрештою, фікс був простим: відредагувати wp_options, щоб активувати дефолтну тему Twenty. Сервіс повернувся миттєво. Лише потім команда помітила, що оновлення теми також включало авто-апдейт, який перезаписав деякі вбудовані ресурси під час деплою, залишивши реліз напівоновленим.

Після цього процес змінили: оновлення теми вимагало валідації на staging проти поточної продакшн-версії PHP, а не того, що вендор тестував минулого тижня. І дефолтна тема залишається встановленою назавжди. Корінна причина була не «погана тема», а хибне припущення, що теми нешкідливі.

Оптимізація, яка відкотилася: кеш, що приховав правду

У підприємства був агресивний стек кешування: реверс-проксі кеш, плагін кешу і CDN. Було швидко, і всі отримували за це похвалу. Потім кастомне реліз теми ввело фатал на певному шаблоні сторінки, який використовувався на головній.

Для деяких користувачів сайт виглядав нормально, бо CDN ще мав кешовану домашню сторінку. Для інших, особливо тих, хто потрапив на холодний edge або інший шлях локалізації, origin повернув 500. Інженери розділилися: «все ок» і «все впало», що чудовий спосіб втратити годину.

Моніторинг теж вводив в оману, бо endpoint перевірки був статичним URL, який залишався в кеші. Дашборд лишався зеленим, тоді як метрики доходів падали. Кеш не спричинив баг, але зробив інцидент важчим для виявлення, відтворення і довіри.

Знову фікс був нудним: переключити на дефолтну тему через БД, очистити кеші в правильному порядку (спочатку origin, потім CDN) і тимчасово змінити моніторинг, щоб обійти кеш. Після цього вони змінили health checks: додали uncached запит з busting заголовками і перевірку доступності адмінки окремо.

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

Нудна, але правильна практика, що врятувала день: дефолтна тема + відпрацьований відкат

Глобальна організація використовувала WordPress в рамках ширшої контентної платформи. Нічого фантастичного: заточені хости, управління конфігурацією, передбачувані релізи. Їхній рунабоr для зміни тем виглядав майже смішно строгим для «CMS-сайту».

Вони завжди тримали дві дефолтні Twenty теми. WP-CLI завжди доступний на хості. У них був готовий SQL-сніпет у рунабоці для перемикання template і stylesheet. І політика: релізи тем відбувалися в робочий час з людиною на чергуванні, яка могла SSH і зробити відкат.

Одного дня дочірня тема зламалася, бо ім’я директорії батьківської теми змінилося під час рефакторингу деплою. Це було типу помилки, яку легко зробити при прибиранні. Адмінка померла миттєво. Фронтенд повертав 500 на uncached сторінках.

Інженер на чергуванні виконав рунабоk: підтвердив фатал, встановив обидві опції на twentytwentyfour, очистив проксі кеш і оголосив про відновлення сервісу. Загальне порушення було коротким. Постмортем був теж нудним: додати перевірку в деплой, яка гарантує, що активна директорія теми існує і батьківська тема для дочірньої присутня.

Це не було героїчно. Це була послідовність. В операціях нудне часто — найвища форма компетентності.

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

1) Які значення в базі даних фактично контролюють активну тему?

template та stylesheet в таблиці опцій. Зазвичай wp_options, якщо префікс таблиці не відрізняється або ви не на multisite.

2) На що треба встановити `template` та `stylesheet`?

Встановіть обидва на ім’я директорії відомої доброї теми в wp-content/themes, наприклад twentytwentyfour. Ім’я директорії, а не відображуване ім’я теми.

3) Чи можна це виправити видаленням теми?

Можна, але перейменування безпечніше. Видалення знищує докази і ускладнює відкат. Перейменуйте директорію на theme-name.disabled і потім явно переключіться через БД.

4) WP-CLI падає з фаталом. Чи марний тоді WP-CLI?

WP-CLI залежить від bootstrap WordPress. Якщо активна тема падає під час bootstrap — WP-CLI теж може впасти. В таких випадках редагування БД виручає.

5) Я переключив тему в БД, але сайт все ще показує стару зламану сторінку. Чому?

Кешування. Очистіть серверний кеш, плагінний кеш, реверс-проксі кеш і CDN. Також перевірте object cache (Redis/Memcached), що може тримати застарілі опції.

6) Чи видалення теми видалить мій контент?

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

7) Що робити, якщо дефолтна тема не встановлена і адмінка недоступна?

Завантажте дефолтну тему до wp-content/themes з надійного джерела через SCP/SFTP або механізм деплою. Потім встановіть template/stylesheet на ім’я тієї директорії.

8) Як це працює на multisite?

Кожен сайт має свою таблицю опцій (наприклад, wp_2_options). Переключайте опції теми для ураженого blog ID. Також переконайтеся, що цільова тема увімкнена мережею.

9) Чи може плагін бути справжньою причиною, а не тема?

Так. Але якщо логи вказують на файли теми — спочатку переключіть тему, щоб відновити сервіс. Якщо проблема лишається після переключення теми — починайте послідовне відключення плагінів (краще через WP-CLI або БД).

10) Чи потрібно також оновлювати опції `theme_mods_*`?

Зазвичай ні для відновлення. Вони зберігають налаштування кастомайзера для конкретної теми. Не чіпайте їх, поки не стабілізуєтесь і не почнете розбиратися із чисткою даних чи переналаштуванням.

Висновок: наступні кроки, щоб уникнути повторення

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

Зробіть це далі, у порядку

Закріпіть відновлення: перевірте, що template/stylesheet вказують на дефолтну тему і що директорія існує на диску.
Збережіть докази: збережіть трасування фаталу і точну версію теми, що спричинила помилку.
Відтворіть безпечно: тестуйте зламану тему в staging з тією ж версією PHP і набором плагінів.
Прийміть довгострокове рішення: відкат теми, патч теми або заміна. Не домовляйтесь з темою, яка тримає продакшн у заручниках.
Додайте профілактику: тримайте дефолтну тему встановленою, додайте перевірку деплою на наявність директорії теми і зробіть health checks, що враховують кеш.

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