Доработка сайта на платформе MODX может затрагивать не только внешний вид страниц. В MODX логика сайта часто распределена между шаблонами, чанками, сниппетами, плагинами, TV-полями, компонентами и собственным PHP-кодом. Поэтому даже небольшую на первый взгляд задачу сначала полезно локализовать: понять, где именно реализована нужная функция и какие части сайта от неё зависят.
Ниже разберём, какие доработки встречаются чаще всего и как вносить их так, чтобы новая функция не сломала уже работающий сайт.
Что можно доработать на сайте MODX
MODX позволяет собирать довольно разные проекты — от корпоративного сайта до каталога или интернет-магазина. Поэтому понятие «доработать MODX» может означать совершенно разные задачи.
Чаще всего изменения относятся к одной из нескольких областей.
Шаблоны и внешний вид страниц
В MODX структура страницы обычно собирается из нескольких элементов. Шаблон задаёт общий каркас, повторяющиеся блоки могут находиться в чанках, а отдельные значения — в полях ресурса и TV.
Поэтому для задачи вроде:
- добавить новый блок на страницу;
- изменить шапку или подвал;
- сделать новый тип посадочной страницы;
- перестроить карточку товара;
- добавить дополнительные поля;
- изменить мобильную версию;
сначала нужно определить, какой именно элемент формирует нужную часть страницы.
Прямая правка одного HTML-фрагмента иногда решает задачу, но на старом проекте этот же фрагмент может использоваться в нескольких шаблонах или вызываться через общий чанк. В таком случае локальная правка неожиданно меняет десятки страниц.
TV-поля и управляемый контент
Template Variables, или TV, используются в MODX как дополнительные поля ресурса.
Через них удобно вынести в административную панель то, что раньше было жёстко прописано в шаблоне: изображение, подпись, цену, ссылку, дополнительный текст, переключатель состояния блока и другие параметры.
Например, вместо ручного изменения разметки можно сделать редактируемыми:
- баннер на странице;
- характеристики услуги;
- изображение категории;
- дополнительные контакты;
- кнопку и её ссылку;
- параметры карточки товара;
- отдельные SEO- или служебные поля.
При доработке существующего сайта важно проверить, как TV уже связаны с шаблонами и ресурсами. Создание ещё одного поля само по себе не гарантирует, что оно будет правильно отображаться во всех нужных контекстах.
Сниппеты, чанки и собственная логика
Динамические функции сайта часто реализованы через сниппеты. Они могут получать данные, строить меню и списки, обрабатывать параметры, обращаться к базе или выполнять другую PHP-логику.
Чанки обычно используют для повторяемой разметки: карточек, форм, элементов меню, писем и других шаблонных блоков.
Поэтому задача «немного изменить вывод» иногда оказывается изменением связки:
сниппет → параметры вызова → данные → чанк вывода → CSS/JavaScript.
Перед правкой полезно определить эту цепочку целиком. Иначе можно исправить отображение в одном месте и получить другую ошибку на странице, где тот же элемент вызывается с другими параметрами.
Формы и отправка заявок
На сайтах MODX для форм часто используется FormIt.
Он может выполнять валидацию полей и запускать hooks после успешной проверки: например, отправить письмо, сохранить данные или выполнить дополнительное действие.
В рамках доработки формы может потребоваться:
- добавить или удалить поля;
- изменить обязательность и правила проверки;
- поменять получателя;
- настроить письмо;
- добавить CAPTCHA;
- изменить сообщение после отправки;
- сделать перенаправление;
- подключить собственный hook;
- передать заявку во внешний API или CRM.
Если пользователь нажимает кнопку, форма визуально отправляется, но письмо не приходит, проблема необязательно находится в самой форме. Нужно разделять как минимум три этапа:
- дошёл ли POST-запрос до обработчика;
- прошла ли валидация и выполнились ли hooks;
- смог ли сервер фактически отправить письмо.
Так можно отличить ошибку FormIt от проблемы SMTP, настроек почты или ограничений хостинга.
Каталог и интернет-магазин на miniShop2
Для интернет-магазинов на MODX часто используется miniShop2.
Доработка такого проекта может касаться:
- каталога;
- карточки товара;
- характеристик;
- вариантов товара;
- цены;
- корзины;
- оформления заказа;
- доставки;
- способов оплаты;
- уведомлений;
- административной части;
- интеграции с внешними системами.
Здесь особенно важно не начинать с изменения шаблона корзины или карточки вслепую. Нужно определить, какая часть относится к стандартной логике компонента, какая реализована дополнительным расширением, а какая была написана специально для конкретного сайта.
На старых проектах эти уровни нередко смешаны.
Интеграции MODX с CRM, API и внешними сервисами
MODX можно связать с внешней системой через PHP-код, собственный компонент, сниппет, plugin или API конкретного сервиса.
Типичные задачи:
- передавать заявки в CRM;
- отправлять данные в Telegram;
- получать остатки или цены из внешней системы;
- синхронизировать каталог;
- подключить платёжный сервис;
- получать данные по API;
- запускать webhook;
- передавать информацию о заказах.
Перед такой доработкой нужно определить не только формат запроса, но и поведение при ошибках.
Например, что произойдёт, если внешний API временно недоступен? Пользователь не должен потерять заявку только потому, что сторонний сервис ответил с ошибкой.
Поэтому для интеграций важно предусматривать обработку неуспешных ответов, логирование и возможность повторной обработки там, где это необходимо.
ЧПУ, ссылки и редиректы
Изменение структуры URL в MODX затрагивает не только aliases ресурсов.
Friendly URLs зависят одновременно от настроек самой CMS и rewrite-конфигурации веб-сервера. Поэтому после переноса сайта, смены домена или переработки структуры могут возникать:
- 404;
- неправильные URL;
- циклические редиректы;
- ссылки на старый домен;
- проблемы со страницами разделов;
- неверная генерация внутренних ссылок.
Если сайт уже получает поисковый трафик, изменение URL нужно делать особенно аккуратно: старые адреса не следует просто уничтожать без проверки необходимых редиректов.
Административная панель и права пользователей
MODX позволяет разграничивать права через группы пользователей, роли и Access Policies.
Это удобно, когда редактору контента нужно дать доступ только к определённым разделам сайта, а технические настройки оставить закрытыми.
В рамках доработки можно настроить, например:
- доступ редактора только к нужным ресурсам;
- отдельную группу менеджеров;
- запрет изменения системных элементов;
- разные права для разных разделов;
- доступ к конкретным компонентам.
При работе с правами важно учитывать, что неправильная ACL-настройка способна создать очень неприятную ситуацию: пользователь существует, авторизуется, но не видит нужный раздел или, наоборот, получает больше возможностей, чем предполагалось.
Обновление старого сайта MODX
Доработка старого MODX-проекта часто начинается с вопроса: нужно ли сначала обновлять саму CMS.
Универсального ответа нет.
Если сайт работает на старой версии MODX Revolution, нельзя просто заменить ядро последней версией и рассчитывать, что весь существующий код продолжит работать.
Особенно внимательно нужно проверять:
- версию MODX;
- версию PHP;
- установленные Extras;
- собственные сниппеты и плагины;
- custom-компоненты;
- старые API-вызовы;
- серверное окружение.
При переходе с MODX 2.x на 3.x есть несовместимые изменения в ядре и API. Кроме того, актуальная ветка MODX 3.2+ требует PHP 8.1 или новее.
Поэтому обновление ядра и функциональная доработка — это связанные, но не всегда одинаковые задачи.
Иногда безопаснее сначала исправить конкретную функцию на существующей совместимой конфигурации, а обновление CMS вынести в отдельный этап. В другом проекте, наоборот, именно устаревшее окружение мешает корректно внедрить новую функцию.
Решение принимается после проверки конкретного сайта.
Почему перед доработкой нужен резервный экземпляр
Даже если изменение кажется небольшим, перед работой желательно иметь актуальную копию файлов и базы данных.
Для старого MODX-проекта это особенно важно, потому что часть логики может находиться:
- в базе;
- в Elements;
- в файлах;
- внутри установленного Extra;
- в собственном компоненте;
- в системных настройках.
Одной копии изменяемого PHP-файла недостаточно, если задача затрагивает структуру данных или конфигурацию компонента.
Для заметных изменений безопаснее сначала проверить результат на отдельной копии или staging-среде, а затем переносить принятую правку на рабочий сайт.
Как проходит доработка сайта на MODX
Рабочий порядок зависит от задачи, но обычно выглядит примерно так.
1. Фиксируется требуемый результат
Не «поправить форму», а, например:
После отправки формы нужно проверить телефон, сохранить заявку и передать её в CRM. При недоступности CRM заявка не должна теряться.
Чем конкретнее результат, тем меньше вероятность переделок.
2. Определяется текущая реализация
Проверяется:
- версия MODX;
- используемый шаблон;
- Elements;
- установленные компоненты;
- custom-код;
- JavaScript;
- серверная конфигурация, если она относится к задаче.
На этом этапе становится понятно, куда действительно нужно вносить изменение.
3. Проверяются зависимости
Если правится FormIt, miniShop2 или другой Extra, нужно учитывать его конфигурацию и связанные дополнения.
Если меняется собственный сниппет — определить, откуда он вызывается.
Если меняется общий чанк — выяснить, сколько страниц его используют.
4. Создаётся резервная копия
Минимум — то, что позволяет вернуть сайт к рабочему состоянию при неудачной правке.
При обновлениях MODX резервная копия файлов и базы особенно важна.
5. Выполняется изменение и проверяются связанные сценарии
Проверяется не только страница, где была замечена проблема.
Например, после доработки формы стоит проверить:
- корректную отправку;
- ошибочную отправку;
- обязательные поля;
- мобильную версию;
- письмо;
- повторную отправку;
- работу CAPTCHA;
- внешний сервис, если он подключён.
6. Изменение переносится на рабочий сайт и проверяется повторно
После публикации важно убедиться, что production-окружение не отличается от тестового критичным параметром: версией PHP, настройками почты, правами файлов или конфигурацией веб-сервера.
Какие задачи можно объединить, а какие лучше разделить
Если на MODX накопилось много небольших правок, их часто удобно выполнять одним пакетом.
Например:
- добавить два поля;
- поправить мобильное меню;
- изменить шаблон письма;
- добавить блок на карточку;
- скорректировать отображение каталога.
Но большое обновление MODX, перенос сервера или переработку интернет-магазина лучше не смешивать с десятком независимых мелочей в одну непрозрачную задачу.
Так проще проверить результат и понять источник ошибки, если она появится.
Что подготовить перед доработкой MODX
Чтобы быстрее оценить задачу, полезно собрать:
- адрес сайта;
- список нужных изменений;
- ссылки на страницы, которых касается задача;
- примеры ожидаемого результата;
- информацию о том, что уже пытались изменить;
- сведения об ошибке, если она есть.
Для технических работ дополнительно могут потребоваться доступ к MODX Manager, файлам сайта, базе данных или серверу. Набор доступов зависит от конкретной задачи — передавать всё подряд заранее не требуется.
Можно ли доработать старый MODX-сайт без полной переделки
Во многих случаях — да.
Если текущая архитектура сайта остаётся пригодной для задачи, нет необходимости полностью создавать проект заново только ради новой формы, блока, интеграции или изменения каталога.
Но сначала нужно проверить техническое состояние проекта.
Полная переработка может оказаться разумнее, если сайт сильно зависит от неподдерживаемых компонентов, несовместимого PHP, большого объёма устаревшего custom-кода или архитектуры, в которой любое изменение постоянно ломает соседние функции.
Это определяется после диагностики, а не только по возрасту сайта.
Что важно при доработке MODX
Хорошая доработка — это не просто ситуация, когда новая кнопка появилась на странице.
После изменения должны сохраниться:
- существующая функциональность;
- управляемость сайта через MODX Manager;
- корректная работа на мобильных устройствах;
- совместимость используемых компонентов;
- возможность дальнейшей поддержки проекта.
Особенно это важно для старых сайтов, где одна функция могла несколько раз дорабатываться разными разработчиками.
Поэтому сначала стоит понять существующую реализацию, а уже затем менять её.
FAQ
Можно ли доработать существующий сайт на MODX без создания нового?
Да. Если архитектура проекта позволяет внести требуемые изменения безопасно, можно изменить отдельные функции, шаблоны, формы, каталог или интеграции без полной разработки сайта заново.
Можно ли доработать сайт на старой версии MODX?
Можно, но сначала нужно проверить версию MODX, PHP, установленные Extras и custom-код. Иногда задача решается на текущей версии, а иногда сначала требуется подготовка к обновлению окружения.
Нужно ли обновлять MODX перед любой доработкой?
Нет. Обновление не является обязательным условием каждой правки. Необходимость зависит от текущей версии сайта, совместимости компонентов и самой задачи.
Можно ли изменить форму заявки на MODX?
Да. Можно менять поля, валидацию, получателей, шаблоны писем, hooks и интеграции. Если используется FormIt, перед изменением нужно проверить его текущий вызов и связанные настройки.
Можно ли доработать магазин на miniShop2?
Да. Доработка может затрагивать каталог, карточки товаров, корзину, заказ, доставку, оплату и связанные расширения. Конкретный способ зависит от установленной версии и структуры проекта.
Можно ли перенести MODX-сайт на другой сервер и одновременно его доработать?
Можно, но перенос и функциональные изменения лучше разделять на понятные этапы. Сначала нужно проверить совместимость серверного окружения и убедиться, что перенесённая версия сайта работает корректно, после чего вносить остальные изменения.
Нужна доработка сайта на MODX?
Поможем доработать существующий сайт на MODX: формы, шаблоны, каталог, miniShop2 и интеграции.
↑ К оглавлению