Оновлення WordPress ламає сайт частіше, ніж хотілося б: конфлікт версій, застарілий код у темі, несумісний плагін. Розбираємо порядок безпечного оновлення і спосіб відкотитися, якщо щось пішло не так.
Чому оновлення WordPress може зламати сайт
Ядро WordPress, плагіни і тема розвиваються незалежно одне від одного. Автор плагіна може використовувати функцію, яку розробники ядра позначили застарілою і видалили в новій версії, — сайт отримає білий екран одразу після оновлення. Тема, написана під WordPress 6.0, не зобов'язана працювати без помилок на WordPress 6.7.
Ризик зростає, якщо на сайті встановлено більше 15-20 плагінів або використовується застаріла версія PHP. Різниця між версією PHP на сервері і мінімальними вимогами нового плагіна — часта причина помилки 500 після оновлення; діагностика такої помилки описана в статті Білий екран і помилка 500 у WordPress: як знайти причину.
Підготовка: резервна копія перед кожним оновленням
Правило без винятків: оновлення без свіжої резервної копії — це ставка, а не робота. Копія повинна включати файли сайту і базу даних цілком, а не лише папку з темою. Порядок створення і відновлення копії описано в статті WordPress бекап: UpdraftPlus і ручний метод.
Перед запуском оновлення перевірте дату останньої резервної копії в панелі плагіна бекапу. Якщо копії більше доби — зробіть нову вручну, не покладаючись на розклад.
Порядок оновлення: плагіни, тема, ядро
Оновлюйте компоненти по черзі, а не разом через кнопку «Оновити все»:
- Спочатку плагіни — по одному, з перевіркою сайту після кожного.
- Потім дочірня або основна тема.
- В останню чергу — ядро WordPress.
Такий порядок звужує пошук винуватця до одного компонента, якщо сайт зламався. При оновленні одразу двадцяти плагінів пошук конфлікту займе години; при оновленні по одному — хвилини.
Оновлення через WP-CLI на сервері
З термінала оновлення проходить швидше і зручніше логується:
# Показати список плагінів з доступними оновленнями
wp plugin list --update=available
# Оновити один плагін
wp plugin update plugin-name
# Оновити ядро WordPress до останньої версії
wp core update
Повний список команд для керування оновленнями і резервними копіями з терміналу — у статті WP-CLI: керування WordPress з командного рядка. Команда wp core update сама створює точку відновлення бази перед міграцією схеми, але файловий бекап вона не робить — його треба готувати окремо.
Як перевірити сайт після оновлення
Відкривати бойовий сайт одразу після оновлення ризиковано. Правильний порядок — прогнати оновлення на staging-копії, а вже потім повторити його на продакшені; як підняти тестову копію, описано в статті Staging сайт для WordPress: тестове середовище без ризику.
Після оновлення перевірте щонайменше три речі: головну сторінку без помилок у консолі браузера, форму зворотного зв'язку або кошик, якщо є WooCommerce, і адмінку — вхід під адміністратором і збереження будь-якого запису.
Відкат: як повернути попередню версію
Якщо після оновлення сайт зламався, порядок дій такий:
| Що зламалося | Дія |
|---|---|
| Один плагін | Відкотити плагін через архів версій або відновити його файли з резервної копії |
| Тема | Відновити папку теми з резервної копії, ядро і плагіни не чіпати |
| Ядро WordPress | Відновити базу даних і файли цілком з резервної копії, зробленої перед оновленням |
Повний відкат сайту з архіву зазвичай швидший, ніж ручний підбір сумісної версії плагіна. Перевірочний список перед стартом кожного оновлення:
- Свіжа резервна копія файлів і бази даних не старша доби.
- Оновлення перевірено на staging-копії.
- Компоненти оновлюються по одному, не всі одразу.
- Після оновлення перевірено головну сторінку, форму й адмінку.