Миграция на MODX и интеграции с бизнес-системами: 1С, CRM, формы и переезд с WordPress или MODX 2.x

У вас старый сайт на MODX — что делать: карта решений

Меня зовут Евгений Семёнов, я технический директор ITfresh. Мы обслуживаем московские компании до пятидесяти рабочих мест, держим собственные серверы в дата-центре МТС и за пятнадцать с лишним лет перевезли на новые движки не один десяток клиентских сайтов. Эта статья — практическое продолжение моего обзора MODX Revolution 3.2: там я объяснял, почему мы ставим клиентам эту CMS, здесь расскажу, как мы на неё переезжаем и что подключаем после переезда — 1С, CRM, почту, аналитику.

Начну с самого частого запроса: «у нас уже сайт на MODX, но старый». Первым делом выясняем, на чём именно он работает, — под словом «MODX» скрываются три разные истории.

Evolution, Revolution 2.x и почему обе ветки — чемодан без ручки

MODX Evolution — это давно отделившийся форк, который сегодня развивается как самостоятельный проект Evolution CMS и к актуальному MODX Revolution отношения не имеет. Отличить его просто: у Evolution админка выглядит архаично, дерево ресурсов и системные настройки устроены иначе, а версии нумеруются своей линейкой. Прямого «апгрейда» с Evolution на Revolution не существует в принципе — это всегда перенос контента на новый движок.

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

Апгрейд 2.x → 3.x: что переезжает само, а что ломается

Хорошая новость: база данных, ресурсы, шаблоны, чанки и TV-параметры при апгрейде на MODX 3 переезжают штатно. Ломается обычно другое — код. Сниппеты, написанные под старый API, кастомные плагины, обращающиеся к переименованным классам ядра, и древние компоненты, которых в версии для 3.x просто нет. Поэтому перед любым апгрейдом мы делаем аудит по чек-листу:

• полный список установленных пакетов и проверка каждого на наличие версии под MODX 3;
• поиск кастомных сниппетов и плагинов, написанных вне пакетов, — их код смотрим руками;
• версия PHP на хостинге: MODX 3.2 требует PHP от 8.1 до 8.5, и старый сервер может не потянуть;
• копия сайта на тестовом поддомене — апгрейд сначала прогоняем там, боевой сайт не трогаем;
• замер битых страниц до и после: карта сайта, консоль вебмастера, скрипт-обходчик.

Когда честнее пересобрать заново

Если сайту больше восьми лет, вёрстка табличная, половина компонентов заброшена, а дизайн всё равно стыдно показывать — тащить наследие дороже, чем пересобрать. Мы прямо говорим клиенту: апгрейд обойдётся в столько-то часов археологии, пересборка на чистом MODX 3.2 с pdoTools 3 — в столько-то, и во втором случае вы получаете современный сайт, а не законсервированные проблемы. Примерно в трети случаев клиенты выбирают пересборку — и ещё ни один не пожалел.

Переезд с WordPress на MODX: когда это оправдано и как мы это делаем

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

1. Плагинный балласт тормозит сайт. Два десятка плагинов, каждый тянет свои скрипты, страница отдаётся по три-четыре секунды, и никакой кеш это не лечит.
2. Сайт ломали, и не раз. Почти всегда — через заброшенный плагин. После второго лечения дешевле переехать, чем дежурить у мусоропровода.
3. Нужен нестандартный каталог. Товары с хитрыми связями, фильтры по десятку параметров, цены из 1С — на WordPress это костыли поверх костылей, на MODX это штатная задача.

Перенос контента

Контент из WordPress выгружается штатным экспортом или напрямую из базы. Дальше мы пишем скрипт заливки через API MODX: каждая запись становится ресурсом, рубрики превращаются в ветки дерева, метаполя — в TV-параметры. Картинки переносим с сохранением путей либо с таблицей соответствий. На сайте до пятисот страниц эта часть занимает два-три дня работы, дальше время растёт почти линейно.

Сохранение SEO: редиректы 301

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

Реализуем редиректы на уровне nginx — это быстрее и надёжнее, чем плагины и сниппеты:

# /etc/nginx/conf.d/redirects-map.conf
map $request_uri $redirect_target {
    default                          "";
    /category/uslugi/                /uslugi/;
    /2023/05/kak-vybrat-server/     /blog/kak-vybrat-server.html;
    /?p=123                          /uslugi/podderzhka.html;
    ~^/tag/                          /blog/;
}

# в блоке server {} сайта:
if ($redirect_target) {
    return 301 $redirect_target;
}

После запуска две недели следим за консолями вебмастеров: смотрим отчёты об ошибках 404, добиваем пропущенные адреса, проверяем, что метатеги и заголовки перенесены один в один. Наш норматив по всему циклу: сайт до пятисот страниц переезжает с WordPress на MODX за две-три недели, включая редиректы и приёмку.

Миграция с самописных движков и конструкторов — самый частый кейс

Как ни странно, чаще всего к нам приходят не с WordPress, а с самописом. Сайт делал «знакомый программист» лет десять назад, программист уехал, исходники частично утеряны, админки нет или она не работает. Второй вариант — конструктор, из которого бизнес вырос: экспорта нет, доступ к базе не дают по определению.

Инвентаризация, когда нет ни экспорта, ни базы

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

Дальше механика та же, что и с WordPress: маппинг разделов на дерево ресурсов, скриптовая заливка через API, таблица редиректов. Разница в том, что у самописа адреса бывают совсем дикими — с параметрами, идентификаторами, дублями одной страницы по трём URL. Каждый такой случай разбираем отдельно, а дубли склеиваем на один канонический адрес.

Чему нас научили переезды legacy-сайтов

Главный урок: всегда находится страница, о которой все забыли. Калькулятор в подпапке, старая акция, на которую до сих пор ссылается партнёр, форма, письма с которой уходили на уволенного сотрудника. Поэтому мы не верим на слово «да там страниц двадцать» — обходчик регулярно находит двести. Второй урок: у самописов часто нет разделения контента и вёрстки, и «перенести текст» означает выковырять его из HTML руками или регулярными выражениями. Третий: заказчик почти никогда не помнит все точки входа — старые рекламные ссылки, QR-коды на визитках, подписи в почте. Мы просим выгрузку из рекламных кабинетов и смотрим статистику заходов за год, чтобы редиректы накрыли и эти хвосты.

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

Интеграция с 1С: каталог, цены и остатки на сайте

Вторая половина статьи — про то, ради чего малый бизнес обычно и затевает переезд: чтобы сайт перестал быть визиткой и начал работать с бизнес-системами. Начнём с 1С, потому что этот вопрос звучит на каждом втором пресейле: «а каталог из 1С сам обновляться будет?»

miniShop2, MiniShop3 и обменные компоненты

Каталог и корзину на MODX закрывает miniShop2 — зрелое магазинное решение, ветка 4.4.x которого штатно работает на MODX 3. Для новых проектов есть MiniShop3 — переписанный наследник под PHP 8.2+ и pdoTools 3.x, при этом совместимый с miniShop2 по сниппетам и чанкам, так что накопленные наработки не выбрасываются. Сам pdoTools 3.0.3 — бесплатный, это фактически стандартный набор инструментов вывода данных в экосистеме MODX.

Обмен с 1С:УТ или 1С:УНФ мы строим двумя способами. Первый — готовые обменные компоненты с modstore (mSync и аналоги): они принимают выгрузку номенклатуры, цен и остатков из 1С и раскладывают её по товарам miniShop2. Ставятся быстро, покрывают типовой сценарий «каталог ведём в 1С, сайт — витрина». Второй способ — самописный коннектор на процессорах MODX: когда у клиента нетиповая конфигурация 1С, хитрые правила ценообразования или нужно гонять данные в обе стороны. В MODX 3 с его Composer-пакетами и PSR-совместимым ядром такой коннектор пишется как нормальное современное PHP-приложение, а не как заплатка.

Расписание обмена и большие каталоги

Типовой режим — полная выгрузка ночью и лёгкие обновления цен и остатков днём по расписанию, раз в час или чаще. Проблемы начинаются после десяти тысяч позиций: полная выгрузка на каждый чих — это часы работы и нагрузка на сервер. Лечится очередями и частичной выгрузкой: 1С отдаёт только изменённые позиции, сайт обрабатывает пакет порциями в фоне, а не в момент запроса. Это вопрос настройки, а не подвиг, но о нём надо думать до запуска, а не после первой «встал сайт, пока грузился прайс».

Честное ограничение

Скажу прямо: MODX с miniShop2 отлично живёт на каталогах до десятков тысяч позиций. Если у вас сотня тысяч SKU, склады в пяти городах, маркетплейсы и программа лояльности — это уже не задача универсальной CMS, пора смотреть на специализированные торговые платформы. Мы в таких случаях так и говорим, потому что потом этот сайт обслуживать нам.

Лиды с сайта в CRM без потерь

Форма, письма с которой падают в общий ящик и там умирают, — это не интеграция, это имитация. Правильная схема: заявка с сайта сразу становится лидом в CRM с источником, меткой и телефоном, а почта остаётся резервным каналом.

FormIt-хуки: заявка → REST → сделка

Формы на MODX мы делаем на FormIt — это бесплатный компонент, и его главная сила в хуках: после успешной отправки формы можно выполнить произвольный код. Именно хуком мы отправляем заявку во внешнюю CRM — Битрикс24, amoCRM или Planfix, у всех троих есть REST API либо вебхуки. Цепочка выглядит так: форма → хук FormIt → HTTP-запрос к CRM → новый лид у менеджера. Вот рабочий скелет хука для отправки лида по входящему вебхуку:

<?php
/* сниппет sendToCrm — вызывается в &hooks=`spam,email,sendToCrm` */
$fields = $hook->getValues();
$payload = ['fields' => [
    'TITLE'      => 'Заявка с сайта: ' . $fields['name'],
    'PHONE'      => [['VALUE' => $fields['phone'], 'VALUE_TYPE' => 'WORK']],
    'COMMENTS'   => $fields['message'],
    'UTM_SOURCE' => $fields['utm_source'] ?? '',
    'UTM_CAMPAIGN' => $fields['utm_campaign'] ?? '',
]];
$ch = curl_init('https://portal.vashdomen.ru/rest/12/XXXXXX/crm.lead.add.json');
curl_setopt_array($ch, [
    CURLOPT_POST => true,
    CURLOPT_POSTFIELDS => http_build_query($payload),
    CURLOPT_RETURNTRANSFER => true,
    CURLOPT_TIMEOUT => 5,
]);
curl_exec($ch);
if (curl_errno($ch)) {
    $modx->log(modX::LOG_LEVEL_ERROR, 'CRM hook: ' . curl_error($ch));
}
curl_close($ch);
return true; /* форму не валим, даже если CRM прилегла */

Обратите внимание на две мелочи, которые отличают рабочую интеграцию от студенческой: таймаут в пять секунд, чтобы зависшая CRM не подвешивала отправку формы, и return true в любом случае — заявка уйдёт на почту резервным письмом, а ошибка останется в логе, по которому мы её потом разберём.

Защита от спама

Без защиты интеграция превращается в мусоропровод: боты зальют CRM сотнями пустых лидов, и менеджеры перестанут ей верить. Минимальный набор: honeypot-поле (скрытое поле, которое человек не заполнит, а бот заполнит), проверка времени заполнения формы и капча на формах, куда спам всё-таки пролез. FormIt позволяет повесить всё это отдельными хуками до отправки в CRM — спам отсекается раньше, чем доходит до менеджера.

Дубли и UTM-метки

Чтобы реклама была измеримой, в каждую форму мы прокидываем скрытые поля с UTM-метками из адреса страницы — они уезжают в CRM вместе с лидом, и в отчётах видно, какая кампания приводит заявки, а какая сжигает бюджет. Дубли ловим на стороне CRM по телефону: повторная заявка прикрепляется к существующему контакту, а не плодит клонов.

Почта, уведомления и внешние сервисы

Классика жанра: форма работает, интеграция работает, а письма-уведомления падают в спам. Причина почти всегда одна — сайт шлёт почту через PHP-функцию mail() с хостинга, у которого нет ни репутации, ни правильных записей в DNS.

Свой SMTP вместо mail()

Мы всегда переводим отправку на полноценный SMTP: либо корпоративный почтовый сервер клиента, либо наш почтовый сервер в дата-центре. Обязательный минимум — записи SPF и DKIM для домена, с которого уходят письма: SPF говорит миру, каким серверам разрешено слать почту от вашего имени, DKIM подписывает каждое письмо криптографической подписью. В MODX параметры SMTP задаются в системных настройках, и вся почта движка — уведомления форм, служебные письма — уходит через нормальный сервер. После этой процедуры «письма не доходят» из еженедельной жалобы превращается в закрытый вопрос.

Отдельный совет из практики: адрес отправителя и адрес получателя уведомлений не должны совпадать — часть почтовых систем режет такие письма как подделку. Шлите с no-reply@вашдомен на рабочие ящики менеджеров, а копию — в CRM, если она умеет принимать почту.

Метрика, карты и виджеты — без убийства скорости

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

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

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

REST API MODX и кастомные интеграции

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

Коннектор на процессорах MODX

В MODX любое действие — от создания ресурса до смены статуса товара — оформлено как процессор: маленький класс с одной обязанностью. Кастомная интеграция собирается из этих же кирпичей: мы поднимаем REST-эндпоинт, который принимает данные извне, валидирует их и дёргает штатные процессоры движка. Плюс подхода в том, что мы не лезем в ядро и не пишем параллельную логику: права, проверки и события MODX отрабатывают так же, как при ручной работе в админке.

Ветка 3.x здесь заметно упростила жизнь: ядро PSR-совместимо, зависимости ставятся Composer-пакетами, и коннектор оформляется как обычный современный PHP-проект — с автозагрузкой, тестами и понятной структурой. Любой квалифицированный разработчик, открыв такой код через год, разберётся в нём за вечер. С самописными интеграциями на движках десятилетней давности это, мягко говоря, не так.

Пример из практики: расписание специалистов

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

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

Смета и сроки: три сценария миграции с интеграциями

Свожу всё в цифры. Вилки ниже — из наших реальных смет 2026 года для сайтов малого бизнеса; каталог, нестандартные интеграции и объём контента сдвигают их вверх, простые визитки — вниз. Все сценарии включают базовый набор: перенос контента, редиректы 301, формы с отправкой в CRM, настройку почты через SMTP и приёмку по чек-листу.

Интеграция с 1С через обменный компонент добавляет к любому сценарию от 40 тыс. ₽ и от трёх дней; самописный коннектор считается отдельно по объёму. Дизайн в этих вилках — адаптация существующего; полная переотрисовка макета оценивается отдельным этапом.

Чек-лист приёмки миграции: 10 пунктов

Приёмку мы проводим по формальному списку — и советую требовать того же от любого подрядчика, даже если это не мы:

1. Все страницы из описи перенесены, выборочная сверка контента глазами пройдена.
2. Таблица редиректов 301 закрывает все старые адреса, включая параметры и картинки.
3. Метатеги, заголовки и разметка перенесены один в один, карта сайта обновлена и отдана поисковикам.
4. Ошибки 404 в консолях вебмастеров отслеживаются, план добивки пропущенных адресов есть.
5. Формы отправляются, лид появляется в CRM с UTM-метками, резервное письмо приходит.
6. Спам-защита работает: тестовый бот-запрос до CRM не доходит.
7. Почта уходит через SMTP, записи SPF и DKIM для домена проверены, тестовые письма во «Входящих», а не в спаме.
8. Обмен с 1С прогнан на боевых данных: цены, остатки и новые позиции доехали до витрины.
9. Скорость страниц замерена до и после — после переезда она обязана вырасти.
10. Резервные копии настроены, доступы переданы клиенту, регламент сопровождения подписан.

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