Fi1osof: от внутренностей MODX к современной архитектуре
Я не вернулся в MODX затем, чтобы снова делать сайты на MODX.
Я вернулся потому, что сегодня есть большой пласт старых проектов, которые всё ещё приносят бизнесу деньги, но сами стали техническим ограничением. И для таких проектов мало человека, который умеет поставить pdoTools, поправить чанк или обновить miniShop.
Нужен тот, кто понимает и старый MODX изнутри, и то, куда проект должен двигаться дальше.
Это как раз мой случай.
Я не просто пользовался MODX
В MODX я пришёл давно и довольно быстро упёрся не в отсутствие готовых компонентов, а в архитектурные ограничения самой системы.
Когда не хватало нормального административного инструмента для выполнения кода и исследования живого runtime, появился Console.
Когда стало понятно, что работа с данными слишком тесно завязана на frontend/runtime и snippets, появился modxSite — API-first слой на processors и xPDO.
Когда хранение шаблонного кода в базе стало мешать переносимости и нормальной разработке, сначала появился phpTemplates, а затем modxSmarty.
Когда понадобилась ecommerce-модель без превращения проекта в ещё один толстый framework поверх MODX, появился shopModx.
То есть это были не случайные Extras. Это была одна линия:
меньше магии → больше явного API → нормальные модели → processors → файловый код → отделение presentation
Часть старого кода и примеров до сих пор доступна публично:
Я ковырял не только компоненты, но и само ядро
Одна из важных черт моей работы с MODX — я довольно рано перестал воспринимать границы платформы как нечто священное.
Если стандартный механизм не выдерживал задачу, я лез в xPDO, request lifecycle, cache map, routing и внутренние классы MODX и смотрел, где именно находится реальный предел.
Например, когда речь заходила о сотнях тысяч ресурсов, проблема была не в каком-то одном медленном сниппете. MODX пытался строить и кешировать огромную карту ресурсов целиком. Для проектов на 150 тысяч документов мне приходилось переписывать части request-механизма, потому что стандартная модель уже начинала рассыпаться.
В обсуждении проекта на 500 000 ресурсов я прямо писал: без серьёзного тюнинга MODX из коробки нормально живёт примерно на десятках тысяч ресурсов, дальше приходится менять сам подход.
Это хороший пример разницы между «знать компоненты MODX» и понимать, где и почему сама архитектура перестаёт выдерживать нагрузку.
Я спорил с доминирующим подходом не из любви к спорам
В русскоязычной экосистеме победил другой путь: больше готовых универсальных компонентов, ниже порог входа, быстрее сборка сайта интегратором.
Я много лет спорил с этим подходом, потому что смотрел на MODX как программист.
Меня интересовали:
- модели данных;
- API;
- переносимость кода;
- наследование;
- processors;
- separation of concerns;
- стоимость сопровождения через годы.
Отсюда и modxSite, modxSmarty, shopModx.
Сегодня спор уже не особенно интересен. Интереснее другое: время дало возможность проверить архитектурные решения на длинной дистанции.
Сейчас именно связанность старых MODX-проектов с runtime, Extras и presentation layer становится одной из главных проблем при модернизации и headless-переходе.
Потом я ушёл далеко за пределы MODX
Последние 10+ лет я не сидел внутри этой экосистемы.
Я работал с современными backend и frontend-стеками, API, Node.js, React, GraphQL, инфраструктурой и большими инженерными системами. Дошёл до bigtech и позиции tech lead.
Это важнее любой строчки «N лет опыта с MODX».
Потому что сегодня задача владельца старого MODX-сайта не в том, чтобы найти самого опытного человека по чанкам.
Задача — провести работающий legacy-проект через технологическую границу:
старый MODX → API → новый frontend → новые сервисы → постепенное отключение legacy
Для этого недостаточно знать только старую сторону. И недостаточно знать только новую.
Почему это имеет значение сегодня
Современный разработчик может прекрасно знать Next.js, GraphQL, Kubernetes и AI-интеграции, но открыть MODX-проект 2013 года и ничего там не понять.
Старый MODX-специалист может прекрасно знать TVs, Fenom, pdoTools и miniShop, но не иметь опыта проектирования систем за пределами этой экосистемы.
Моя ценность находится в пересечении: глубокое знание legacy MODX + опыт архитектурной работы внутри него + 10+ лет современной разработки вне MODX + опыт технического лидерства.
Именно поэтому я могу взять на себя не отдельную доработку, а техническую ответственность за переход проекта из одного поколения технологий в другое.
Чего я не собираюсь делать
Я не собираюсь возвращаться на рынок дешёвой сборки MODX-сайтов.
Я не предлагаю создавать новые проекты на MODX.
И я не собираюсь убеждать владельца, которого полностью устраивает его текущий стек, что ему срочно нужна миграция.
Моя аудитория — те, кто уже чувствует проблему:
- сайт приносит деньги, но развивать его всё тяжелее;
- старые подрядчики исчезают;
- новые специалисты боятся трогать legacy;
- полная перепись слишком рискованна;
- бизнес не хочет ещё десять лет зависеть от MODX.
Я знаю обе стороны достаточно хорошо, чтобы не заставлять бизнес выбирать между вечным legacy и опасным переписыванием с нуля.
Именно в этом сегодня смысл моего возвращения в MODX.
