Efficient MODX Chunk and Template Organization with Git

From Chaotic MODX Structures to a Modular Chunk System

Development and maintenance of all types of websites:

Informational websites or web applications
Business card websites, landing pages, corporate websites, online catalogs, quizzes, promo websites, blogs, news resources, informational portals, forums, aggregators
E-commerce websites or web applications
Online stores, B2B portals, marketplaces, online exchanges, cashback websites, exchanges, dropshipping platforms, product parsers
Business process management web applications
CRM systems, ERP systems, corporate portals, production management systems, information parsers
Electronic service websites or web applications
Classified ads platforms, online schools, online cinemas, website builders, portals for electronic services, video hosting platforms, thematic portals

These are just some of the technical types of websites we work with, and each of them can have its own specific features and functionality, as well as be customized to meet the specific needs and goals of the client.

Our competencies:

Frequently Asked Questions

Latest works

  • image_web-applications_feedme_466_0.webp
    Development of a web application for FEEDME
    1285
  • image_ecommerce_furnoro_435_0.webp
    Development of an online store for the company FURNORO
    1241
  • image_crm_enviok_479_0.webp
    Development of a web application for Enviok
    982
  • image_crm_chasseurs_493_0.webp
    CRM development for Chasseurs
    1033
  • image_website-sbh_0.webp
    Website development for SBH Partners
    1104
  • image_website-_0.webp
    Website development for Red Pear
    554

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?

  1. Audit current structure — analyze all chunks and templates, identify duplicates and unused elements. Typical finding: 30% of chunks are never called.
  2. Design hierarchy — define prefixes, directories, number of templates per page type.
  3. Move to files — create chunk and template files, set up Git repository.
  4. Environment setup — set Source Type = File, configure deployment via Git hook.
  5. 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.