From Chaotic MODX Structures to a Modular Chunk System
Developing on MODX quickly turns into a nightmare when chunks are scattered across the database without a system and templates are duplicated ten times over. We encountered a project where a single chunk held the entire homepage (over 500 lines), and another held just a menu fragment. Each change required an hour of maintenance. The solution is a modular structure with file storage and Git. This approach cuts modification time by 3–5 times and completely eliminates the loss of changes.
Why File Storage for Chunks and Templates is Better Than the Database?
Database storage is convenient for rapid prototyping, but once a project lives longer than a month, problems arise: no change history, impossible to roll back, difficult to transfer to another server. The file system solves this:
| Criteria | Database | Files + Git |
|---|---|---|
| Versioning | None | Full commit log |
| Environment migration | Export/import | Git push/pull |
| Editing | Only in admin panel | IDE, autocomplete, linters |
| Code review | Cumbersome | Pull request |
File-based approach is the standard for commercial MODX development. Simply set Source Type = File and specify the path. In our practice, switching to file storage reduced deployment time from 2 hours to 5 minutes. One client saved $2,000 per year on maintenance after reorganization.
How to Properly Organize Chunk Names?
Chunk names should immediately indicate their purpose. We use prefixes by type:
header — main header header.mobile — mobile version footer — footer footer.minimal — minimal footer for landing pages card.product — product card card.article — article card card.team — team member card block.cta — call to action block.features — benefits block block.testimonials — testimonials form.contact — contact form form.callback — callback form email.contact — email after inquiry email.order — order confirmation Each chunk resides in a separate file inside assets/chunks/. For templates — assets/templates/. Structure:
assets/ ├── chunks/ │ ├── header.html │ ├── footer.html │ ├── card.product.html │ └── block.features.html └── templates/ ├── home.html ├── inner.html └── catalog.html Example full structure for an e-commerce site (click to expand)
assets/ ├── chunks/ │ ├── header.html │ ├── header.mobile.html │ ├── footer.html │ ├── footer.minimal.html │ ├── card.product.html │ ├── card.article.html │ ├── block.cta.html │ ├── block.features.html │ ├── block.testimonials.html │ ├── form.contact.html │ ├── form.callback.html │ ├── email.contact.html │ └── email.order.html └── templates/ ├── base.html ├── home.html ├── inner.html ├── catalog.html ├── detail.html ├── landing.html ├── blog.html └── error.html How Many Templates Does a Typical Site Need?
A common mistake is having one template for all cases, stuffed with conditions. We use 6–8 templates:
| Template | When Used |
|---|---|
| base | Base skeleton (not used directly, only as parent) |
| home | Homepage |
| inner | Typical inner page (contact, about) |
| catalog | List of categories/products |
| detail | Detail card of product/article |
| landing | Landing with unique layout (no header/footer) |
| blog | Blog with article list |
| error | 404, 503 pages |
In the template, we call chunks with parameters. Example of passing data from template to chunk:
<!-- In template --> [[$block.features? &title=`Why choose us` &items=`[[*tv.features_json]]` &columns=`3` ]] <!-- Chunk block.features --> <section class="features features--[[+columns]]col"> <h2>[[+title]]</h2> <div class="features__grid"> [[+items]] </div> </section> This example shows how to separate presentation from data.
How Not to Lose Version Control?
Even simple chunks sometimes contain logic: show a "New" badge for fresh products, change class for active page. Storing such conditions in a file is fine, but to avoid copying, we use Git. Each change goes through code review. For displaying the "New" badge, we use a condition [[+createdon:gt=...]].
How We Conduct the Reorganization?
- Audit current structure — analyze all chunks and templates, identify duplicates and unused elements. Typical finding: 30% of chunks are never called.
- Design hierarchy — define prefixes, directories, number of templates per page type.
- Move to files — create chunk and template files, set up Git repository.
- Environment setup — set Source Type = File, configure deployment via Git hook.
- Documentation and training — document naming rules, describe process for adding a new chunk. Conduct a short workshop for the team.
This process takes 3 to 5 business days for a typical site (15–25 chunks). Order an audit of your current structure — it takes just one day.
What Does the Modular Structure Give?
After reorganization, time to find the right chunk drops from 10 minutes to 10 seconds. Support savings reach 50% of the budget. The project becomes predictable: any new developer understands the structure in an hour, not a week.
Timelines and Cost
Creating and organizing 15–25 chunks for a typical site — from 3 to 5 business days. The final price is calculated individually after scope assessment. Get a consultation for your project — we will analyze your current structure and propose the optimal solution. Savings on support after such reorganization can reach 50% of expenses.
What's Included in the Reorganization Service
- Full audit of existing chunks and templates with identification of duplicates and unused elements.
- Design of a modular hierarchy with prefix naming and directory structure.
- Migration of all chunks and templates to file-based storage with Git version control.
- Setup of deployment via Git hook for seamless environment synchronization.
- Documentation of naming rules and processes, plus a team workshop.
- Post-delivery support for 30 days to ensure smooth adoption.
Why Trust the Reorganization to Professionals?
With over 5 years in web development and more than 50 successful MODX projects, we guarantee that after chunk reorganization, the time to make edits will be reduced by at least half. Our engineers use Git, code review, and continue to support the project after delivery. As noted in the official MODX documentation, file storage is the recommended approach for commercial projects.
We don't just bring order — we implement a modular development culture that pays off on the first functional update. Contact us to get a consultation for your project.







