Экосистема pdoTools и miniShop: быстрый старт, дорогой хвост
У pdoTools и miniShop есть очевидное достоинство: они сделали MODX намного удобнее для массового интегратора.
Нужно вывести каталог, фильтры, меню, пагинацию, товары, корзину, заказ? Во многих случаях не надо проектировать приложение. Достаточно поставить компоненты, передать параметры, написать чанки и получить результат.
На старте это очень эффективно.
Проблема начинается позже.
Что именно произошло
У MODX уже есть собственный application stack:
xPDO → models → processors → resources → parser
Поверх него появился ещё один универсальный слой:
MODX → pdoTools / pdoFetch → Fenom / chunks → многочисленные Extras
А ecommerce добавляет следующий:
MODX → pdoTools → miniShop2 → mSearch2 / mFilter2 / addons → project code
Каждый отдельный слой может быть вполне полезен. Но вместе они создают систему, где проект зависит уже не просто от MODX, а от конкретной исторической комбинации MODX + pdoTools + miniShop + Extras + их версий и соглашений.
Это и есть цена быстрого старта.
pdoTools не убрал сложность — он её спрятал
В pdoFetch можно декларативно задать class, where, select, joins, TVs, sorting, grouping, шаблон вывода и получить готовый результат.
Для интегратора это прекрасно: огромное количество типовых задач решается без собственного PHP-кода.
Но SQL, xPDO, ACL, TV, выборка данных и rendering никуда не исчезли. Они просто переехали внутрь большого универсального runtime и его конфигурации.
В простом проекте это экономия.
В сложном проекте приходится понимать одновременно:
- MODX;
- xPDO;
- pdoTools;
- Fenom;
- конкретные Extras;
- особенности их взаимодействия.
Абстракция начинает протекать.
miniShop усилил тот же подход
miniShop2 дал рынку очень много готового ecommerce-функционала. Но архитектурно это уже отдельный framework layer внутри MODX: собственные модели, handlers, события, сервисы, product abstraction, snippets и тесная связь с pdoTools.
В актуальном MiniShop3 зависимость от pdoTools остаётся обязательной. README прямо указывает pdoTools 3.x как required dependency.
Сам по себе факт зависимости не преступление. Проблема в том, что каждое новое поколение продолжает тащить исторический стек дальше.
Что происходит при обновлениях
На длинной дистанции такой стек неизбежно начинает жить как единый организм.
Меняется PHP — ломается один слой. Обновляется MODX — всплывает несовместимость в другом. Меняется pdoTools — начинает вести себя иначе компонент поверх него.
Свежий пример из 2026 года: релиз pdoTools 3.0.3-pl устанавливался без vendor и давал fatal error на чистом MODX 3.2.
В списке открытых issues есть проблемы совместимости с MiniShop3, PHP 8, TV filters, Fenom и другими частями стека.
Это не доказательство того, что pdoTools «плохой». Это нормальное следствие большого слоя совместимости, который годами растёт поверх другого большого слоя совместимости.
Был другой подход
В той же MODX-экосистеме существовал другой путь:
xPDO → processors → API → presentation
На нём строились modxSite, modxSmarty и shopModx.
Идея была простой: не писать второй framework поверх MODX там, где само ядро уже даёт модели, relations, processors и extension points.
modxSite использовал processors как application/API layer.
modxSmarty выносил presentation в нормальный файловый template engine, не ломая при этом нативный parser MODX.
shopModx отделял ecommerce-сущности от presentation и не пытался превращать весь магазин в один универсальный компонентный runtime.
«Но так же дольше»
Нет. Не обязательно.
Так дольше для человека, который умеет только собирать сайт из готовых компонентов.
Программист, который нормально знает PHP, xPDO, SQL, наследование и processors, решает многие задачи не медленнее. Просто скорость достигается не количеством установленных Extras, а уровнем владения базовыми инструментами.
И вот здесь был настоящий конфликт подходов.
Не: "быстро против правильно", а "интеграторская скорость за счёт готовых абстракций против программистской скорости за счёт квалификации и более прямой архитектуры".
Кто в итоге заплатил
Рынок выбрал первое. И это понятно: такой подход легче продавать, легче тиражировать и проще масштабировать через большое количество интеграторов.
Но через десять лет стоимость решения оплачивает уже не интегратор.
Её оплачивает собственник сайта.
Он получает проект, в котором бизнес-знание распределено между MODX, pdoTools, miniShop, десятками Extras, чанками, TV, snippets, plugins и человеком, который когда-то всё это собрал.
Когда этот человек исчезает, документацией проекта внезапно оказывается его голова.
Вывод
Экосистема pdoTools/miniShop действительно ускорила создание MODX-сайтов.
Но ускорение старта и управляемость проекта через десять лет — разные задачи.
В первом рынок выиграл.
Во втором накопил долг.
И теперь этот долг приходится распутывать тем бизнесам, которые когда-то получили быстрый и недорогой старт, а сегодня хотят нормальный API, современный frontend, автоматизацию, AI и возможность вообще перестать зависеть от MODX.
