Оновлення ядра 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-сайту, зв'язавшись з нами.
Порівняння способів оновлення
| Спосіб | Швидкість | Надійність | Вимоги |
|---|---|---|---|
| Через адмінку (Package Manager) | Середня | Висока | Доступ до адмінки |
| Через CLI (artisan) | Висока | Висока | SSH, MODX 3 |
| Вручну через FTP | Низька | Низька | FTP-доступ |
| Наша послуга (під ключ) | Оптимальна | Максимальна | Доступ до сервера |
Ми рекомендуємо довіряти оновлення професіоналам — це виключає помилки та економить час. Зв'яжіться з нами для оцінки вашого проєкту.
Строки та що входить в роботу
| Етап | Тривалість | Результат |
|---|---|---|
| Аналіз поточних версій і сумісності | 0,5–1 год | Звіт про статус |
| Резервне копіювання | 0,5–1 год | Бекап файлів і БД |
| Оновлення ядра | 1–2 год | Робоча нова версія |
| Оновлення пакетів | 1–2 год | Усі Extra актуальні |
| Тестування функціональності | 1–2 год | Сайт працює коректно |
| Документація та передача доступів | 0,5 год | Інструкція, логи, скрипти |
Орієнтовний час на комплексне оновлення — від 2 до 6 годин. Вартість розраховується індивідуально, пишіть для оцінки.
Типові помилки при самостійному оновленні
- Пропуск бекапу бази даних — відновлення майже неможливе.
- Копіювання файлів без виключення папок Extra — ламає компоненти.
- Оновлення Extra до версій, несумісних з поточним ядром.
- Ігнорування логів помилок після оновлення.
- Використання застарілих інструкцій з неперевірених джерел.
Ми гарантуємо збереження даних і підтримку після оновлення. Наша команда виконала понад 200 успішних оновлень MODX. Замовте консультацію — отримайте чек-лист і безкоштовну перевірку поточного стану вашого MODX-сайту.