Міграція MODX Evolution → Revolution: контент, шаблони, API

Ми часто стикаємося з ситуацією, коли власники сайтів на MODX Evolution скаржаться на застарілу архітектуру: PHP 5.6, відсутність PSR-сумісності, незакриті вразливості. Evolution використовує процедурний підхід, глобальні об'єкти $modx, а Revolution — сучасний ООП з xPDO ORM. Прямий апгрейд неможливий — потрібна повноцінна міграція з переробкою коду. Evolution не підтримує сучасні стандарти кешування та автозавантаження, що призводить до повільної роботи та проблем із масштабуванням. Revolution надає вбудоване кешування, PSR-сумісні класи та гнучку систему подій. Наприклад, в Evolution для виведення списку документів доводилося писати прямі SQL-запити, що збільшувало ризик SQL-ін'єкцій. В Revolution це завдання вирішується через xPDO з автоматичним екрануванням.

Навіщо мігрувати з MODX Evolution на Revolution?

Перехід на Revolution дає вимірні вигоди: середній час завантаження сторінки скорочується вдвічі за рахунок вбудованого кешування, усуваються вразливості старої архітектури, з'являється доступ до сучасних пакетів та автозавантаження. Економія на хостингу може сягати 30% — це до 20 000 грн на рік для типового проєкту. Крім того, Revolution підтримує PHP 8.x, що продовжує життєвий цикл сайту. Зниження витрат на підтримку та доопрацювання досягає 40%, що економить близько 50 000 грн щорічно.

Що переноситься при міграції

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

Як проходить міграція?

Аналіз поточного сайту

Перед міграцією проводимо аудит: збираємо дані по шаблонах, TV-параметрах, сніпетах та плагінах. Приклад SQL-запиту для оцінки обсягу роботи:

-- Кількість документів за шаблонами
SELECT t.templatename, COUNT(d.id) as count
FROM site_content d
JOIN site_templates t ON t.id = d.template
GROUP BY t.templatename;

-- TV-параметри
SELECT tv.caption, tv.type, COUNT(tvv.id) as used
FROM site_tmplvars tv
LEFT JOIN site_tmplvar_contentvalues tvv ON tv.id = tvv.tmplvarid
GROUP BY tv.id;

-- Кастомні сніпети
SELECT name, LENGTH(snippet) as size FROM site_snippets;

-- Плагіни
SELECT name, plugincode FROM site_plugins WHERE disabled = 0;

Як перенести TV-параметри?

TV-параметри мапляться за назвою. Якщо в Evolution поле називалося color, в Revolution воно залишається color. Важливо перевірити типи: в Evolution тип TV може відрізнятися від Revolution (наприклад, текстове поле проти текстової області). Ми коригуємо типи вручну. Додатково налаштовуємо доступ до TV через системні налаштування Revolution.

Як мігрувати сніпети та плагіни?

Сніпети Evolution написані в процедурному стилі з глобальним $modx. В Revolution API інший. Наприклад:

// Evolution (старий API)
$docs = $modx->getDocuments($parents = [5], $published = 1);

// Revolution (правильний API)
$c = $modx->newQuery('modResource');
$c->where(['parent' => 5, 'published' => 1]);
$docs = $modx->getCollection('modResource', $c);

Сніпети потрібно переписувати. Для типових завдань (виведення списків, меню, форм) — використовувати готові Revolution Extra: pdoResources, pdoMenu, FormIt. Це прискорює розробку та знижує ймовірність помилок.

Міграція зображень і файлів

# Структура зображень ідентична (assets/images/)
rsync -avz old-server:/var/www/evo-site/assets/images/ \
    /var/www/revo-site/assets/images/

Реальний кейс: інтернет-магазин за 4 тижні

Наш клієнт — інтернет-магазин на Evolution з 300 ресурсами, 20 сніпетами та 10 TV. Ми виконали міграцію за 4 тижні. Ключові проблеми:

• Сніпет кошика використовував прямі SQL-запити — переписали на xPDO.
• Шаблони містили застарілі теги [+...+] — замінені на [[+...]] Revolution.
• Змінена структура URL, налаштовані редиректи .htaccess.

Клієнт відзначив: «Швидкість завантаження зросла на 40%, а навантаження на сервер знизилося вдвічі».

Результат: швидкість завантаження зросла на 40% за рахунок кешування Revolution, усунені вразливості, знижено навантаження на сервер. Економія на хостингу склала до 30%. Хочете так само? Замовте аудит свого сайту на Evolution безкоштовно.

Порівняння продуктивності: Evolution vs Revolution

Revolution швидший у 2 рази за часом завантаження, а кешування знижує навантаження на сервер.

Терміни та вартість

Вартість розраховується індивідуально після аналізу кодової бази.

Що входить у роботу?

• Аудит поточного сайту: аналіз шаблонів, сніпетів, TV, плагінів.
• Експорт всіх даних зі збереженням структури.
• Встановлення та конфігурація Revolution з налаштуванням кешування.
• Імпорт контенту з рефакторингом шаблонів та сніпетів під xPDO.
• Міграція зображень та файлів з автоматичною заміною шляхів.
• Налаштування 301 редиректів для збереження URL.
• Тестування на staging-оточенні.
• Документація по новому сайту та навчання адміністраторів.
• Пост-релізна підтримка: безкоштовне виправлення багів протягом 30 днів.

Чому нам довіряють

• 10+ років досвіду з MODX обох версій.
• Понад 50 реалізованих проєктів з міграції.
• Сертифіковані інженери з MODX Revolution.
• Гарантія якості: безкоштовне виправлення багів протягом 30 днів.

Зв'яжіться з нами для безкоштовної оцінки обсягу робіт. Замовте міграцію — і забудьте про проблеми Evolution. Отримайте консультацію протягом 2 робочих днів.

Редизайн та міграція сайту: зміна CMS, збереження SEO

Клієнт прийшов через 6 тижнів після самостійного редизайну: «Ми переїхали з WordPress на Tilda, трафік впав на 70%». Відкриваю Google Search Console — 847 сторінок віддають 404, URL-структура повністю змінилася, жодного 301-редиректу. Яндекс ще не переіндексував новий сайт, позиції впали. Відновлення зайняло 4 місяці та призвело до значних фінансових втрат. Наш досвід — понад 7 років та 80+ успішних міграцій. Клієнти, які замовляють професійну міграцію, відновлюють трафік у 3 рази швидше, ніж ті, хто виконує її самостійно.

Чому міграції ламають SEO?

Пошуковики проіндексували конкретні URL. Якщо /catalog/shoes/nike-air-max-270 перетворився на /products/nike-air-max-270 без 301-редиректу — весь посилальний вага сторінки, весь трафік, всі позиції йдуть у нікуди. Google каже, що 301 передає ~99% PageRank, але на практиці позиції відновлюються за 2–8 тижнів, а не миттєво.

Найчастіше SEO ламають не зі злого наміру, а тому що розробник не думає про URL-структуру як про публічний API. Ось типові поломки:

Як відновити трафік після невдалої міграції?

Якщо трафік впав — дійте негайно:

1. Краул нового сайту на 404 та порівняння з передміграційним списком URL.
2. Створення редиректів для всіх втрачених сторінок з трафіком >0.
3. Перевірка структурованих даних та мета-тегів на тестовій вибірці.
4. Щоденний моніторинг Coverage в Search Console та позицій за топ-50 запитами.
5. Якщо через 2 тижні трафік не відновлюється — глибокий аудит редиректів (транзитивність, ланцюжки, цикли).

У нашій практиці такий випадок: великий інтернет-магазин втратив 50% трафіку при переїзді з Бітрікса на React + Strapi. За три дні відновили 95% редиректів, через 3 тижні трафік повернувся на 90% від початкового.

Як підготувати сайт до міграції: що не можна пропустити?

До початку розробки нового сайту потрібно:

1. Повний краул поточного сайту через Screaming Frog або Sitebulb. Отримати список всіх індексованих URL з трафіком з Google Search Console.
2. Вивантажити всі сторінки з органічним трафіком >0 за останні 6 місяців — це пріоритет для редиректів.
3. Зафіксувати всі зовнішні посилання (backlinks) на конкретні сторінки — Ahrefs, Semrush.
4. Сфотографувати поточні позиції за ключовими запитами — база для порівняння після міграції.
5. Зберегти Core Web Vitals з Search Console за попередні 90 днів.

Таблиця для фіксації:

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

Мапінг URL та редиректи

Для проекту з 200+ сторінками створюємо таблицю мапінгу: старий URL → новий URL → статус (301, об'єднаний з іншою сторінкою, видалений). Кожен рядок проходить перевірку: чи реально контент переїхав саме сюди.

У Laravel редиректи через конфігураційний файл та middleware, не через .htaccess — це швидше та керованіше. Для WordPress → Next.js: редиректи налаштовуються в next.config.js (статичні) та на рівні Nginx/CDN для динамічних. Старий .htaccess на shared хостингу з 500+ рядками редиректів — особливий ад. Кожен редирект перевіряється послідовно, продуктивність падає. Переносимо в Nginx map директиву або Redis-кеш для динамічного пошуку.

Міграція контенту з різних CMS

WordPress → Headless CMS (Contentful, Strapi, Sanity):
WordPress REST API або WP All Export для експорту постів, метаполів, медіафайлів. Скрипт міграції на Node.js: парсимо експорт, трансформуємо структуру, завантажуємо через API CMS. Медіафайли перевантажуємо в нове сховище, оновлюємо посилання в контенті. Типова проблема — shortcodes в контенті WordPress ([gallery id="123"]): потрібен парсер та трансформація в новий формат.

1С-Бітрікс → сучасний стек:
Бітрікс зберігає контент у нестандартних таблицях з IBLOCK_ELEMENT_PROPERTY. Прямий SQL-експорт через phpMyAdmin або Bitrix API. Трансформація — найдовша частина через специфіку структури даних Бітрікса.

Важкі WYSIWYG → структурований контент:
Роки редагування в FCKEditor/TinyMCE залишають inline-стилі, нестандартні теги, зламані атрибути. HTML sanitize + трансформація в Markdown або Portable Text (Sanity) з ручною перевіркою проблемних сторінок.

SEO-збереження технічних елементів

Структуровані дані (Schema.org) — якщо на старому сайті були Product, Article, BreadcrumbList розмітки, вони повинні бути і на новому. Google Search Console → Enhancement reports покажуть втрату rich snippets.

Sitemap XML: генерується автоматично, відправляється в GSC через день після запуску. Старий sitemap залишається до повної переіндексації.

hreflang для багатомовних сайтів: якщо теги загубилися при міграції, через кілька тижнів почнуться конфлікти між мовними версіями у видачі.

Open Graph та Twitter Card мета-теги — часто забувають при зміні шаблону, сторінки перестають коректно відображатися при шарінгу в соцмережах.

Як контролювати сайт після запуску?

DNS propagation: перемикання DNS займає до 48 годин, плануйте запуск із запасом. Cloudflare як DNS-провайдер — propagation займає хвилини, не години.

Після запуску щоденно моніторимо: Search Console → Coverage (помилки індексації), Analytics → органічний трафік, порівняння з аналогічним періодом минулого року, краулінг сайту на 404-помилки.

Перші 2 тижні — критичний період. Якщо трафік падає на 30%+ — негайний аудит редиректів та порівняння з передміграційним краулом.

Що входить в роботу

Результати, які ви отримуєте:

1. План міграції з мапінгом URL та редиректів у форматі Excel/Google Sheets.
2. Налаштовані 301 редиректи на серверному рівні (Nginx/Cloudflare/Vercel).
3. Перенесений контент з перевіркою цілісності: зображення, мета-поля, посилання.
4. Структуровані дані (Schema.org) на новому сайті, ідентичні старим або покращені.
5. Звіт по SEO: динаміка позицій через 1, 3 та 6 тижнів після запуску.
6. Моніторинг Coverage в Search Console з повідомленнями про помилки.
7. Гарантія збереження позицій: якщо трафік падає більш ніж на 15% протягом першого місяця — безкоштовний аудит та корекція.

Терміни та орієнтири

• Редизайн з міграцією невеликого сайту (до 100 сторінок): 4–8 тижнів.
• Міграція e-commerce з 500+ сторінок товарів: 8–16 тижнів.
• Тільки технічна частина міграції (редиректи, метадані) без редизайну: 1–3 тижні.

Вартість розраховується індивідуально за обсягом. Середня економія клієнта за рахунок збереження трафіку після міграції — суттєва сума для бізнесу.

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