Як оновити WordPress, плагіни і теми безпечно і без втрати даних

Чому оновлення критично важливі

Оновлення WordPress — це не «ну, колись оновлю». Це питання безпеки і працездатності сайту. Ось чому:

Безпека — більшість зламів WordPress відбуваються через відомі вразливості у застарілих плагінах. Хакери не вигадують нових атак — вони використовують вразливості, для яких вже вийшов патч, але власник сайту його не встановив
Сумісність — нові версії PHP, нові браузери, нові стандарти. Застарілий WordPress може просто перестати працювати після оновлення PHP на хостингу
Функціональність — нові можливості, покращена швидкість, виправлені баги
SEO — Google знижує позиції сайтів з проблемами безпеки. Якщо Google Search Console виявить вразливість — ваші позиції обваляться

Детальніше про ризики — в статті чому виникають віруси на сайті і чекліст безпеки.

Типи оновлень: мінорні vs мажорні

Не всі оновлення однакові. Розуміння різниці допоможе оцінити ризик:

Мінорні оновлення (6.5.1 → 6.5.2)

Виправлення безпеки і багів. Мінімальний ризик конфліктів. Встановлюйте якнайшвидше — протягом 1-2 днів після виходу. WordPress за замовчуванням встановлює їх автоматично, і це правильно.

Мажорні оновлення (6.5 → 6.6)

Нові функції, зміни в API, можливі зміни в поведінці. Помірний ризик конфліктів з плагінами і темами. Зачекайте 3-7 днів після виходу — поки перші користувачі знайдуть проблеми і розробники випустять патчі. Обов'язково зробіть бекап перед оновленням.

Оновлення плагінів

Найчастіша причина поломок після оновлення. Один плагін оновився — інший перестав працювати. Оновлюйте по одному і перевіряйте сайт після кожного.

Оновлення теми

Якщо ви вносили зміни напряму у файли теми (а не через child theme) — оновлення перезапише ваші зміни. Це найчастіша причина «все зникло після оновлення». Завжди використовуйте дочірню тему для кастомізацій.

Потрібна консультація?

Безкоштовно розберу ваш проєкт і дам рекомендації

Що зробити перед оновленням

Чекліст перед будь-яким оновленням:

Повний бекап — файли + база даних. Не бекап тільки бази. Не бекап тільки файлів. Обидва. Перевірте що бекап можна відновити — завантажте і переконайтесь що архів не пошкоджений
Перевірте сумісність — прочитайте changelog оновлення. Зверніть увагу на «breaking changes». Перевірте чи ваші ключові плагіни підтримують нову версію WordPress
Перевірте версію PHP — нові версії WordPress можуть вимагати новішу PHP. Якщо хостинг на PHP 7.4 — спочатку оновіть PHP, потім WordPress
Вимкніть кешування — кеш-плагіни іноді створюють проблеми під час оновлення. Очистіть кеш і тимчасово деактивуйте кеш-плагін
Оберіть правильний час — не оновлюйте в п'ятницю ввечері або перед вихідними. Ідеальний час — ранок робочого дня, коли ви маєте кілька годин на виправлення можливих проблем
Повідомте команду — якщо над сайтом працюють кілька людей, попередьте що буде оновлення і щоб не редагували контент у цей час

Правильний порядок оновлень

Порядок має значення. Неправильна послідовність може створити конфлікти:

Крок 1: Бекап — повний, перевірений
Крок 2: Плагіни — оновлюйте по одному. Після кожного — перевірте фронтенд і адмінку. Якщо щось зламалось — відкотіть цей один плагін, а не все
Крок 3: Тема — оновіть тему (якщо є оновлення). Перевірте зовнішній вигляд на головній, внутрішніх сторінках і мобільній версії
Крок 4: WordPress ядро — оновіть саму систему. Перевірте все ще раз
Крок 5: Перевірка — пройдіться по ключових сторінках, перевірте форми, кнопки, кошик (для магазину), мобільну версію
Крок 6: Очистіть кеш — очистіть кеш плагіна, серверний кеш і CDN (якщо є)

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

Staging: тестування без ризику

Staging — це копія вашого сайту на окремому піддомені (наприклад, staging.example.com), де можна тестувати оновлення без ризику для робочого сайту.

Процес:

Створіть копію сайту на staging
Оновіть все на staging
Перевірте що нічого не зламалось
Якщо все ок — повторіть оновлення на робочому сайті
Якщо щось зламалось — виправте на staging, потім оновлюйте робочий

Багато хостинг-провайдерів пропонують staging одним кліком. Якщо хостинг не підтримує — можна створити вручну через клон бази і файлів на піддомен.

Staging обов'язковий для інтернет-магазинів, сайтів з великим трафіком і кастомних розробок. Для простого блогу або сайту-візитки зазвичай достатньо бекапу + обережного оновлення.

Автоматичні оновлення: вмикати чи ні

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

Мінорні оновлення ядра — увімкнути (безпека, мінімальний ризик). Увімкнені за замовчуванням
Мажорні оновлення ядра — вимкнути. Занадто ризиковано для автоматичного оновлення без перевірки
Плагіни безпеки (Wordfence, Sucuri) — увімкнути автооновлення. Для них критично бути актуальними
Решта плагінів — залежить від ситуації. Для простих сайтів з надійними плагінами — можна увімкнути. Для складних сайтів з кастомними плагінами — краще вручну
Тема — вимкнути, особливо якщо тема кастомізована

Золоте правило: автооновлення + щоденний бекап = прийнятний ризик для простих сайтів. Для складних проєктів — тільки ручні оновлення з тестуванням.

Що робити якщо сайт зламався

Не панікуйте. У 90% випадків проблема вирішується за 15-30 хвилин:

Білий екран (White Screen of Death)

Найчастіша проблема. Зайдіть на хостинг через файловий менеджер або FTP. Перейменуйте папку /wp-content/plugins/ на /wp-content/plugins-old/. Якщо сайт ожив — проблема в плагіні. Перейменуйте назад і вимикайте плагіни по одному, поки не знайдете винуватця.

Помилка підключення до бази даних

Перевірте wp-config.php — чи правильні дані підключення до бази. Іноді оновлення хостингу змінює параметри бази. Перевірте чи працює MySQL на хостингу.

Помилка 500

Перевірте .htaccess — перейменуйте його і створіть новий через Налаштування → Постійні посилання в адмінці. Якщо адмінка недоступна — створіть стандартний .htaccess вручну.

Нічого не допомогло

Відновіть з бекапу. Саме тому бекап перед оновленням — обов'язковий крок. Якщо бекапу немає — зверніться до фахівця. Не намагайтесь «полагодити» навмання — можете зробити гірше.

Часті запитання

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

Для плагінів — так, через плагін WP Rollback. Для ядра WordPress — технічно складніше, найпростіше відновити з бекапу. Тому бекап перед оновленням — не рекомендація, а обов'язковий крок.

Це червоний прапорець. Плагін, який не оновлювався 12+ місяців, скоріш за все має невиправлені вразливості і може бути несумісний з новими версіями WordPress і PHP. Шукайте альтернативу або зверніться до розробника для заміни функціоналу кастомним рішенням.

Технічно — так, через мобільний браузер. Практично — не робіть цього. Якщо щось піде не так, вам потрібен буде доступ до FTP або файлового менеджера хостингу, що незручно з телефону. Оновлюйте з комп'ютера, коли маєте час на перевірку.

Якщо робите самостійно — безкоштовно, тільки ваш час. Якщо делегуєте фахівцю — від 1 000 до 5 000 грн/міс за регулярну підтримку (оновлення, бекапи, моніторинг, дрібні правки). Детальніше в статті про підтримку сайту.

Висновок

Оновлення WordPress — це не складна процедура, але вона потребує дисципліни. Бекап → плагіни по одному → тема → ядро → перевірка — і ваш сайт в безпеці. Ігнорування оновлень місяцями — це накопичення технічного боргу, який рано чи пізно обвалиться.

Для простих сайтів: автооновлення + щоденні бекапи. Для складних проєктів: staging + ручні оновлення з тестуванням.

Не хочете займатися оновленнями самостійно? Замовте технічну підтримку — буду оновлювати, робити бекапи і моніторити безпеку вашого сайту. А якщо сайт вже зламався — допоможу з видаленням вірусів і відновленням.