Миграция с MODX Evolution на Revolution: что меняется внутри

Сайт на MODX Evolution может продолжить отдавать страницы после импорта базы в Revolution, но это ещё не означает успешную миграцию. У двух веток разные классы объектов, система прав, контексты и формат подключения расширений. На практике первыми ломаются сниппеты, TV-параметры, формы, мультиязычные разделы и админские действия. Разбирать перенос нужно как преобразование модели сайта, а не как копирование таблиц.

Что именно меняется между Evolution и Revolution

MODX Evolution 1.x и MODX Revolution 2.x/3.x используют похожие понятия: ресурсы, шаблоны, чанки, сниппеты и TV-параметры. На уровне интерфейса это создаёт ощущение совместимости. Внутри Revolution эти сущности представлены объектной моделью xPDO, связаны с контекстами и управляются более детальной ACL-системой.

Ресурс в Revolution — это не просто строка с полями страницы. Это объект, связанный с родителем, контекстом, шаблоном, настройками публикации и правилами доступа. Поэтому перенос записи из таблицы Evolution не переносит автоматически все зависимости, которые ожидает Revolution.

Термин: xPDO — слой объектно-реляционного отображения, который связывает PHP-объекты MODX с таблицами базы данных. В Revolution расширения обычно работают не с произвольными SQL-строками, а с объектами и связями xPDO.

Главная ошибка миграции — проверять только главную страницу. Нужно проверять зависимости: кто вызывает сниппет, откуда берётся TV, в каком контексте находится ресурс и какие права нужны редактору.

Как Revolution видит сайт после переноса

Ресурсы и контексты

В Evolution дерево сайта обычно воспринимается как единая структура. В Revolution дерево живёт внутри контекста. Контекст может отвечать за отдельный домен, язык, поддомен или закрытую область. Один и тот же URI в разных контекстах не обязательно указывает на один объект или использует одинаковые настройки.

При переносе нужно сопоставить не только идентификаторы ресурсов, но и:

• корневой ресурс и родителя каждой ветки;
• контекст, в котором публикуется ресурс;
• настройки генерации URL и правило определения страницы;
• шаблон, статус публикации, дату публикации и меню;
• права группы пользователей на чтение и редактирование.

Особенно опасна миграция мультиязычного сайта. Если в Evolution языки определялись плагином, TV-полями или соглашением в URI, Revolution не угадает эту схему. Контексты придётся спроектировать отдельно, а не создавать механически по числу языков.

Шаблоны, чанки и парсер

Шаблон в Revolution по-прежнему содержит HTML и теги MODX, но обработка проходит через другую архитектуру. Чанк, сниппет, плагин и шаблон становятся объектами менеджера и могут вызываться через системные события. Старый тег может выглядеть корректно, но зависеть от переменной, плагина или порядка обработки, которого в Revolution уже нет.

Особый риск — прямой доступ к внутренним переменным Evolution. Код, который рассчитывает на конкретные глобальные переменные, старые имена таблиц или поведение парсера, нельзя считать совместимым только потому, что он написан на PHP. Каждый такой сниппет нужно проверить на тестовой странице с теми же входными данными, что и в продакшене.

Не смешивайте перенос ядра и перенос логики. Сначала нужно понять, какие элементы сайта являются контентом, а какие — исполняемым кодом. Тексты и изображения переносятся как данные. Сниппеты, плагины и формы требуют ревью и тестирования.

Почему TV-параметры дают больше всего ложных успехов

Страница может открываться, а её поля — исчезнуть. Причина в том, что TV состоит не только из имени. У него есть тип ввода, список значений, привязка к шаблонам, параметры отображения и значения для конкретных ресурсов. В Revolution эти связи представлены иначе, поэтому перенос только названий TV не восстанавливает их поведение.

Проверять нужно три уровня:

1. Определение TV. Совпадают ли имя, тип, описание, обязательность и список допустимых значений.
2. Привязка. Подключён ли TV к нужным шаблонам и показывается ли он редактору с правильными правами.
3. Значение. Сохранилось ли значение для каждого ресурса, включая пустые, множественные и файловые поля.

Файловый TV требует отдельной проверки. В базе может сохраниться старый путь, но каталог на новом сервере будет другим. Ссылка начнёт вести в никуда, хотя поле в админке формально заполнено.

Расширения: где перенос перестаёт быть импортом

В Evolution расширение могло состоять из сниппета, плагина и набора файлов, вручную разложенных по каталогам. В Revolution пакет обычно описывает установку, системные события, настройки и зависимости. Поэтому копирование папки расширения не превращает его в рабочий пакет.

Для каждого расширения составьте карту:

• какие сниппеты вызываются из шаблонов и чанков;
• какие плагины подписаны на события MODX;
• какие TV, таблицы и файлы оно использует;
• какие настройки хранятся в конфигурации, а какие — в базе;
• совместима ли версия расширения с вашей веткой Revolution и версией PHP.

Если пакет заброшен, самый дешёвый путь не всегда означает прямой перенос. Иногда безопаснее заменить его штатным механизмом Revolution или небольшим новым сниппетом. Цена решения — это не только время разработки, но и риск получить скрытую ошибку после обновления PHP.

Что измерять, а не угадывать

Без замеров нельзя честно утверждать, что Revolution медленнее или быстрее Evolution именно на вашем сайте. Результат зависит от версии PHP, числа ресурсов, запросов сниппетов, кеширования, базы данных и конфигурации сервера.

До переключения домена зафиксируйте для одинаковых URL:

• время ответа без учёта сети и время до первого байта;
• HTTP-коды для страниц, изображений, файлов и форм;
• число SQL-запросов и время их выполнения, если это доступно в окружении;
• размер HTML и количество внешних запросов;
• время открытия списка ресурсов и сохранения страницы в админке.

Сравнивайте сайты на одинаковых данных, с одинаковым состоянием кеша и хотя бы на одной версии PHP. Иначе разницу между системами легко перепутать с влиянием хостинга или нового шаблона.

Граничные случаи, на которых схема ломается

Старые URL. Если изменились алиасы, вложенность или правила URL, поисковые страницы и внешние ссылки начнут возвращать 404. Карта перенаправлений должна появиться до переключения DNS.

Кеш. После миграции старый кеш может содержать HTML со старыми идентификаторами и путями. Очистка кеша не исправит неправильный шаблон, но без неё диагностика будет недостоверной.

Формы и отправка почты. Форма может отрисоваться, но не отправить письмо из-за другой конфигурации почты, события или несовместимого дополнения. Проверяйте не только страницу благодарности, но и фактическую доставку.

Права редакторов. Владелец сайта часто проверяет миграцию под администратором и не замечает, что редактор не видит нужный контекст или не может менять TV. Тестовая учётная запись должна иметь те же права, что и реальный сотрудник.

Пользовательский PHP-код. Вызовы старого API и прямые обращения к таблицам могут работать на простом сценарии и падать на пустом значении или другом типе ресурса. Такие места нужно искать по коду до импорта, а не после первого сбоя в продакшене.

Что делать дальше

Соберите стенд на отдельном домене и перенесите туда копию базы и файлов. Затем составьте матрицу: URL, контекст, шаблон, TV, сниппеты, форма и ожидаемый HTTP-код. Прогоните по ней главную страницу, типовые материалы, поиск, формы, закрытые разделы и несколько страниц с пустыми значениями.

После функциональной проверки измерьте время ответа и ошибки в логах на одинаковой нагрузке. Только затем планируйте короткое окно переключения: заморозьте изменения контента, сделайте резервную копию, примените миграцию и оставьте возможность быстро вернуть старую систему. Инвалидация кеша и настройка редиректов — отдельные задачи, их не стоит прятать внутри импорта базы.