Миграция на Joomla и интеграции: 1С, CRM, почта

Три типовых миграционных сценария

Меня зовут Евгений Семёнов, я технический директор ITfresh. Мы обслуживаем компании до 50 рабочих мест в Москве, держим собственные серверы в дата-центре МТС и за последние годы перенесли на Joomla не один десяток сайтов — со старых версий самой Joomla, с WordPress и из самописных движков разной степени запущенности. Эта статья — концентрат того, что мы узнали на этих проектах: где миграция проходит за пару дней, где превращается в квест, и как заранее понять, к какому сценарию готовиться. А во второй половине — то, ради чего сайт вообще переносят: интеграции с 1С, CRM и почтой.

Практически все обращения «перенесите нас на Joomla» укладываются в три сценария. У каждого своя цена, свои риски и свои маркеры «пора».

Сценарий 1: апгрейд легаси Joomla 3.x/4.x до 6.x

Самый частый запрос 2026 года. Joomla 3.x давно не получает патчей безопасности, и сайты на ней — открытая дверь: уязвимости в ядре и в старых расширениях известны, эксплойты автоматизированы, и вопрос взлома — это вопрос времени, а не вероятности. При этом таких сайтов в рунете всё ещё тысячи: сделали в 2016–2019, работает — не трогали.

Маркеры «пора мигрировать»:

• в админке версия начинается с 3 или 4 — обе ветки уже вне поддержки;
• хостер прислал письмо о повышении версии PHP, и сайт после этого падает;
• в почту сыплется спам «с вашего сайта рассылается рассылка» — классический симптом залитого шелла;
• нужные расширения перестали обновляться, а новые не ставятся на старое ядро.

Сценарий 2: переезд с WordPress, когда стало тесно

WordPress прекрасен для блога и лендинга, но у него есть потолок, в который упираются растущие компании. Типичные жалобы, с которыми к нам приходят: десять редакторов топчутся по чужим материалам, потому что штатная модель прав примитивна; двуязычный сайт держится на платном плагине, который конфликтует с половиной остальных; структура из сотен вложенных страниц управляется через боль. В Joomla разграничение прав (ACL), мультиязычность и вложенные категории — это ядро, а не плагины, и именно за этим с WordPress уходят.

Маркеры: больше 3–5 редакторов с разными зонами ответственности, два языка и больше, каталожная структура контента, счёт установленных плагинов перевалил за тридцать.

Сценарий 3: вытащить сайт из самописного движка

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

Маркеры: никто в компании не может внести правку без «того самого» подрядчика; движок не обновлялся годами; резервных копий нет или их никто не проверял; любая доработка оценивается в недели.

Апгрейд Joomla 3.x → 6.x: почему это миграция, а не обновление

Главное, что я объясняю клиентам на первой встрече: между Joomla 3 и Joomla 6 лежит смена поколений, и «нажать кнопку обновить» не получится. Официальный путь — цепочка 3.10 → 4.4 → 5.x → 6.x, и на каждом шаге ядро проверяет готовность через Pre-Update Check: версию PHP, базу данных, совместимость установленных расширений. Требования конечной точки жёсткие: Joomla 6 хочет PHP 8.3.0+ и MySQL 8.0.13+ либо MariaDB 10.4.0+. Сайт на 3.x обычно живёт на PHP 7.x — то есть параллельно с CMS мигрирует и весь серверный стек.

Ориентир по версиям на момент написания: актуальная — Joomla 6.1.2 (security-релиз от 7 июля 2026, вышел одновременно с 5.4.7 LTS и закрыл 12 уязвимостей). Сама ветка 6.1 «Nyota» стала стабильной 14 апреля 2026, а 6.2 ожидается примерно 13 октября 2026. Целиться при миграции имеет смысл сразу в свежую 6.1.x — прыгать через полгода ещё раз никто не захочет.

Главный блокер — расширения

Ядро по цепочке проходит достаточно предсказуемо. Ломается всё на расширениях. Наша статистика по типовому сайту на Joomla 3.x: из 15 установленных расширений 4–6 не имеют версий под Joomla 5/6. Это конструкторы контента (CCK), старые галереи, слайдеры, формы, SEO-плагины — их авторы либо забросили проекты, либо переписали продукт платно и с другой архитектурой.

Наша стратегия на этот случай отработана:

• Выпилить лишнее. На старых сайтах половина расширений либо выключена, либо дублирует друг друга. Каждое расширение, которое не переезжает, — минус час-другой работ и минус вектор атаки.
• Заменить возможностями ядра. Самая частая замена — кастомные поля (Custom Fields) вместо тяжёлых CCK: то, ради чего в 2017 ставили сторонний конструктор, ядро умеет само начиная с 3.7, а в шестёрке поля стали ещё гибче — вплоть до медиаполей.
• Для оставшегося — искать актуальные аналоги, и только в крайнем случае портировать старый код (это дорого и почти всегда не нужно).

Кейс: производственная компания, 1200 материалов

Показательный проект прошлого сезона: сайт производственной компании на Joomla 3.10 — 1200 материалов, каталог продукции на кастомных полях, 14 расширений. По плану: день на аудит и staging-прогон (на нём отвалились три расширения — старый слайдер, форма обратной связи и SEO-компонент), день на замену отвалившегося (слайдер — на возможности шаблона, форму — на современный конструктор, SEO — на связку ядро плюс редиректы), день на прогон по цепочке на бою, финальные проверки и снятие старых бэкапов. Итого три рабочих дня, контент и позиции в поиске не пострадали. Это типовой, хороший сценарий — но он стал таким именно потому, что staging показал все сюрпризы заранее.

Перенос контента с WordPress и самописных движков

Когда исходная система — не Joomla, встаёт вопрос переноса контента. Здесь важно сразу разделить: что переносится инструментами, а что — руками и скриптами.

Маппинг сущностей

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

С самописками универсальных инструментов нет по определению. Порядок такой: разбираем структуру базы старого движка, составляем таблицу соответствия «их сущность → материал/категория/кастомное поле Joomla», пишем одноразовый скрипт конвертации, прогоняем, проверяем выборочно и по счётчикам («в старой базе 840 товаров — в новой должно быть 840»).

SEO: таблица 301-редиректов обязательна

Самая дорогая ошибка миграции — потерять поисковый трафик. URL-структура почти наверняка изменится, и каждый старый адрес обязан отдавать 301-редирект на новый. Мы делаем это так: берём sitemap.xml старого сайта (или выгружаем список URL из поисковой консоли), скриптом генерируем таблицу соответствия «старый URL → новый URL», спорные случаи сводим руками, а результат кладём либо в правила веб-сервера, либо в компонент редиректов Joomla. После запуска пару недель следим за логами на предмет 404 — всегда всплывает десяток адресов, которых не было ни в одном sitemap.

Что не тащить с собой

• Мусорные шорткоды плагинов WordPress. Если в текстах остались конструкции вида [gallery id=...] от давно удалённых плагинов — их надо вычистить регулярками на этапе конвертации, иначе они так и будут торчать в текстах на новом сайте.
• Старые формы и их архивы заявок. Формы дешевле пересобрать на новом стеке, чем портировать; архив заявок при необходимости выгружается в таблицу и отдаётся клиенту отдельно.
• Дубли и черновики десятилетней давности. Миграция — лучший момент провести ревизию: на одном из переносов из 2400 «материалов» до нового сайта доехало 1100, и никто ни разу не вспомнил об остальных.

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

Теперь про то, что делает корпоративный сайт живым, — данные из учётной системы. Сразу честно: штатного обмена CommerceML, как у Битрикса, у Joomla нет. Битрикс и 1С — продукты одной экосистемы, их обмен «из коробки» — это их конкурентное преимущество, и врать, что в Joomla так же, я не буду. Но задача «каталог и цены с сайта всегда актуальны» решается, и решается надёжно.

Рабочая схема: выгрузка по расписанию + импорт скриптом

Проверенный на наших проектах поток выглядит так: 1С по расписанию выгружает номенклатуру, цены и остатки в CSV или XML → файл уезжает на сервер сайта по FTP или HTTP → cron на сервере запускает CLI-скрипт импорта → скрипт раскладывает данные в материалы и кастомные поля Joomla (или в таблицы e-commerce-компонента) через её API. Обновление раз в час или раз в ночь — по потребности бизнеса.

Почему именно файл + cron, а не онлайн-запросы сайта в 1С напрямую: учётная база — не то место, куда стоит пускать веб-сервер в реальном времени. Файловый обмен развязывает системы: 1С может быть за VPN, на обеде, на обновлении — сайт продолжает работать на последних загруженных данных. Для компаний нашего профиля (до 50 рабочих мест) этой асинхронности хватает в ста процентах случаев.

Если нужен полноценный магазин

Когда на сайте не просто каталог-витрина, а корзина и заказы, подключаются e-commerce-расширения: VirtueMart — ветеран с самой богатой функциональностью и самым тяжёлым характером; J2Store — изящное решение «магазин из обычных материалов Joomla», наш выбор для каталогов до пары тысяч позиций; EShop — крепкая середина. Для всех трёх существуют коннекторы к 1С у сторонних разработчиков, но их качество плавает, поэтому мы чаще держим свой слой импорта — он переживает обновления и не зависит от прихотей автора коннектора.

Лиды с сайта в CRM: Битрикс24, amoCRM, Planfix

Вторая по частоте интеграция: заявка с сайта должна мгновенно оказаться в CRM, а не в почтовом ящике, который менеджер проверяет по вдохновению.

Формы делаем либо на встроенных контакт-формах, либо — почти всегда на коммерческих проектах — на конструкторах Convert Forms или RSForm Pro: многошаговые сценарии, условные поля, свои обработчики. Передачу в CRM — Битрикс24, amoCRM, Planfix — строим на вебхуках с серверной стороны: обработчик формы после валидации отправляет данные HTTP-запросом в API CRM.

Почему серверная отправка, а не JS-виджет CRM

У каждой CRM есть готовый JS-виджет «вставьте код на сайт». Мы их на боевых проектах избегаем, и вот почему: виджет грузится с чужого CDN и тормозит страницу; при блокировках или сетевых проблемах CDN форма просто исчезает вместе с заявками; блокировщики рекламы режут чужие скрипты. Серверная отправка лишена всех трёх проблем: форма — ваша, рендерится вашим сервером, а CRM получает данные из бэкенда. Если API CRM недоступен — заявка не теряется, а уходит в очередь на повтор.

Антиспам и страховка

• PoW-капча из ядра. В Joomla 6.1 появилась встроенная proof-of-work капча без внешних сервисов: браузер посетителя решает вычислительную задачку невидимо для человека. Не нужны ни reCAPTCHA (привет, блокировки Google-доменов), ни сторонние подписки.
• Honeypot-поле — скрытое поле, которое человек не видит, а бот заполняет. Копеечный приём, отсекающий львиную долю примитивного спама.
• Логирование заявок в базу сайта. Обязательное правило наших внедрений: каждая заявка сначала пишется в локальную таблицу и только потом уходит в CRM. Упал вебхук, сменился токен, CRM на техработах — ни одна заявка не пропала, всё доотправляется из журнала.

REST API Joomla как основа интеграций

Мой любимый аргумент в пользу современной Joomla: REST API есть в ядре начиная с Joomla 4 — без плагинов и доработок. Авторизация — по токену через заголовок X-Joomla-Token (токен выпускается в профиле пользователя), эндпоинты имеют вид /api/index.php/v1/content/articles. Через API создаются и читаются материалы, категории, пользователи, значения кастомных полей — этого достаточно для большинства интеграционных задач.

Практический пример: автопубликация новостей из внутреннего портала

Живой сценарий с одного из наших проектов: новости компании пишутся во внутреннем портале, а на сайт попадают автоматически. Вся «интеграция» — один HTTP-запрос из скрипта портала:

curl -X POST "https://site.ru/api/index.php/v1/content/articles" \
  -H "Content-Type: application/json" \
  -H "X-Joomla-Token: ВАШ_API_ТОКЕН" \
  -d '{
    "title": "Компания открыла новый склад в Подольске",
    "alias": "novyy-sklad-podolsk",
    "catid": 14,
    "articletext": "<p>Полный текст новости...</p>",
    "state": 1,
    "language": "*"
  }'

Материал появляется в категории 14 в статусе «опубликовано». Тем же способом делается чтение: GET на тот же эндпоинт возвращает список материалов в JSON — на этом строятся выгрузки на сторонние витрины и в мобильные приложения.

Headless: Joomla как контент-бэкенд

Из наличия полноценного API следует приятная возможность: Joomla может работать headless — как чистый бэкенд контента, который по API отдаёт материалы мобильному приложению или фронтенду на React/Vue. Редакция работает в привычной удобной админке, а «морда» может быть какой угодно. Для компании, у которой есть и сайт, и приложение, это означает один источник контента вместо двух.

Почта, календари и обвязка: SSO, Telegram, карты

Несколько интеграций поменьше, которые превращают сайт из витрины в часть корпоративной инфраструктуры.

SSO через Active Directory

В ядре Joomla есть LDAP-плагин аутентификации, и для нашего типового клиента — компания с Active Directory на 20–50 человек — это готовое SSO для закрытых разделов: сотрудник входит в интранет-раздел сайта под своей доменной учёткой. Уволили человека — отключили в AD — доступ к сайту умер сам, без отдельного «а ещё удалите его на сайте». На внедрение с тестами закладываем 4–8 часов, из них половина обычно уходит на согласование сервисной учётки и сетевой доступности контроллера домена.

Новости и вакансии в Telegram-канал

Схема, которую мы ставим почти всем: опубликованный на сайте материал автоматически улетает в Telegram-канал компании через Bot API. Реализация — маленький плагин на событие публикации или cron-скрипт, который забирает свежие материалы через тот же REST API и постит анонсы со ссылками. Отдел маркетинга публикует в одном месте, канал живёт сам. То же самое работает для вакансий.

Карты: Яндекс вместо Google

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

Смета и сроки: сколько это стоит в часах

Финальный раздел — про деньги, точнее про часы, из которых деньги складываются. Цифры ниже — из наших реальных смет; это диапазоны для типовых сайтов до нескольких тысяч материалов, без эксклюзивного дизайна.

Что удорожает проект

• Кастомные расширения без версий под Joomla 5/6 — каждое такое либо заменяется (часы), либо портируется (десятки часов).
• Дизайн. «Перенесите один в один» на новом шаблонизаторе — это отдельная работа, иногда сопоставимая со всей миграцией. Часто дешевле и полезнее взять современный шаблон и адаптировать под фирменный стиль.
• Объём и качество контента. Пять тысяч материалов с картинками, вставленными абсолютными ссылками на старый домен, — это не пять тысяч строк в скрипте, а неделя чистки.

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

Если суммировать: типовой проект «апгрейд плюс базовые интеграции» — это 2–4 недели календарного времени при 40–80 часах работ. Не бесплатно, но это разовая инвестиция, после которой у вас поддерживаемая CMS с патчами безопасности, живыми данными из 1С и заявками, которые не теряются по дороге в CRM.