The pdoTools and miniShop Ecosystem: Fast Start, High Long-Term Cost
pdoTools and miniShop have an obvious advantage: they made MODX much more convenient for the mass-market integrator.
Need to display a catalog, filters, a menu, pagination, products, a shopping cart, an order? In many cases, there is no need to design an application. It is enough to install components, pass parameters, write chunks, and get the result.
At the start, this is very efficient.
The problem begins later.
What Actually Happened
MODX already has its own application stack:
xPDO β models β processors β resources β parser
On top of it, another universal layer appeared:
MODX β pdoTools / pdoFetch β Fenom / chunks β numerous Extras
And ecommerce adds the following:
MODX β pdoTools β miniShop2 β mSearch2 / mFilter2 / addons β project code
Each individual layer can be quite useful. But together they create a system where a project depends no longer just on MODX, but on a specific historical combination of MODX + pdoTools + miniShop + Extras + their versions and conventions.
This is the price of a fast start.
pdoTools Didn't Remove Complexity β It Hidden It
In pdoFetch, you can declaratively set class, where, select, joins, TVs, sorting, grouping, an output template, and get a ready-made result.
For an integrator, this is wonderful: a huge number of standard tasks are solved without writing custom PHP code.
But SQL, xPDO, ACL, TVs, data selection, and rendering haven't gone anywhere. They have simply moved inside a large universal runtime and its configuration.
In a simple project, this is a saving.
In a complex project, you have to understand all of the following simultaneously:
- MODX;
- xPDO;
- pdoTools;
- Fenom;
- specific Extras;
- the specifics of how they interact.
The abstraction starts to leak.
miniShop Reinforced the Same Approach
miniShop2 gave the market a lot of ready-made ecommerce functionality. But architecturally, this is already a separate framework layer within MODX: custom models, handlers, events, services, product abstraction, snippets, and a tight connection with pdoTools.
In the current MiniShop3, the dependency on pdoTools remains mandatory. The README explicitly specifies pdoTools 3.x as a required dependency.
The fact of dependency in itself is not a crime. The problem is that every new generation continues to drag the historical stack further along.
What Happens During Updates
Over the long run, such a stack inevitably starts to live as a single organism.
PHP changes β one layer breaks. MODX updates β an incompatibility surfaces in another. pdoTools changes β a component on top of it begins to behave differently.
A fresh example from 2026: the release of pdoTools 3.0.3-pl installed without vendor and caused a fatal error on a clean MODX 3.2 installation.
The list of open issues includes compatibility problems with MiniShop3, PHP 8, TV filters, Fenom, and other parts of the stack.
This is not proof that pdoTools is "bad." It is the normal consequence of a large compatibility layer growing for years on top of another large compatibility layer.
There Was a Different Approach
In the same MODX ecosystem, there was another path:
xPDO β processors β API β presentation
modxSite, modxSmarty, and shopModx were built upon it.
The idea was simple: do not write a second framework on top of MODX where the core itself already provides models, relations, processors, and extension points.
modxSite used processors as an application/API layer.
modxSmarty moved presentation into a normal file-based template engine without breaking the native MODX parser.
shopModx separated ecommerce entities from presentation and did not try to turn the entire store into a single universal component runtime.
"But That Takes Longer"
No. Not necessarily.
It takes longer for a person who only knows how to assemble a website from pre-made components.
A programmer who is well-versed in PHP, xPDO, SQL, inheritance, and processors solves many tasks just as quickly. Speed is achieved not through the number of installed Extras, but through mastery of basic tools.
And this is where the real conflict of approaches lay.
Not: "fast versus correct", but "integrator speed at the expense of ready-made abstractions versus programmer speed at the expense of qualification and a more direct architecture".
Who Paid in the End
The market chose the former. And this is understandable: such an approach is easier to sell, easier to replicate, and simpler to scale through a large number of integrators.
But ten years later, the cost of the solution is no longer paid by the integrator.
It is paid by the website owner.
They get a project where business knowledge is distributed between MODX, pdoTools, miniShop, dozens of Extras, chunks, TVs, snippets, plugins, and the person who once assembled all of this.
When that person disappears, the project documentation suddenly turns out to be inside their head.
Conclusion
The pdoTools/miniShop ecosystem truly accelerated the creation of MODX sites.
But accelerating a startup and the maintainability of a project ten years down the road are different tasks.
The market won on the first point.
It accumulated debt on the second.
And now this debt has to be untangled by those businesses that once got a fast and inexpensive start, and today want a normal API, a modern frontend, automation, AI, and the ability to stop depending on MODX altogether.
