Слово legacy здесь не означает «старое — значит плохое». Старый код может десятилетиями нормально выполнять свою работу.

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

И это уже не вопрос вкуса. Это видно по релизам.

Что реально происходило последние годы

MODX Revolution 2 вышел ещё в 2010 году. Его базовая модель нам хорошо знакома до сих пор:

modResource → Templates / TVs / Chunks / Snippets / Plugins → parser → HTML

Плюс xPDO, processors, Manager и Transport Packages.

За последующие годы выходили 2.5, 2.6, 2.7, 2.8. Но если открыть сами release notes, там в основном:

• исправления багов;
• security fixes;
• совместимость с новыми PHP;
• обновление Smarty, PHPMailer, xPDO и других библиотек;
• улучшения Manager;
• небольшие UX-изменения.

Например MODX 2.8 официально описывался через security fixes, file handling и обновления библиотек. 2.8.2 — PHP 8 compatibility, security и bug fixes. 2.8.6 — снова security, PHP 8 compatibility и обновления зависимостей.

Это нормальная работа по сопровождению продукта. Но это не архитектурное развитие платформы.

А потом наконец вышел MODX 3

Готовили его долго. Настолько долго, что сама команда называла релиз long-awaited и прямо писала, что MODX 3 — результат нескольких лет работы.

Что появилось:

• namespaces;
• Composer;
• dependency injection container;
• новые HTTP services;
• xPDO 3;
• поддержка более современных PHP.

На бумаге звучит солидно.

Но рядом в том же релизе команда пишет ключевую фразу: одной из целей MODX 3 было сохранить как можно больше совместимости с веткой 2.x, чтобы старые Extras продолжили работать.

И вот здесь вся суть.

MODX 3 не заменил архитектуру Revolution 2. Он обернул старую архитектуру более современными PHP-механизмами.

Resource остался Resource. TVs остались TVs. Chunks, Snippets, Plugins, parser и старая application model никуда не делись.

То есть это не новая система. Это всё тот же MODX, только в профиль.

Почему это важно владельцу сайта

Потому что сайт живёт дольше, чем версия CMS.

Если бизнес зависит от сайта десять или пятнадцать лет, ему нужны новые интерфейсы, API, мобильные приложения, автоматизация, AI, нормальные deployment pipelines, observability, интеграции с внешними сервисами.

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

Современный специалист с AI, автоматизацией и хорошими инструментами может быть значительно быстрее на новом стеке. Но внутри старого MODX-проекта часть этой производительности теряется на ручных процессах, особенностях legacy-кода, хрупких зависимостях и осторожности при каждом изменении. Поэтому модернизация становится не вопросом вкуса и не технологической роскошью, а экономической необходимостью. Общий закон этой связи сформулирован на futurist.expert: рост производительности специалистов требует соответствующего развития технологической среды бизнеса.

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

Вывод

MODX ещё долго будет работать на тысячах сайтов. Его будут обновлять, латать, переносить на новые PHP и чинить найденные уязвимости.

Но это и есть нормальная жизнь legacy-платформы.

Поддерживать MODX можно. Экономически зависеть от его ограничений бесконечно — всё менее рационально.