Открытое письмо руководству MODX и команде MODX Revolution (Русская версия)

Всем привет!

Сегодня на официальном форуме сообщества я опубликовал Открытое письмо руководству MODX и команде MODX Revolution.

Ниже его переведенный вариант.

От сообщества разработчиков и пользователей MODX

Мы обращаемся к руководству MODX и команде, отвечающей за развитие MODX Revolution.

Это письмо не про конфликт и не про противостояние «сообщество против MODX».

Наоборот.

Мы хотим, чтобы MODX продолжал жить, развиваться и оставался современной платформой, на которой можно строить реальные проекты.

Но сегодня между желанием сообщества развивать MODX и существующим процессом разработки образовался серьёзный разрыв.

Что происходит сейчас

MODX Revolution остаётся работоспособной и востребованной системой.

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

В официальном репозитории находится большой backlog Pull Requests и Issues.

При этом важно отметить: разработка полностью не остановлена. Появляются новые PR, исправления и релизы.

Проблема в другом.

Проблема в том, как работа сообщества превращается в решения и официальные релизы.

Разработчики есть.
PR есть.
Идеи есть.
Готовность тестировать, исправлять и поддерживать код есть.

Но отсутствует достаточно предсказуемый процесс, который превращает эту работу в регулярное развитие MODX.

Нам нужен публичный roadmap

Вопрос roadmap поднимается сообществом не первый год.

В феврале 2026 года на форуме MODX была открыта отдельная дискуссия о будущем MODX, roadmap и release cycle.

В ней обсуждались:

отсутствие публичного roadmap;
необходимость понятного процесса работы с PR;
регулярные релизы;
возможность более активного участия сообщества;
необходимость распределения ответственности за review и releases.

Прошло полгода.

И многие из этих вопросов по-прежнему остаются актуальными.

Нам необходимо понимать:

куда движется MODX Revolution;
какие задачи являются приоритетными;
что планируется сделать в ближайшие 6–12 месяцев;
какие изменения считаются стратегическими;
что будет происходить с ExtJS и Manager API;
как будет развиваться API и backend-инфраструктура;
как будет развиваться frontend;
какие MAB-рекомендации остаются актуальными;
какие из них уже реализованы;
какие были отменены или заменены;
какой будет модель дальнейшего развития MODX 3.x.

Roadmap не обязан быть идеальным.

Он может меняться.

Но его отсутствие создаёт гораздо большую проблему:

сообщество не понимает, куда направлять свои силы.

PR не должны месяцами находиться в неопределённости

Открытый Pull Request — это уже работа разработчика.

Кто-то потратил время на анализ проблемы, написал код, подготовил тесты, оформил PR и готов отвечать на замечания.

Если PR не соответствует направлению проекта — его можно закрыть.
Если решение неправильное — его можно отклонить.
Если необходимы изменения — их можно запросить.
Если решение хорошее — его можно принять.

Любое из этих решений лучше многомесячного отсутствия решения.

Сегодня проблема заключается не только в количестве открытых PR.

Проблема в отсутствии предсказуемого процесса их прохождения.

Сообществу необходимы понятные состояния:

New → Needs review → Changes requested → Ready for merge → Merged / Closed

И понятные сроки реакции на каждом этапе.

Не обязательно обещать, что каждый PR будет принят.

Необходимо обеспечить, чтобы каждый качественно оформленный PR был:

рассмотрен → получил feedback → получил решение.

Нужна распределённая команда maintainers

Один из самых серьёзных системных рисков — концентрация критически важных решений у слишком небольшого количества людей.

Если проект зависит от того, найдётся ли время у одного-двух человек посмотреть PR, провести release или принять архитектурное решение, развитие неизбежно будет замедляться.

MODX уже достаточно большой проект, чтобы иметь распределённую Core Maintainers Team.

Сообщество готово участвовать в такой работе.

Нужны:

дополнительные maintainers;
понятные критерии получения прав;
разграничение ответственности;
технические reviewers;
release manager;
люди, отвечающие за triage;
прозрачный процесс назначения и передачи полномочий.

Это не означает отказ от контроля качества.

Наоборот.

Распределение ответственности позволит повысить качество и снизить зависимость проекта от отдельных людей.

MAB должен получить окончательный статус

MAB был создан как механизм формирования архитектурного направления MODX.

За прошедшие годы часть рекомендаций была реализована, часть потеряла актуальность, часть была заменена другими решениями.

Теперь необходимо просто зафиксировать актуальный статус каждого пункта:

Implemented
Superseded
Withdrawn
In progress
Planned
Rejected

Не нужно снова годами обсуждать MAB.

Нужно завершить его аудит и получить актуальную техническую картину.

Это позволит использовать уже проделанную работу вместо того, чтобы начинать стратегическое планирование с нуля.

Нужен нормальный release cycle

Сообществу не нужны редкие большие релизы, вокруг которых каждый раз возникает отдельная организационная проблема.

Лучше небольшие и предсказуемые релизы.

Например:

регулярные patch-релизы;
плановые minor-релизы;
development/nightly builds;
публичное тестирование;
changelog для каждого релиза;
понятный процесс подготовки следующей версии.

Nightly и development-сборки особенно важны для сообщества.

Они позволяют тестировать изменения до финального релиза и получать обратную связь тогда, когда её ещё можно использовать.

Тестирование должно приводить к результату

Недостаточно просто попросить сообщество протестировать изменения.

Если разработчики тратят время на тестирование, а после этого PR месяцами остаётся без решения, такая модель не работает.

Результатом тестирования должен становиться следующий шаг: merge / changes requested / rejected / additional testing required

Это простая вещь, но именно она формирует доверие к процессу.

Нужен triage существующего backlog

Необязательно пытаться сразу обработать сотни PR и Issues.

Нужно начать с классификации.

Ready to merge — Изменения проверены и не требуют существенной доработки.

Needs review — Нужен технический review.

Needs testing — Код требует проверки на реальных проектах.

Changes requested — Автору необходимо внести изменения.

Outdated — PR потерял актуальность из-за изменений в 3.x.

Close — Проблема уже решена, неактуальна или решение принято другим способом.

Такой процесс позволит уменьшить backlog и вернуть разработчикам понимание того, что происходит с их вкладом.

Сообщество готово помогать

Важно подчеркнуть: сообщество не требует, чтобы небольшая команда MODX сделала всю работу самостоятельно.

Наоборот.

Есть разработчики, которые готовы:

писать код;
исправлять баги;
тестировать PR;
заниматься triage;
писать документацию;
поддерживать инфраструктуру;
готовить релизы;
финансировать разработку;
брать ответственность за отдельные направления.

Но для этого необходимы полномочия и понятные правила.

Нельзя одновременно говорить сообществу «помогайте» и оставлять его без возможности довести работу до результата.

Open Source требует не только денег, но и управления

Если в проект вкладываются деньги, они должны помогать решать реальные проблемы проекта.

В первую очередь это могут быть:

triage;
PR review;
release management;
тестирование;
документация;
разработка ключевых компонентов;
работа с backlog;
инфраструктура CI/CD.

При этом сообщество готово участвовать и финансово.

Если для полноценной работы Core Maintainers Team требуется финансирование — давайте открыто обсудим необходимую сумму, задачи и модель финансирования.

Гораздо лучше иметь прозрачную модель: финансирование → конкретная работа → конкретный результат → публичный отчёт

Мы не хотим форка

Это принципиальный момент.

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

Мы хотим развивать официальный MODX Revolution.
Мы хотим отправлять PR в официальный репозиторий.
Мы хотим видеть свои изменения в официальных релизах.
Мы хотим участвовать в формировании roadmap.
Мы хотим помогать тестировать новые версии.
Мы хотим вкладывать время и деньги в развитие проекта.

Но для этого должна существовать возможность реально влиять на результат своей работы.

Однако fork становится следствием отсутствия решений

Если сообщество годами сталкивается с одной и той же ситуацией:

roadmap обсуждается, но не появляется;
contribution process обсуждается, но не становится рабочим инструментом;
PR открываются, но долго остаются без решения;
сообщество готово тестировать, но не видит результата;
backlog продолжает расти;

возникает естественный вопрос: Что разработчикам делать сейчас?

Если официальный репозиторий не позволяет достаточно быстро развивать проект, разработчики рано или поздно начинают создавать собственную инфраструктуру.

Не потому, что хотят уничтожить MODX.

А потому, что хотят продолжать работать.

Поэтому появление fork в такой ситуации будет не причиной проблемы.

Это будет следствием отсутствия работающего механизма развития официального проекта.

И чем дольше откладываются необходимые изменения, тем выше вероятность того, что сообщество начнёт развивать альтернативную ветку.

Что мы предлагаем сделать в ближайшие 30 дней

Мы предлагаем не создавать ещё одну дискуссию на несколько лет, а перейти к конкретным действиям.

1. Опубликовать roadmap

Хотя бы на ближайшие 6–12 месяцев.

2. Провести публичный аудит MAB

Для каждого пункта определить текущий статус.

3. Опубликовать contribution process

От создания PR до merge или закрытия.

4. Создать Core Maintainers Team

И распределить технические полномочия.

5. Провести triage backlog

Начать с наиболее актуальных PR и Issues.

6. Определить release cycle

И придерживаться его.

7. Запустить регулярные development/nightly builds

Чтобы сообщество могло тестировать изменения до релиза.

8. Определить ответственных за review и releases

Чтобы работа не зависела от одного человека.

9. Опубликовать модель финансирования Open Source-разработки

И показать, какие задачи можно финансировать непосредственно.

10. Публично ответить на вопрос о будущем MODX Revolution

Не общими обещаниями, а конкретным планом.

В заключение

Мы не хотим закрытия MODX.
Мы не хотим очередного конфликта.
Мы не хотим форка ради форка.
Мы хотим развивающийся MODX.

Нам нужна современная, активно развивающаяся платформа с понятным будущим, регулярными релизами, работающим процессом contribution и возможностью сообщества реально участвовать в развитии ядра.

У MODX всё ещё есть сильное сообщество, большой накопленный технический потенциал, огромная экосистема дополнений и разработчики, которые готовы продолжать работу.

Но этого недостаточно без работающей модели управления проектом.

Поэтому сейчас нужен не очередной год ожидания.

Нужны решения.

Мы готовы помогать.
Мы готовы разрабатывать.
Мы готовы тестировать.
Мы готовы финансировать.
Мы готовы брать на себя ответственность.

Вопрос только в том, готово ли руководство MODX создать условия, при которых эта работа действительно сможет попасть в официальный проект.

Мы надеемся, что ответ будет да.

И что на этот раз за ответом последуют конкретные действия.

Огромная просьба кто имеет желание и возможность поддержать его — оставить комментарий или оставить реакцию по ссылке Открытое письмо руководству MODX и команде MODX Revolution.

Заранее всем спасибо!

Иван Бочкарев

02 сентября 2026, 18:12

1 047

Комментарии: 15

Антон Тарасов

02 сентября 2026, 20:21

Всецело и полностью поддерживаю, комментарий и реакция не заставили меня ждать.

Олег Захаров

03 сентября 2026, 00:18

Давно пора! Такой классный движок застопорился в развитии из-за непонятно чего. Я много лет занимаюсь разработкой сайтов, делал сайты на joomla, wordpress, Yii, 1С-Битрикс, MODX, Laravel+Vue. Но последние лет 10 когда надо сделать какой-нибудь сложный сайт я всегда выбираю MODX. На нем просто и быстро развернуть прототип, сделать рабочую модель в разы проще. Я уже несколько проектов на ИИ-сделал на MODX. Хотя и выбираю для некоторых проектов Laravel+Vue, мне очень нравится MODX и хочется чтобы он развивался. В свое время кстати нашумели MODX Evolution на базе Laravel — что-то про них не слышно в последнее время. Где-то читал что якобы их Laravel или кто-то там поглотил (не знаю правда или нет? Подскажите). Пробовал на нем делать проекты, как-то не зашло. MODX REVO как-то привычнее стал что-ли — в нем все понятно и просто (ну как бы новичкам не просто все сразу, но потом к нему так привыкаешь). И суть в том что MODX Revo столько лет существует, но от этого не становится неактуальным. И даже сегодня в век ИИ он довольно интересен и перспективен — ИИ прекрасно знают как работает MODX Revo, причем как версии 2, так и 3. Сейчас сделать компонент для MODX легче легкого — ИИ сам упакует как надо все (не тратишь время на отладки и поиски где поставил не так запятую), остается фокус внимания на бизнес-логике компонента. Не надо тратить время на создание механики сайта (учетки, авторизации, магазин, мультиязычность/ мультидоменность, легко встраивать любые скрипты, шаблоны, фреймворки). И я себе даже сделал сервис сайт-завод который делает сайты именно на MODX Revo. Использование чанков оказалось очень удобно для работы с ИИ — даешь ему ссылку на чанк — он правит только его, не ломая и не переписывая весь сайт. Только надо научить правильно программировать и создавать структуру сайта.
В век развития ИИ надо делать сайт максимально адаптированным для применения для ИИ. Сделать универсальные API. Удобные интеграции. И многое другое. Нужна база знаний по MODX в формате Obsidian.md — общедоступная.

Евгений Борисов

04 сентября 2026, 01:08

Мы 14 лет наблюдаем один и тот же цикл.

19 апреля 2012 сама MODX в «Bringing Evolution Development Back to Life» написала: push-доступ у нескольких человек, а *«with the current workload of the MODX Team, it also serves as a barrier. That must change!»* Решением тогда назвали не форк, а Integration Manager, выбранного сообществом, с push-доступом в официальный репозиторий — *«handing over the keys to the Community ASAP»*.

23 января 2013 готовый фикс XSS в FormIt ушёл PR'ом — к 17 марта ноль реакции, а в середине марта баг подтверждён как всё ещё присутствующий в релизе. 14 ноября 2016 MODX выпустила security-релиз 2.5.2 и официально поблагодарила bezumkin, Fi1osof, Mark-H, AgelXNash и chengruiqi; в том же треде член security team написал: *«We took too long to respond to your initial email, and I'm sorry for that»*. 2 сентября 2026 сообщество снова пишет открытое письмо с тем же диагнозом: вклад есть, люди есть, процесса, превращающего их в решения, нет.

Между этими точками — наш собственный опыт: параллельные сборки, а затем в 2016 MODX сама передала Evolution команде сообщества — опять её же словами, «handing over the keys»; Evo 2.0 вышел в 2018, репозиторий позже осёл в evocms-community. Две экосистемы, два рынка дополнений, две документации и миграция, которая пережила все споры, её породившие. Мы проходили этот цикл изнутри.

Вывод простой: когда единственный способ превратить работу в решение — построить отдельный продукт, контрибьюторы не объединяются, а фрагментируются. И платит установленная база.

Поэтому предлагаю не ждать очередного ответа официалов и не плодить конкурирующие ветки, а вернуться к совместной разработке — под новым брендом, который не принадлежит ни одной компании и ни одной национальной группе (включая modx.pro и включая нас).

Что кладём в основу:
— опыт Evolution CMS: сопровождение большой установленной базы и модернизация в условиях обратной совместимости, включая работу на базе Laravel-компонентов;
— практики экосистемы Laravel: пакеты, контракты, service container — современный PHP без изобретания собственного велосипеда;
— архитектурные идеи следующего поколения, которые давно обсуждают Философ и другие: API-first, отказ от ExtJS, чистое ядро.

С одним правилом, согласованным заранее — два трека:
— Трек A — эволюция с обратной совместимостью: безопасность, современные версии PHP, DX для существующей установленной базы.
— Трек B — прогрессивный трек без ограничений совместимости: чистая архитектура проверяется прототипами, а не манифестами.

Governance с первого дня: мейнтейнеры зарабатывают права историей вклада, зоны ответственности ограничены, RFC публичные, правила передачи и отзыва прав прозрачны. Если у официалов появится реальный процесс — интеграция на столе; срок 30 сентября — это срок для MODX, не для нас. Но после четырнадцати лет одного и того же цикла сообщество, которое все эти годы тащило проект на старой памяти, обязано само себе дать работающую альтернативу.

Мы больше не ждём разрешения. Название, как и всё остальное, выберем вместе. Кто с нами?

Николай Савин

04 сентября 2026, 15:26

Хорошо написал, хочется поапладировать. Практический план ровно такой каким и должен быть. Максимально крупными мазками, но уже конкретный.
Как думаешь есть смысл менять название и брендинг? Если да, то в какой момент?
В чатике предлагали modex — мне прям зашло.

Андрей Степаненко

04 сентября 2026, 21:07

кто сказал что надо разрешение спрашивать…
скажут что mody))) и флаг в руки

Андрей Степаненко

04 сентября 2026, 21:11

про гибкость
```
--v2-line-height-body: 1.22;
```

плиз

Иван Бочкарев

07 сентября 2026, 07:23

Сделал, спасибо

Сергей Шлоков

06 сентября 2026, 10:36

Грустно наблюдать всё это. Чтобы понять всю бесперспективность данного многолетнего обсуждения в RU сообществе, нужно подняться над проблемой. Тогда будет всё очевидно.
Удел MODX — постепенное забвение. И небольшая кучка людей, которая страдает ностальгией, это не изменит. Даже если наберется 10 желающих, то через год от них вряд ли останется половина. Основная движущая сила этого движения — несколько бывших модыксеров, у которых остались тёплые чувства к MODX из-за того, что он дал им выход в мир разработки. Они уже сейчас даже его не используют. Это просто энтузиасты, у которых завтра изменятся планы и которым по большому счету спасибо никто говорить не будет.

MODX все любят и любили именно за то, что он из себя представляет. Если всё это убрать и сделать из него второй Laravel, то он перестанет быть MODX. Да и вообще, зачем делать Laravel-подобный инструмент, если есть Laravel. Чтобы был Laravel, но с чанками, сниппетами, плагинами? Нафига? Из-за страха, что сложно выучить Laravel? ИИ сейчас эту проблем убирает почти совсем.

Это не значит, что MODX нельзя сейчас использовать. Можно конечно. Но относится к этому нужно просто как к инструменту, который помогает здесь и сейчас заработать деньги. Вы потратили время на его изучение. Поэтому нужно взять от этого максимум. Но ни в коем случае нельзя на нём зацикливаться. Нужно развиваться дальше.

Я никого не отговариваю. У кого есть желание и свободное время для этого, могут взяться и доказать, что я ошибаюсь. Хоть я в успех не верю, но тем не менее, это всё равно будет полезно для повышения скиллов.

Вот такое моё имхо. Это сообщение самоуничтожится после самоуничтожения )

Павел Голубев

07 сентября 2026, 09:29

Рынок, где коммерчески оправданно использование Modx — очень сильно сжался. Для чего-то более-менее сложного есть Laravel/Symfony в качестве бека и Vue/React на фронте. Для лендингов, простых сайтов и магазинов на 200 товаров — есть конструкторы, а теперь еще и нейронки. Каких-то раскидистых корпоративных порталов и сложного екома на нём тоже делать не будешь.

Поэтому это было классное время, спасибо Modx, но пора двигаться дальше.

Димыч

09 сентября 2026, 12:29

Вектор разработки резко сместился в сторону LLM, и MODX здесь — не самый лучший инструмент. Имхо, в ближайшее время будут рулить Headless CMS, типа Strapi. Останутся разработчики с большим багажом проектов на MODX. Ну и старые пердуны, которым лень изучать что-то новое.

Wassi Wassinen

09 сентября 2026, 17:31

Вы упускаете изначальную аудиторию MODx. Это те, кто хотят сами (или им мало условной Тильды), но при этом не могут полностью в самостоятельное программирование. И не только не могут, но и не хотят. Поэтому используют готовые дополнения, шаблоны, вызовы сниппетов и чанки. Которые можно немного подправить под себя и оно заработает.

Именно это всегда был основной объем в штуках от пользователей MODx.

Но, почему-то, разработчики об этом упорно не хотят вспоминать. И при попытке простроить видение новой ветки MODx — тоже. Пытаются уйти в полноценный стек «разработки для разработчиков». Но для этого MODx не годится. Он создавался для другого. :)

Моё скромное мнение, могу ошибаться.

des1gner

10 сентября 2026, 06:41

Я как раз и есть та аудитория, ЖПТ это мне вот объяснил:

Да, это очень точное замечание. Я бы даже сформулировал его чуть жёстче: если MODX пытается конкурировать именно как фреймворк для профессиональных разработчиков, он начинает конкурировать не на своём поле.

Исторически сила MODX была именно в промежуточной зоне:

Тильда / Wix / WordPress-конструкторы ← → полноценная разработка

А MODX занимал место примерно здесь:

«Я понимаю HTML/CSS, немного PHP/JS, могу разобраться в документации, но не хочу каждый раз писать CMS с нуля. Дайте мне готовый сниппет, TV, чанк, плагин, шаблон — я немного переделаю и получу нужный сайт».

И это очень важная аудитория.

В чём был феномен MODX

MODX позволял человеку быть не программистом в полном смысле, но при этом делать вещи, которые конструктор ему не позволял.

Например:

pdoResources
    ↓
готовая выборка
    ↓
Fenom-шаблон
    ↓
немного HTML/CSS
    ↓
готовый каталог

Или:

miniShop2
    ↓
готовый интернет-магазин
    ↓
чанк
    ↓
несколько условий Fenom
    ↓
магазин выглядит "под себя"

Человек не обязан был понимать внутренности xPDO, архитектуру MVC, DI, сервис-контейнеры и т. д.

Он должен был понимать:

«Вот этот вызов выводит товары. Вот этот параметр отвечает за родителей. Вот этот чанк определяет разметку. Здесь я поменяю HTML».

И именно это давало MODX огромную практическую ценность.

Поэтому я бы разделил две аудитории

1. MODX-разработчик

Ему нужны:

API;
Composer;
PHP 8.x;
Git;
CI/CD;
тестирование;
архитектура;
кастомные компоненты;
полноценные приложения.

Это нормальная аудитория.

Но она уже прекрасно живёт в мире:

Laravel + Symfony + Vue/React + API + Docker.

И здесь MODX действительно сложно предложить что-то уникальное.

2. MODX-мастер / веб-мастер

Вот это гораздо интереснее.

Человек говорит:

«Мне нужно сделать сайт. Я умею верстать. Немного понимаю PHP. Я могу разобраться с документацией. Но я не хочу становиться backend-разработчиком».

И ему нужен инструмент:

готовая функциональность
        +
визуально понятная настройка
        +
HTML/Fenom
        +
простые PHP-хуки
        +
огромная библиотека дополнений
        =
готовый сайт

Вот здесь MODX исторически был очень силён.

И здесь есть интересный парадокс

MODX может быть очень хорош именно потому, что не пытается полностью скрыть код.

Тильда говорит:

«Не думай о коде».

Laravel говорит:

«Ты должен уметь программировать».

А MODX исторически говорил:

«Вот код. Он не такой страшный. Возьми готовый и немного измени».

И это совершенно отдельная философия.

Поэтому я бы не пытался превращать MODX в «ещё один современный framework».

Я бы развивал концепцию:

MODX — CMS для людей, которые хотят делать нестандартные сайты без необходимости становиться полноценными программистами.

Причём современные технологии этому совершенно не мешают.

Можно иметь:

MODX 3;
PHP 8.3;
Composer;
Vite;
Tailwind;
Alpine.js;
API;
Docker;

но поверх этого сохранить старую модель потребления:

установил → настроил → вызвал → изменил шаблон → получил результат.

И вот это, на мой взгляд, гораздо более перспективное направление.

Потому что тогда MODX продаёт не «современную архитектуру».

Он продаёт снижение порога между дизайнером/верстальщиком и разработчиком.

И, кстати, ваш собственный опыт с MODX как раз очень хорошо иллюстрирует эту аудиторию: вы можете разбираться в PHP, Fenom, pdoTools, miniShop2, Alpine, Tailwind и т. д., но при этом совершенно не обязательно каждый раз писать полноценную систему с нуля. Именно комбинирование готовых кирпичиков + небольшая доработка и является ценностью MODX.

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

Wassi Wassinen

10 сентября 2026, 14:59

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

Да, всё так. :)

MODX — CMS для людей, которые хотят делать нестандартные сайты без необходимости становиться полноценными программистами.

Эта фраза передает суть.
И создатели MODx это хорошо понимают и помнят. :) А «новая волна» разработчиков — нет. На этом весь «холивар» и строится.

Основной вопрос должен быть в том, как найти компромисс между «хотелками» разработчиков и концепцией MODx. И это — сложный вопрос.
Этот процесс НЕ должен превратить MODx в удобную среду разработки для 15 новых разработчиков MODx, НО при этом потерять всю основную аудиторию.

Разработчиков можно понять и в то же время можно не понять.
Им хочется современный стек, современную работу с файлами, работу «напрямую без админки» и так далее. Но это всё уводит MODx от изначальной стратегии и от основной аудитории.
Странно, что большинство разработчиков не понимают, что добившись всего этого они увидят, что MODx стал очередной бледной копией Laravel или Django (или огромного кол-ва других схожих фреймворков). У которых ИЗНАЧАЛЬНО была аудитория состоящая из программистов. И в новый MODx для программистов они уже не пойдут. Потому что уже есть хорошие фреймворки для программистов с большой кодовой базой, с сообществом, историей и так далее.

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

Наверное, основной вектор может быть сформулирован так — изменения в MODx допускаются только, если они не уводят его от изначальной сути этой CMF. И если разработчик готов мириться с этим вектором, то он остается с MODx. То есть, когда разработчик думает не о себе, а о сообществе «НЕ разработчиков» для которых это всё делается. Это сложно, это вступает в конфликт с внутренним эго, часто это только для энтузиастов и альтруистов. Но такова стезя MODx.

А если нет — есть более современные и заточенные именно под разработчиков фреймворки с которыми не нужно конкурировать. Нужно понять и признать свою нишу и развиваться в ней.

Моё скромное мнение. Могу ошибаться.

Николай Савин

10 сентября 2026, 20:46

И все смешалось, люди, кони…
Илья, мне кажется ты просто бурчишь по привычке не особо понимая разницы между разработкой MODX и разработкой сайта. Уверен что это не так, просто впечатление такое.

Внутри MODX разработка и улучшение ядра никак почти не касается конечных потребителей. Это патчи, которые улучшают безопасность, исправляют различные аспекты новых фич, которые уже заложены, но имеют проблемы и недостатки.
К примеру от меня лежит до сих пор не влитый PR, который позволяет подключить внутри админки поиск по любой таблице, а не только по ресурсам, шаблонам, чанкам и т.п. И основная проблема что даже на такие вещи владельцы MODX забили и не вливают. Здесь нет никакого усложнения разработки сайтов.

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

Пост совсем не о том, что компоненты сейчас сложные. Пост о том, что улучшения давно напрашивающиеся не вливают и повлиять на это никак не получается

Wassi Wassinen

10 сентября 2026, 21:25

Николай, по твоему комментарию — полностью согласен.
Выше писал о другом.
А то, что не принимаются улучшения по существующей «кодовой базе» MODx — это да. Это проблема с которой нужно что-то делать. Главное, если что-то будет меняться в составе контрибуторов или визионеров, чтобы это были люди, которые придерживаются той концепции MODx, которая в эту CMF закладывалась изначально. И выше я писал, в том числе, об этом.

Авторизуйтесь или зарегистрируйтесь, чтобы оставлять комментарии.

Открытое письмо руководству MODX и команде MODX Revolution (Русская версия)

Комментарии: 15

Здесь упомянуты