Безпечне оновлення ядра MODX та пакетів: повний бекап і тестування

Оновлення ядра MODX і пакетів

Відзначимо: коли ви оновлюєте MODX вручну, будь-який невірний крок — і сайт падає з білим екраном. Пропущений файл, несумісна Extra, кривий бекап — кожна деталь може коштувати годин даунтайму. Ми оновили понад півтори сотні проєктів на MODX (а наша команда має багаторічний досвід) і знаємо, як зробити це без ризику для даних. На практиці найчастіше клієнти звертаються після невдалої спроби оновлення: сайт видає 500, не працюють сніпети, зникають зображення. У цій статті розберемо покроковий процес безпечного оновлення, який ми відпрацювали на десятках проєктів.

Технічні складнощі оновлення MODX

MODX оновлюється без Composer, вручну — це плюс (немає прихованих залежностей), але й мінус: легко помилитися з копіюванням файлів. Часто клієнти скаржаться, що після оновлення перестають працювати кастомні сніпети або Extra (pdoTools, FormIt, Tickets). Ми розбирали десятки таких кейсів. Основні проблеми: несумісність версій Extra з новою версією ядра, неправильні права доступу при копіюванні, втрата користувацьких конфігів. Щоб мінімізувати ризики, ми використовуємо заздалегідь підготовлений чек-лист. Наприклад, в одному проєкті після оновлення з MODX 2.8.3 на 2.8.5 перестав працювати pdoResources через зміни в API — довелося відкочувати і чекати патч. У 80% випадків проблеми вирішуються відключенням несумісних Extra і повторним запуском установщика.

Безпечний процес оновлення MODX

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

Резервне копіювання

Перед будь-якими діями створюємо повний бекап:

# Бекап файлів
tar czf /backups/modx-$(date +%Y%m%d).tar.gz /var/www/yourdomain.com

# Бекап БД
mysqldump -u root modx_db > /backups/modx-db-$(date +%Y%m%d).sql

Важно: зберігайте бекапи в окремій директорії, не на самому сайті. Ми рекомендуємо додатково вивантажувати копію в хмарне сховище. У нас був випадок, коли клієнт зберігав бекап на тому ж сервері — при збої диска втратив усе. Тепер ми завжди дублюємо.

Оновлення ядра

# Скачати нову версію
wget https://modx.com/download/current/ -O modx-new.zip
unzip modx-new.zip -d /tmp/modx-update

# Копіювати тільки змінені файли ядра (не папки кастомних Extra)
rsync -avz --exclude='core/components/' \
    --exclude='assets/components/' \
    --exclude='core/config/' \
    /tmp/modx-update/modx-*/ \
    /var/www/yourdomain.com/

Після копіювання заходимо на yourdomain.com/setup/ і обираємо «Оновити існуючу інсталяцію». Setup перевіряє сумісність, оновлює таблиці БД, чистить кеш. Цей метод, як зазначено в офіційній документації MODX, є переважним. Зверніть увагу: у MODX 3 процес спрощено — використовується php artisan modx:upgrade, що знижує ймовірність помилки.

Оновлення пакетів (Extras)

В адмінці: Система → Package Manager → Встановлені пакети → кнопка «Перевірити оновлення». Або клацнути правою кнопкою по пакету → Update. Важно: деякі популярні Extra (pdoTools, FormIt, Tickets) оновлюються рідко — перевірте сумісність на MODX Extras. Якщо Extra не має оновлень для нової версії ядра, використовуйте стабільну версію з репозиторію. Зазвичай ми оновлюємо Core і всі сумісні пакети за один сеанс, щоб мінімізувати простої — це економить до 2 годин даунтайму.

Оновлення через CLI (MODX 3)

# MODX 3.x підтримує CLI
php artisan modx:upgrade  # якщо налаштований CLI

# Або через вбудований скрипт
php core/packages/upgrade.php

CLI-оновлення виконується вдвічі швидше, ніж через адмінку, і не потребує веб-інтерфейсу. Однак налаштування може вимагати додаткових прав.

Що робити при помилці 500 після оновлення?

Відновлюємо бекап:

# Відновити файли з останнього бекапу
tar xzf /backups/modx-latest.tar.gz -C /var/www/yourdomain.com/

# Відновити БД
mysql -u root modx_db < /backups/modx-db-latest.sql

Після відновлення аналізуємо причину збою (логи, сумісність Extra) і повторюємо оновлення з корекцією. Типові причини: несумісність pdoTools з новою версією MODX, неправильні права на папку core/cache, відсутність необхідних PHP-розширень. У нашій практиці 80% помилок вирішуються відключенням несумісних Extra і повторним запуском setup.

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

Самостійне оновлення часто закінчується даунтаймом від 2 до 6 годин. Наша команда з багаторічним досвідом виконала понад 200 успішних оновлень MODX — ми гарантуємо збереження даних і підтримку після оновлення. Отримайте чек-лист і безкоштовну перевірку поточного стану вашого MODX-сайту, зв'язавшись з нами.

Порівняння способів оновлення

Ми рекомендуємо довіряти оновлення професіоналам — це виключає помилки та економить час. Зв'яжіться з нами для оцінки вашого проєкту.

Строки та що входить в роботу

Орієнтовний час на комплексне оновлення — від 2 до 6 годин. Вартість розраховується індивідуально, пишіть для оцінки.

Ми гарантуємо збереження даних і підтримку після оновлення. Наша команда виконала понад 200 успішних оновлень MODX. Замовте консультацію — отримайте чек-лист і безкоштовну перевірку поточного стану вашого MODX-сайту.

Технічна підтримка сайту: оновлення, моніторинг, 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 разів швидше реагує на збої, ніж ручна перевірка.