Миграция сайта в MODX: что проверить на ревью

Миграция MODX ломается там, где её считают копированием

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

Ниже — чек-лист для миграции MODX Revolution 3.x. Если проект остаётся на MODX Revolution 2.x или переходит между мажорными версиями, проверок будет больше: поведение дополнений, требования PHP и структура конфигурации могут отличаться. Точные совместимые версии сверяйте с документацией конкретного релиза.

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

Что именно должно попасть на ревью

До проверки зафиксируйте исходную и целевую среду: версию MODX, PHP, СУБД, веб-сервера, установленных дополнений, доменов и контекстов. Без этого невозможно отличить ошибку переноса от несовместимости платформы.

• файлы проекта, включая кастомные чанки, сниппеты, плагины, шаблоны и дополнения;
• базу данных и кодировку соединения;
• пользовательские файлы: изображения, документы, загрузки из медиаменеджера;
• настройки доменов, контекстов, путей к файлам и URL;
• права на каталоги, где MODX пишет кэш, логи и загруженные файлы;
• планировщики, очереди, вебхуки, интеграции с почтой, CRM и платёжными сервисами;
• процедуру переключения DNS и план отката.

Контекст¹ в MODX — отдельное окружение с собственными настройками, доменом и правилами обработки ресурсов. Ошибка в контексте может затронуть только часть сайта, поэтому проверка одной главной страницы её не обнаружит.

Первое ревью: версии и воспроизводимость

Сверьте не только MODX

Запросите список версий старого и нового окружения. В нём должны быть MODX Revolution, PHP, MySQL или MariaDB, веб-сервер, обработчик PHP и ключевые дополнения. Если на старом сервере используется PHP-расширение, которого нет на новом, ошибка может появиться только в отдельном сниппете или при обработке изображения.

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

1. оно установлено на новом сервере;
2. его версия совместима с целевой версией MODX и PHP;
3. его настройки перенесены, а не восстановлены значениями по умолчанию.

Результат ревью должен быть не фразой «версии примерно одинаковые», а таблицей с фактическими значениями и решением по каждому расхождению. Если версия неизвестна, её сначала нужно получить из панели управления, файлов проекта или пакета развёртывания, а не угадывать.

База данных: проверяйте целостность, а не размер дампа

Одинаковый размер SQL-файла не доказывает, что перенос прошёл правильно. На ревью сравнивают количество таблиц, наличие пользовательских данных, кодировку, префиксы таблиц и результат выборочных проверок.

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

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

Файлы, пути и права: где чаще всего скрывается сбой

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

На ревью отдельно проверяют:

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

Не принимайте универсальное решение «выдать права на запись всему каталогу проекта». Оно маскирует проблему и расширяет последствия уязвимости. Права должны быть минимальными, но достаточными для конкретных операций: кэширования, логирования и загрузки файлов.

Контексты, URL и кэш

Первая страница часто работает даже при неверных настройках контекста. Ошибка проявится позже: у мультиязычной версии, отдельного домена, каталога или API-эндпоинта.

1. Откройте по одному ресурсу в каждом контексте.
2. Проверьте абсолютные и относительные ссылки, канонический URL, robots.txt и карту сайта.
3. Проверьте страницы с параметрами, ошибку 404 и редирект с HTTP на HTTPS, если он настроен.
4. Очистите кэш и повторите проверки анонимным пользователем.
5. Сравните результат с исходным сайтом: URL, заголовки ответа, изображения и служебные файлы должны вести себя одинаково, если это было частью требований.

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

Что проверить в пользовательских сценариях

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

Для интеграций нужен тестовый контур или безопасная заглушка. Не проверяйте платёжный или почтовый сценарий реальными операциями без согласованного тестового режима.

Формулировки замечаний на ревью

Общее «проверьте настройки» не помогает закрыть риск. Замечание должно связывать проблему с проверкой и последствием.

• Слабо: «Неясно, как перенесли файлы». Сильнее: «Нет подтверждения загрузки файла через медиаменеджер. Проверить владельца каталога, путь загрузки и открытие файла по публичному URL».
• Слабо: «Проверить кэш». Сильнее: «После очистки кэша страница должна сформироваться заново на новом сервере; приложить результат для анонимного запроса и запись об ошибке, если она появляется».
• Слабо: «Проверить интеграции». Сильнее: «Для формы указать, где проверяется успешная доставка: лог MODX, журнал почтового сервиса или тестовая запись в CRM».
• Слабо: «Можно переключать домен». Сильнее: «Нет процедуры возврата DNS и старого сервера в рабочее состояние. Описать шаги отката и срок сохранения старой среды».

Граничные случаи и момент, когда миграция не готова

Ревью нельзя закрывать, если проверена только копия базы и главная страница. Отдельного решения требуют большие медиакаталоги, несколько контекстов, нестандартные правила URL, интеграции без тестового режима и дополнения, давно не обновлявшиеся относительно MODX или PHP.

Нельзя считать перенос готовым и в таких случаях:

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

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

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

Соберите короткий протокол: версии, состав перенесённых данных, результаты сценариев, найденные замечания, время переключения и план отката. После выхода в продакшен следите за HTTP-кодами 4xx и 5xx, логами MODX, ошибками PHP, временем ответа, отправкой форм и заполнением диска. Первую проверку кэша и фоновых задач проведите после реального периода нагрузки, а не только сразу после переключения.

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

¹ Контекст — конфигурационная область MODX, которая может задавать собственный домен, настройки URL, ресурсы и параметры обработки запросов.