Blog Sections Open
Working with 10,000+ Documents in the Evolution CMS Tree
A practical look at document tree performance, alias listing strategies, and URL helpers on very large Evolution CMS installs.
Once an Evolution CMS site grows into tens of thousands of documents, the manager tree itself becomes part of the performance problem. The issue is not only database size. It is the cost of repeatedly building alias listings, traversing folders, and resolving URLs for structures that are much larger than the manager actually needs to display at once.
The source discussion described a tree with more than 23,000 resources and only a small fraction of them acting as folders. That is exactly the kind of project where default traversal logic starts to hurt.
Where the load comes from
- Alias listing logic that loads too many rows into memory.
- Tree builders that do not distinguish well between folders and ordinary documents.
- Recursive child-ID gathering across deep branches.
- Repeated URL reconstruction for many items that are not visible in the current manager view.
One useful optimization
If the manager tree only needs folder nodes for navigation, narrow the tree query to isfolder=1 instead of loading everything:
$rs = $modx->db->select(
'IF(alias="", id, alias) AS alias, id, parent, isfolder',
$modx->getFullTableName('site_content'),
'deleted=0 AND isfolder=1',
'parent, menuindex'
);
Another important point
Frontend helpers such as Ditto, Wayfinder, or URL placeholders do not always need the same tree data as the manager. Treat the manager tree and frontend navigation as separate workloads. Optimizing one by trimming folder-only tree data does not mean your frontend links have to become less accurate.
What to review in large installs
- How alias listings are cached and reused.
- Whether recursive child lookups are bounded to realistic depth.
- Whether folder-only logic is used where appropriate.
- Whether expensive URL reconstruction is being repeated unnecessarily.
On very large Evo installations, performance improvements often come from reducing unnecessary traversal rather than from one magical cache switch. The tree should carry only the navigation workload it actually needs to serve.
Why a Catalog Slows Down After 500 Products in Evolution CMS
How to diagnose catalog slowdowns that appear after a few hundred products, especially on Evo setups built around DocLister and TV-heavy product data.
Reducing Page Generation Time in Large Evolution CMS Projects
How to reason about slow page generation in large Evolution CMS installs when API calls, TVs, menus, and repeated snippet queries all add up.