Безпечне оновлення WordPress: ядро, плагіни, теми — під ключ

Застаріле ядро WordPress та плагіни — основна причина зламів: за даними Sucuri, до 70% атак використовують вже виправлені вразливості. Більшість вебмайстрів бояться натискати «оновити» через ризик зламати сайт. Ми регулярно стикаємося з проєктами, де неправильне оновлення призвело до простою або втрати даних. Наш підхід — мінімізація ризиків за рахунок попереднього бекапу, тестування на staging та моніторингу. За понад 7 років ми оновили понад 200 сайтів різної складності — від лендінгів до кастомних рішень на WooCommerce та Elementor. Жодного збою на production.

Як оновити WordPress без ризику?

Оновлення в production без підготовки — прямий шлях до простою. Правильний порядок включає п'ять етапів: створення повного бекапу, тестування на staging, перевірка сумісності, застосування на бойовому сайті та пост-моніторинг. Нижче розберемо кожен крок з конкретними командами.

Бекап — єдина страховка

Перед будь-яким оновленням архівуємо файли та дамп бази даних. Використовуємо утиліти командного рядка та WP-CLI:

# Повний бекап файлів та БД
tar czf backup-$(date +%Y%m%d).tar.gz /var/www/yourdomain.com
mysqldump -u root wordpress > backup-$(date +%Y%m%d).sql

# Через WP-CLI
wp db export backup.sql --add-drop-table

Важливо зберігати бекап на віддаленому сховищі, окремо від сервера. Ми використовуємо Amazon S3 або Яндекс.Облако.

Оновлення через WP-CLI: в 2 рази швидше адмінки

WP-CLI дає повний контроль: оновлюємо ядро, плагіни, теми та переклади однією командою. Це в 2–3 рази швидше ручного оновлення через адмін-панель. Команди:

# Оновити ядро, плагіни, теми, переклади
wp core update
wp plugin update --all
wp theme update --all
wp language core update
wp language plugin --all update

# Перевірити поточну версію та доступні оновлення
wp core version
wp plugin list --update=available

Для масового оновлення кількох сайтів використовуємо скрипт на Bash. Середній час оновлення одного сайту — 10 хвилин, включаючи бекап.

Налаштування автоматичних мінор-оновлень

Для стандартних сайтів вмикаємо автооновлення мінор-версій ядра. Для плагінів — обираємо лише перевірені, наприклад Wordfence або Akismet.

// Ввімкнути автооновлення minor-версій ядра
define('WP_AUTO_UPDATE_CORE', 'minor');

// Автооновлення всіх плагінів (не рекомендується)
// add_filter('auto_update_plugin', '__return_true');

// Автооновлення конкретного плагіна
add_filter('auto_update_plugin', function (bool $update, object $item): bool {
    return $item->slug === 'wordfence' ? true : $update;
}, 10, 2);

Порівняння підходів до оновлення

Типові помилки при самостійному оновленні

• Оновлення плагіна до версії, несумісної з ядром — найчастіше ламає функціонал.
• Пропуск бекапу бази даних перед мажорним оновленням — втрата даних при збої.
• Ігнорування changelog плагіна — там часто вказані breaking changes, які потребують додаткових дій.

Покрокова інструкція з професійного оновлення

1. Аудит поточного стану: перевіряємо версії ядра, плагінів, теми, виявляємо застарілі або несумісні компоненти.
2. Створення повного бекапу: копіюємо файли та базу даних на зовнішнє сховище.
3. Розгортання staging-середовища: розгортаємо копію сайту на ізольованому сервері.
4. Тестування оновлення: послідовно оновлюємо ядро, плагіни, тему на staging, запускаємо автотести (50+ сценаріїв).
5. Застосування на production: після успішного тестування переносимо оновлення на бойовий сайт, моніторимо протягом 24 годин.

Оновлення мажорних версій: екстра-обережність

При переході з мажорної версії на наступну (наприклад, 6.x → 7.x) обов'язково перевіряємо сумісність плагінів та теми. Спочатку тестуємо на копії сайту.

# Перевірити сумісність
wp plugin list --format=table

# Оновити на тестовій копії
wp core update --version=7.0 --force

Після оновлення запускаємо 50+ автотестів та перевіряємо консоль браузера.

Відновлення після збою

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

# Відкотити останнє оновлення плагіна
wp plugin install woocommerce --version=8.5.0 --force

# Відкотити ядро
wp core download --version=6.6.0 --force
wp core update-db

# Відновити з бекапу БД
wp db import backup.sql

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

Чому варто довірити оновлення професіоналам?

Наш досвід — понад 7 років роботи з WordPress, 200+ оновлених проєктів. Сертифіковані спеціалісти використовують staging-сервери, систему моніторингу та регламент відкату. Ми не просто натискаємо кнопку — ми гарантуємо працездатність та надаємо детальний звіт. Зв'яжіться з нами для оцінки вашого проєкту — запропонуємо терміни та вартість. Отримайте консультацію з оновлення вашого сайту.

Що входить в послугу «Оновлення під ключ»?

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

Технічна підтримка сайту: оновлення, моніторинг, SLA

Сайт на Laravel 8 з PHP 7.4. PHP 7.4 більше не підтримується, Laravel 8 — теж не отримує оновлень безпеки. Хостинг-провайдер попередив про обов'язкове оновлення PHP до 8.1 — після оновлення два плагіни та одна бібліотека зламалися, сайт упав. Ми регулярно стикаємося з такими сценаріями: проект без регулярного ТО перетворює кожне оновлення середовища на аварію.

Цей кейс — не виняток, а правило. Комерційні сайти втрачають конверсію через повільне завантаження, вразливості, недоступність. Ми беремо на себе моніторинг, оновлення залежностей, бекапи та SLA — щоб ви займалися бізнесом, а не сервером.

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

Що реально входить у технічну підтримку сайту?

Підтримка — не «відповісти на дзвінок, коли щось зламалося». Це систематичне запобігання поломкам.

Оновлення залежностей. Composer packages, npm packages, CMS або фреймворк. composer audit та npm audit показують відомі вразливості. Dependabot або Renovate створюють автоматичні PR — завдання підтримки перевірити, що оновлення не зламало staging, і змержити.

Оновлення бувають: patch (1.2.3 → 1.2.4, тільки bugfix, безпечно), minor (1.2.0 → 1.3.0, нові фічі зі зворотною сумісністю, зазвичай безпечно), major (1.x → 2.x, ламаючі зміни, вимагають тестування). Ігнорувати оновлення 6+ місяців — накопичити техборг: розрив більший, роботи більше.

WordPress — окрема розмова. Популярність платформи робить її головною ціллю атак. Застарілі плагіни — вектор №1 зломів. Регулярні оновлення ядра, плагінів, тем + правильні дозволи файлової системи + WAF — необхідний мінімум. Наш досвід показує, що автоматичні оновлення WordPress Core без тестового середовища — ризик, який ми не допускаємо.

Як моніторинг запобігає простоям?

Uptime моніторинг. Базовий HTTP-чек раз на хвилину. Better Uptime, Upptime (self-hosted), Checkly, New Relic Synthetics. Алерт у Telegram або Slack при падінні — і сповіщення при відновленні. Якщо сайт недоступний 10 хвилин у робочий час — прямий збиток.

Продуктивність. TTFB, LCP, INP — відстежуємо через Google Search Console (реальні користувачі, CrUX) та синтетичний моніторинг (Lighthouse CI, SpeedCurve). Деградація часто поступова — без моніторингу ви помічаєте через місяць, коли LCP вже 5s.

Помилки додатку. Sentry — стандарт для відстеження JavaScript та PHP/Python помилок у реальному часі. Кожен необроблений виняток із трасуванням стеку, контекстом запиту, версією браузера. Особливо важливо для помилок, які користувачі не повідомляють — вони просто йдуть.

База даних. Зростання об'єму, повільні запити (MySQL slow query log, pg_stat_statements для PostgreSQL), розмір індексів. Таблиця без VACUUM у PostgreSQL розростається до гігабайт через dead tuples. Рутинне обслуговування БД — частина підтримки.

Дисковий простір та логи. logrotate налаштований? /var/log/nginx росте без обмежень і заповнює диск — класика. Автоматична ротація + алерт при disk > 80%.

Чому бекапи без перевірки — ілюзія?

Бекап без перевірки відновлення — не бекап, а ілюзія безпеки. Бачили випадки, коли mysqldump створював файл 0 байт через помилку прав, а ніхто не перевіряв вміст місяцями. Ми гарантуємо, що всі копії працездатні.

Схема бекапів:

• Щоденний інкрементальний бекап бази даних + медіафайли
• Щотижневий повний бекап
• Зберігання: мінімум 3 копії, 2 різних медіа, 1 offsite (S3, Backblaze B2)
• Автоматична перевірка цілісності (pg_restore --list, mysqldump verify)
• Тестове відновлення раз на квартал в ізольоване середовище

Retention політика: 7 щоденних, 4 щотижневих, 3 щомісячних. S3 Lifecycle rules автоматизують видалення.

SLA: що це означає на практиці

SLA (Service-Level Agreement) Wikipedia — конкретні зобов'язання щодо часу реакції та відновлення:

SLA має сенс тільки за наявності моніторингу — інакше про проблеми дізнаються від користувачів, а не від систем. Неробоча кнопка у формі може непомітно вбивати конверсію тижнями.

Процес оновлення контенту

Розробник не повинен бути в ланцюжку для правки тексту на сторінці. CMS зі зручним редактором, розмежування прав (редактор править контент, не чіпає код), історія змін. Для Laravel-проектів — Nova, Filament, або headless CMS (Strapi, Contentful) залежно від складності.

Preview перед публікацією, staged rollout для важливих змін. Якщо редактори працюють напряму з prod — це ризик.

Типові ситуації, які вирішуємо

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

Падіння продуктивності після оновлення: feature flag + можливість швидкого rollback. Canary деплой — оновлюємо 5% трафіку, дивимось метрики, потім 100%.

Що входить у пакет підтримки (deliverables)

При укладенні договору ви отримуєте:

• Документація: схема інфраструктури, доступи, процедури відновлення
• Моніторинг: uptime, продуктивність, помилки, логи — налаштований з першого дня
• Резервне копіювання: щоденні/щотижневі копії з перевіркою
• Оновлення залежностей: щомісячний аудит та оновлення з тестуванням
• SLA-реагування: за пріоритетами з таблиці вище
• Звіти: щотижневі дашборди, щомісячний огляд, квартальний техплан
• Підтримка редагування контенту: навчання редакторів, налаштування прав

Зв'яжіться з нами, щоб підібрати відповідний план та отримати первинний аудит стану вашого проекту.

Як ми працюємо: етапи

1. Онбординг (3–5 днів): аудит поточного стану, налаштування моніторингу та бекапів, документування інфраструктури.
2. Регулярний ритм: щотижневий звіт за метриками, щомісячний огляд оновлень, квартальний технічний аудит.
3. Реагування: за SLA, з фіксацією причини та часу вирішення.
4. Розвиток: за вашим запитом — новий функціонал, оптимізація, рефакторинг.

Ми працюємо з 2016 року, підтримуємо понад 50 проектів від лендінгів до маркетплейсів.

Строки та вартість

Налаштування моніторингу та бекапів: 3–5 днів. Регулярна підтримка — ongoing контракт з фіксованим об'ємом годин на місяць або абонемент. Вартість розраховується індивідуально після аудиту. Отримайте консультацію — оцінимо ваш проект за 1–2 дні.

Порівняння: моніторинг з автоматичним алертингом vs ручна перевірка

Автоматичний моніторинг Better Uptime в 10 разів швидше реагує на збої, ніж ручна перевірка.