Перенос сайта с MODX на Битрикс: карта шаблонов, ТВ-полей и адресов
Перенос сайта с MODX на Битрикс — это проект миграции контента и логики вывода, а не смена хостинга. Чтобы не потерять страницы и не сломать поведение сайта, сначала составляют карту ресурсов, шаблонов, TV-параметров, сниппетов и чанков, затем переносят данные, настраивают адреса и редиректы, проводят тестовый прогон и приёмку. В статье — предметная последовательность, таблица решений по нестандартным полям, учебный пример и чек-лист.
Что входит в перенос сайта с MODX на Битрикс и где границы
Перенос сайта с MODX на Битрикс охватывает контент, структуру, логику вывода и адреса. В работу входят: инвентаризация ресурсов, шаблонов, TV-параметров, сниппетов и чанков; перенос материалов и каталога; настройка пользователей и прав; карта URL и редиректов; подключение аналитики; тестовый прогон и приёмка. Границы задачи важно зафиксировать до старта, чтобы не смешивать миграцию с другими работами.
Что не входит: перенос хостинга, смена домена, переезд почты, настройка серверного окружения, разработка нового дизайна, изменение бизнес-логики, которой не было в исходной системе. Если эти работы нужны, их выделяют в отдельные этапы с собственными критериями приёмки. Перенос хостинга — это отдельная задача: она про инфраструктуру, а не про CMS. Смешивать её с миграцией рискованно, так как при сбое сложно локализовать причину.
Отдельно фиксируют, что гарантий неизменности позиций в поиске не даётся. Миграция может повлиять на видимость страниц, если адреса, заголовки или разметка изменятся. Задача команды — сохранить адреса и содержимое настолько, насколько это возможно, и заранее подготовить редиректы. Ответственный за границы — руководитель проекта со стороны заказчика; он подтверждает, что входит в объём, а что выносится за скобки.
Ещё одна граница — перенос паролей пользователей. Он зависит от формата хешей и совместимости. Если перенести пароли нельзя, применяют безопасный сброс без рассылки паролей в открытом виде. Это решение согласуют с профильным специалистом по безопасности и с заказчиком.
Исходные данные, доступы и ответственные
До начала работ собирают входные данные. Нужны: доступ к админке MODX с правами на чтение ресурсов, шаблонов, TV-параметров, сниппетов и чанков; доступ к базе данных для выгрузки; список доменов и поддоменов; перечень языковых версий; данные о пользователях и группах; сведения о каталоге и его связях; текущие настройки аналитики; карта текущих адресов. Если каких-то данных нет, это фиксируют как риск и планируют способ получения.
Ответственные роли: руководитель проекта, аналитик или контент-менеджер, разработчик со стороны MODX, разработчик со стороны Битрикс, тестировщик, специалист по аналитике, представитель заказчика для приёмки. На малых проектах роли совмещают, но зоны ответственности всё равно прописывают. Например, аналитик отвечает за карту ресурсов и TV-полей, разработчик — за перенос логики вывода, тестировщик — за проверку адресов и форм, заказчик — за подтверждение приёмки.
Полезно заранее договориться о формате обмена: выгрузки в таблицах, промежуточные отчёты, журнал решений. Это снижает риск, что нестандартное поле потеряется между этапами. Если в проекте есть юридические или персональные данные, границы их обработки согласуют с профильным специалистом; статья не заменяет юридическое заключение.
Карта ресурсов, шаблонов, TV-параметров, сниппетов и чанков
Карта — это таблица, где каждой сущности MODX сопоставлено решение для Битрикс. Начинают с ресурсов: какие типы страниц есть, сколько их, какие шаблоны используются, какие TV-параметры к ним привязаны. Затем описывают сниппеты и чанки: что они выводят, какие данные запрашивают, есть ли зависимости от внешних сервисов. Для каждого элемента указывают: переносится как есть, переписывается, заменяется штатным механизмом или не переносится.
TV-параметры — частая зона потерь. Одни поля становятся свойствами элементов, другие — дополнительными полями разделов, третьи — настройками компонента. Решение зависит от контекста использования: в шаблоне вывода, в фильтре, в карточке товара или в служебной логике. Если поле нигде не выводится и не влияет на поведение, его можно не переносить, но отказ фиксируют письменно.
Сниппеты и чанки не переносят механически. Сначала описывают их назначение, затем подбирают эквивалент в Битрикс или переписывают логику. Если сниппет обращается к внешнему API, проверяют доступ и формат ответа. Чанки, бывшие фрагментами разметки, часто становятся включаемыми областями или шаблонами компонентов.
Результат этапа — согласованная карта, где по каждой сущности есть решение и ответственный. Без неё перенос превращается в цепочку импровизаций, а нестандартные поля теряются.
Таблица решений по нестандартным полям и логике
Таблица помогает принять решение до переноса, а не после. Ниже — предметные строки для типовых ситуаций.
| Сущность в MODX | Признак | Решение для Битрикс | Критерий проверки |
|---|---|---|---|
| TV-параметр с одиночным текстом | Выводится в карточке | Перенести как свойство элемента | Значение видно на странице и доступно в выгрузке |
| TV-параметр с изображением | Используется в галерее | Перенести как свойство с привязкой к файлу | Изображение отображается и не теряет привязку |
| TV-параметр-список | Влияет на фильтр | Перенести как свойство с допустимыми значениями | Фильтр возвращает те же элементы |
| Сниппет выборки | Формирует список по условию | Переписать под компонент каталога | Список совпадает по составу и порядку |
| Чанк-обёртка | Повторяется на многих страницах | Заменить включаемой областью или шаблоном | Разметка одинакова на всех страницах |
| Сниппет с внешним API | Запрашивает данные у сервиса | Проверить доступ и формат ответа | Ответ обрабатывается, ошибки логируются |
| Поле только для служебной логики | Не выводится посетителю | Не переносить, зафиксировать отказ | Поведение сайта не меняется |
После заполнения таблицы проверяют наличие ответственного и способа проверки для каждой строки. При сомнениях решение выносят на встречу с заказчиком. Не стоит переносить поле «на всякий случай»: лишние сущности усложняют поддержку и приёмку.
Карта URL, редиректы и сохранение адресов
Адреса — самая чувствительная часть миграции. Сначала снимают полный список текущих URL: страницы, разделы, карточки, пагинация, служебные адреса. Затем для каждого адреса определяют, сохраняется ли он в новой системе. Если адрес меняется, готовят редирект с прежнего на новый. Редиректы проверяют на тестовом стенде до переключения.
Отдельно разбирают динамические адреса каталога, фильтров и поиска. Часть из них может не переноситься, если в новой системе другая логика. Такие случаи фиксируют и согласуют: либо настраивают редирект на ближайшую страницу, либо оставляют без изменений, если адрес не индексируется. Решение зависит от того, как адрес используется и попадает ли он в аналитику.
Проверка карты адресов включает: совпадение адресов для ключевых страниц, работу редиректов, отсутствие цепочек из нескольких переходов, корректный ответ для несуществующих страниц. Тестировщик проходит по выборке адресов и сверяет результат с картой. Если адрес ведёт не туда, это блокирующая ошибка до приёмки.
Перенос материалов, каталога и пользователей
Материалы переносят по карте ресурсов: тексты, изображения, привязки к разделам, авторы, даты. Каталог требует отдельного внимания: товары, цены, склады, свойства, категории, связи. Если каталог большой, его переносят частями, сверяя количество и состав на каждом этапе. Для сложных каталогов полезно изучить Миграция каталога интернет-магазина: как перенести большой каталог и не потерять товары, чтобы учесть связи.
Пользователей переносят с учётом групп и прав. Пароли переносятся только при совместимости форматов хешей; иначе применяют безопасный сброс без рассылки паролей. Это решение согласуют с заказчиком и специалистом по безопасности. Права доступа проверяют на тестовых учётных записях: редактор, менеджер, администратор.
После переноса сверяют: количество материалов, количество товаров, количество пользователей, наличие изображений и файлов, корректность привязок. Расхождения фиксируют в отчёте и устраняют до тестового прогона.
Тестовый прогон, приёмка и переключение
Тестовый прогон проводят на копии, а не на рабочем сайте. Создают резервную копию, разворачивают стенд, переносят данные, настраивают адреса и редиректы, подключают аналитику в тестовом режиме. Прогон повторяют до устранения ошибок. План возврата готовят заранее: при критичной проблеме после переключения должно быть понятно, как вернуться к прежнему состоянию.
Приёмка идёт по чек-листу: адреса, редиректы, формы, каталог, пользователи, аналитика, скорость ответа, отсутствие ошибок в журналах. Заказчик подтверждает результат письменно. Переключение выполняют в согласованное окно, с ответственным на связи и планом отката. После переключения наблюдают за поведением сайта и сверяют ключевые страницы.
Если в проекте участвуют смежные системы, полезно заранее изучить, как устроен перенос сайтов на 1с-битрикс в целом, чтобы не потерять общие этапы. Для сравнения подходов можно посмотреть Перенос WordPress на Битрикс: карта данных, адреса и приёмка и Перенос Тильды на Битрикс: карта миграции, проверка и приёмка — там описаны похожие принципы карты данных и приёмки.
Учебный пример: перенос сайта с MODX на Битрикс
Учебный пример. Условная компания с сайтом на MODX Revo: 420 страниц, 180 товаров, 12 шаблонов, 26 TV-параметров, 9 сниппетов, 40 чанков. Задача — перенести сайт на Битрикс без переноса хостинга. Входные условия: доступ к админке и базе есть, каталог небольшой, 15 пользователей, пароли в несовместимом формате.
Действия команды. Сначала составили карту ресурсов и TV-полей. Выяснили, что 6 TV-параметров не выводятся и не влияют на поведение — их решили не переносить. Два сниппета обращались к внешнему сервису: проверили доступ и формат ответа, один переписали, второй заменили штатным механизмом. Чанки-обёртки заменили включаемыми областями. Адреса сверили по карте: 18 адресов менялись, для них подготовили редиректы. Пароли решили сбросить безопасным способом без рассылки.
Проверка. На тестовом стенде прошли по выборке из 60 адресов: все вели на нужные страницы, цепочек редиректов не было. Сверили количество материалов, товаров и пользователей — совпало с исходным. Формы отправляли тестовые заявки, аналитика фиксировала тестовые события. После приёмки переключили сайт в согласованное окно и наблюдали за ключевыми страницами. Результат: сайт работает на Битрикс, адреса сохранены, нестандартные поля перенесены по решениям из таблицы. Позиции в поиске не оценивались в рамках примера.
Чек-лист приёмки
- Карта ресурсов, шаблонов, TV-параметров, сниппетов и чанков согласована
- По каждому нестандартному полю есть решение и ответственный
- Список текущих URL снят и сверен с новой структурой
- Редиректы настроены и проверены на тестовом стенде
- Материалы, каталог и пользователи перенесены, количества сверены
- Права доступа проверены на тестовых учётных записях
- Формы отправляют заявки, уведомления приходят
- Аналитика фиксирует события в тестовом режиме
- Резервная копия и план возврата готовы
- Переключение выполнено в согласованное окно, ответственный на связи
Ограничения, типичные ошибки и следующий шаг
Ограничения. Перенос паролей зависит от формата хешей и совместимости; безопасный сброс — не ошибка, а осознанное решение. Неизменность позиций в поиске не гарантируется. Сложные интеграции с внешними сервисами требуют отдельной проверки. Если в проекте есть юридические или персональные данные, границы их обработки согласуют с профильным специалистом.
Типичные ошибки: переносить сниппеты и чанки механически, без описания назначения; не фиксировать отказ от неиспользуемых полей; забыть про динамические адреса каталога и фильтров; проверять только главную страницу; переключать сайт без резервной копии и плана возврата; смешивать миграцию с переносом хостинга. Каждая из этих ошибок приводит к потерям, которые обнаруживаются уже после переключения.
Следующий шаг — согласовать карту сущностей и границы задачи, назначить ответственных и определить дату тестового прогона. После этого можно переходить к переносу данных и настройке адресов.
Можно ли перенести сайт с MODX на Битрикс без потери адресов?
Адреса можно сохранить, если заранее снять их полный список и подготовить редиректы для меняющихся. Технически адреса переносятся контролируемо.
Что делать с TV-параметрами, которые нигде не выводятся?
Решение принимает заказчик вместе с командой. Если поле не влияет на поведение и не используется, его можно не переносить, зафиксировав отказ письменно.
Переносятся ли пароли пользователей?
Зависит от формата хешей и совместимости. Если перенос невозможен, применяют безопасный сброс без рассылки паролей в открытом виде, согласовав это с заказчиком.
Входит ли перенос хостинга в миграцию с MODX на Битрикс?
Нет, это отдельная задача. Миграция касается контента, структуры, логики вывода и адресов. Перенос хостинга планируют отдельно, чтобы при сбое было понятно, что именно сломалось.
Как проверяют, что перенос прошёл успешно?
По чек-листу: адреса и редиректы, формы, каталог, пользователи, аналитика, отсутствие ошибок в журналах. Приёмку подтверждает заказчик, переключение выполняют с резервной копией и планом возврата.
Нужно ли переносить сниппеты и чанки как есть?
Нет. Сначала описывают их назначение, затем подбирают эквивалент в Битрикс или переписывают логику. Механический перенос часто приводит к скрытым ошибкам.
Практический разбор: проверка карты адресов и редиректов при переносе с MODX на Битрикс
Учебный разбор. Условный сайт на MODX: раздел «Услуги» с ресурсами «Консультация» (адрес /uslugi/konsultaciya.html) и «Аудит» (/uslugi/audit.html), у каждого ресурса заполнены поля заголовка и описания. На копии сайта на Битрикс эти же страницы должны открываться по тем же адресам, а старые адреса — вести на них. Вводное требование: адреса существующих страниц сохраняются без изменений.
| Действие | Что проверить |
|---|---|
| Сверить карту адресов: выписать адреса ресурсов из MODX и сопоставить с адресами соответствующих страниц на копии Битрикс. | Для «Консультации» и «Аудита» адреса совпадают посимвольно, включая расширение и регистр. |
| Проверить переход со старого адреса: открыть в браузере старый адрес ресурса на копии. | Страница открывается по новому адресу, в адресной строке виден целевой адрес, содержимое соответствует исходному ресурсу. |
| Проверить заголовок и описание: открыть свойства перенесённой страницы и сравнить с исходными значениями из MODX. | Заголовок страницы и описание совпадают с исходными; заголовок окна браузера заполнен. |
Для приёмки. Зафиксировать таблицу сопоставления: старый адрес, новый адрес, результат перехода, совпадение заголовка и описания. Таблицу приложить к акту приёмки как артефакт проверки адресов.
Ограничение. Разбор проверяет только сохранение адресов и полей заголовка/описания для двух статических страниц. Он не охватывает динамические материалы, каталог, права доступа и поведение при смене домена.
