5 мифов о MODX, в которые верят даже опытные разработчики (и почему это не так)
Каждый год MODX хоронят. Говорят, что он устарел, что у него сложная админка, что ExtJS — это прошлый век, а сообщество вымерло. Но система продолжает жить: выходят обновления ядра, появляются компоненты с интерфейсами на Vue, а в русскоязычном сообществе по-прежнему можно получить помощь от людей, которые годами работают с MODX.
Мы — команда разработчиков, которая работает с MODX больше 5 лет. Мы не идеализируем систему, мы знаем ее боли. Но мы устали читать одни и те же стереотипы от людей, которые не заглядывали в MODX со времен версии 2.2. Давайте разберем 5 главных мифов честно, без фанатизма.
1. «ExtJS — это мертвый стек, админка неудобная»
Миф: MODX использует устаревший ExtJS, поэтому админка выглядит как из 2010 года и её невозможно кастомизировать.
Реальность: Да, основной интерфейс manager MODX по-прежнему построен на ExtJS. Делать вид, что его там нет, было бы нечестно. Но ExtJS не ограничивает интерфейсы ваших компонентов: отдельные страницы и виджеты можно писать на Vanilla JS, React или Vue и встраивать в manager через штатные контроллеры и API. А в большинстве проектов переписывать админку целиком вообще не требуется — редакторам нужны понятные поля и удобные экраны для конкретных задач.
Практика: Возьмите MiniShop3: его современная административная часть использует **Vue 3 и PrimeVue**, хотя сам компонент, конечно, состоит не только из Vue — в нём есть PHP-ядро, API и клиентский JavaScript. А пакет VueTools даёт компонентам MODX 3 общий стек Vue, Pinia и PrimeVue, чтобы каждому разработчику не тащить собственную копию библиотек. ExtJS остаётся частью manager, но новые интерфейсы уже не обязаны быть написаны на нём.
2. «Нет нормального API, нельзя делать Headless»
Миф: MODX не подходит для современных SPA-приложений и мобильных приложений, потому что у него нет нормального API.
Реальность: Для MODX есть пакет mxApi, который даёт инфраструктуру публичного REST API: маршрутизацию, bearer-токены, права, журнал запросов и OpenAPI. Прикладные эндпоинты — например, выдачу страниц, каталога или личного кабинета — добавляет код проекта или отдельный провайдер. После этого данные можно отдавать в React, Next.js, Flutter или любой другой клиент без привязки к шаблонам MODX. А MiniShop3 уже включает Web API для корзины, заказа и покупателя.
Практика: Мы делали проект, где бэкенд на MODX отдавал данные через mxApi для Vue-приложения. Админка оставалась привычной для редакторов, а фронтенд был полностью изолирован. Это не попытка притвориться, что MODX — headless-first CMS. Это практичный способ сохранить его данные, права и manager, когда проекту нужен отдельный фронтенд.
3. «MODX не для сложной логики, только для визиток»
Миф: На MODX можно сделать только сайт-визитку или блог. Для интернет-магазина или сложного портала нужно брать Laravel/Bitrix.
Реальность: MODX не ограничивает проект визиткой или блогом: его модель данных, события, права доступа и PHP-код позволяют реализовать магазин, портал, личный кабинет или внутреннюю систему. Но это не обещание «установил — и всё заработало». Если вам нужна индивидуальная архитектура, MODX даёт много контроля — вместе с ответственностью за проектирование и поддержку решения.
Практика: MiniShop3 закрывает базовую механику e-commerce: товары, корзину, покупателей, оформление и управление заказами. Поверх него можно подключать эквайринг, CRM, доставку и проектную бизнес-логику — готовыми компонентами или собственной интеграцией. Да, это требует настройки и разработки. Зато архитектура не заставляет подгонять нестандартный магазин под жёсткий сценарий коробочного решения.
4. «У MODX нет сообщества, все ушли на Laravel»
Миф: MODX умер, потому что разработчики ушли в современные PHP-фреймворки.
Реальность: Сообщество MODX в РФ действительно небольшое. Но оно не исчезло: работают русскоязычный Telegram-чат, modx.pro, документация и репозитории компонентов. Здесь меньше случайного шума, а многие участники глубоко знают платформу и её экосистему.
Практика: По нашему опыту, в русскоязычном Telegram-чате и на modx.pro на конкретный технический вопрос нередко отвечают в тот же день. С ядром сложнее: пул-реквест может пройти быстро, а может ждать ревью месяцами — небольшой команде мейнтейнеров приходится вручную разбирать большой поток изменений. Это не самая быстрая модель разработки, но сообщество точно нельзя назвать вымершим.
5. «MODX — это легаси, разработка ядра замерла»
Миф: Код и настройки MODX живут в базе данных, поэтому проект невозможно нормально хранить в Git, тестировать и выкладывать через CI/CD. А само ядро уже не развивается.
Реальность: У этого стереотипа есть основание. Стандартный сценарий MODX действительно поощряет хранение элементов и части конфигурации в базе данных, а ручные изменения через manager сложно воспроизводить между окружениями. Если ничего не менять в процессе разработки, нормальный CI/CD сам собой не появится. Но это особенность стандартного workflow, а не непреодолимое ограничение платформы: код можно вынести в файлы и Git, а изменения структуры и данных оформлять миграциями.
Практика: mxMigrations позволяет хранить изменения базы и моделей в версионируемых миграциях и выполнять их через CLI, а MIGXPageConfigurator — генерировать конфигурации и шаблоны страниц в файлы, которые можно хранить в Git. Вместе с тестами, сборкой и CI-раннером это позволяет построить полноценный pipeline от коммита до выкладки.
Разработка самого ядра тоже не замерла: в 2026 году обновления получили и ветка MODX 3, и поддерживаемая ветка 2.8. Темп остаётся неспешным. Согласно политике проекта, мейнтейнеры используют AI как рабочий инструмент, но не делегируют ему окончательное ревью и принятие пул-реквестов. Ответственность остаётся на человеке, поэтому большой поток изменений разбирается вручную.
Заключение
MODX не идеален. Мы не призываем всех бежать и переписывать проекты. Но мы призываем перестать поливать его грязью, основываясь на стереотипах десятилетней давности.
Это рабочая, стабильная и гибкая платформа для проектов, где важны контроль над разметкой, моделью данных и серверной логикой, а возможностей конструктора или типовой CMS уже не хватает. Если вам близок такой подход — дайте MODX шанс. Посмотрите на него свежим взглядом. Возможно, вы удивитесь.
А если вы уже работаете с MODX и устали оправдываться — пересылайте эту статью коллегам. Хватит хоронить то, что еще живо.
А теперь давайте честно: в комментариях жду хейтеров с «птичками» и фанатов с «плюсами». У кого был негативный опыт — расскажите, мы не кусаемся. Аргументированный хейт важнее, чем бездумная похвала. Погнали!