MIGX MODX: why complex content breaks the admin panel
Standard TVs in MODX are flat by nature: one variable stores one value. As long as the content is simple, that is enough.
As soon as a catalog with specifications, a price list with supply options, or a "team" block with job titles and photos appears, the template becomes overgrown with a dozen fields, and the relationship between them rests on the agreement "fill in strictly in order." If a content manager shifts a row, the specifications of one product on the site end up attached to another.
Then the familiar degradation of the MODX admin panel begins. Editors work around the limitation with copy-paste: they duplicate resources entirely so they don't have to deal with nested TVs, spawn extra documents in the tree, and lose track of which version is current.
The content manager stops touching the structure — edits go through the developer, and any update to a section turns into a task with a queue. Complex MODX content in such a scheme rests not on a data model but on people's carefulness, and that is the most fragile layer.
MIGX solves exactly this problem: it is a builder of repeatable and nested fields on top of TVs, where the structure is described explicitly rather than guessed from the order of filling.
You define the composition of a block once — and the content manager adds, removes, and rearranges elements in a visual interface without risking breaking the layout. Nested TVs get a predictable storage schema, and the resource tree stops swelling with duplicates.
We break down how this works at the configuration level, and why a properly assembled MIGX takes the load off the developer instead of shifting it onto the editor.
What a configured MIGX delivers: the effect in numbers
A configured MIGX turns MODX from a page editor into a managed content system, where the data structure is described in advance rather than assembled manually in every item.
When fields, their types, and their order are fixed in the configuration, the editor fills out a form instead of laying out blocks — on a typical catalog card this saves from half to two-thirds of the content entry time.
The same set of fields is reused across dozens of items: new entries are added by copying the structure rather than redoing the layout.
The reduction in errors here is not a declaration but a consequence of typing.
Required fields, format constraints, and dropdown lists instead of free input eliminate a class of errors that previously were caught only in production: broken links, lost images, discrepancies in section names.
A content manager physically cannot save an item with an empty required field — validation triggers at the input stage, not after publication.
Output templates separate data from presentation. A single MIGX output template serves the catalog card, the block on the homepage, and the export — when the structure changes, the edit is made in one place and propagates to all points automatically.
This is what predictability means: a new section or content type is added without rewriting existing templates, and reusing configurations across projects cuts the launch time of a new section from days to hours.
A separate effect is maintainability. When content lives in structured fields rather than in markup, migrating to a new theme or a redesign does not require manually transferring items: the data stays, only the output layer changes.
Our team configures MIGX so that the editor works with a clear form and the developer works with a clean structure, and both sides stop depending on manual edits in every item.
Ways to Organize Complex Content in MODX
Complex content in MODX means repeating blocks: team, services, specifications, price rows, galleries. The storage method is chosen not by taste, but by the data structure and by who edits it and how often.
Below are four working approaches that we use in projects, and the boundaries beyond which each starts to get in the way.
| Approach | When it fits | Limitations |
|---|---|---|
| Single TVs | 3-7 fields of the same type per resource: title, subtitle, image, link | As the number of fields grows, the admin panel turns into a long form, the editor gets confused, and there is no connection between blocks |
| MIGX | Repeating groups: employees, reviews, plans, process steps — with nested fields and sorting | Requires careful configuration of the setup and output templates; with tens of thousands of rows it gives way to an external table |
| Collections | Sections where each entry is a separate page with its own address: news, cases, vacancies | No nested repeats inside an entry; not suitable for block data within a single page |
| External tables | Large volumes, import from an accounting system, queries with filters and sorting | Requires a data access layer and synchronization; content editing moves out of the admin panel into its own panel |
MIGX covers the most common case — when content repeats within a single page. The administrator adds and rearranges blocks with the mouse, and the template outputs them in a loop, so the structure doesn't break during edits. Single TVs are good exactly up to the point where there are few fields and they don't form groups.
Collections win where addresses and sections matter: each entry gets its own URL, participates in navigation and the sitemap. External tables take on the volumes that are inconvenient to keep in the resource tree — but then part of the logic moves to a separate interface.
In practice, the approaches are combined: collections for sections, MIGX for blocks within an entry, single TVs for small fields. We lock in the choice at the structure design stage — redoing it after content is filled in costs more than laying out the data right away.
How we set up MIGX: stages of work
Work on MIGX almost never comes down to "create a TV and fill in the fields." Complex content is a structure that an editor must assemble without errors, and templates must render it without manual edits.
That's why we start not with configuration, but with an audit: we examine the existing templates, chunks, snippets, and how content managers actually edit pages. The output is a map of entities and relationships, from which the data schema is born.
Next comes design: we determine which blocks become separate TVs, where nested MIGX configurations are needed, and where a single field is enough.
The schema is fixed before the configuration is written — otherwise you end up with a set of fields that no one fills in during real work.
- Audit of content and templates. We look at what page types exist, how they differ, and where editors are already working around the system manually. We record bottlenecks and the volume of data.
- Data schema. We describe the entities, their fields, types, and the relationships between blocks. We agree with the client on what exactly is edited and what stays in the template.
- MIGX configuration. We build configurations for each entity: fields, nesting, output order, input restrictions. We set up the binding to TVs and templates.
- Frontend output. We write snippets and chunks that expand the data into markup: lists, cards, repeating blocks. We test on real volumes, not on three test records.
- Testing and acceptance. We run through the editor's scenarios: add, reorder, delete, copy a block. We look at what happens with empty fields and broken data.
- Documentation. We prepare a guide for content managers: what is responsible for what, how to add a new block, what not to do.
- Handover and support. We show the client's team how everything is set up, hand over access and source files. We stay in touch for further improvements.
This order produces a predictable result: the content manager assembles pages on their own, and the developer doesn't edit them by hand after every publication.
If you already have MIGX configurations that "work, but are scary" — describe the task, and we'll come back with an estimate and a plan.
Configurations, templates, and regulations: what you get
The deliverable is not a "configured site" but a kit your team can work with without us: adding fields, changing output, granting access to new employees. Everything lives in the project repository, not in a chat thread.
- MIGX configuration files — definitions of all TV variables and groups: which fields, types, order, nested blocks. Imported in a single operation on any environment — test, pre-release, production.
- Output templates — snippets and chunks with explicit names and comments: where the list is rendered, where the card is, where the filter is. Edits are localized, not smeared across a dozen files.
- Data schema — a map of relationships between sections: which records reference each other, what happens when a parent is deleted, where constraints are needed.
- Instructions for editors — how to add a material, fill in a nested block, reorder elements. With screenshots and breakdowns of common mistakes.
- Update regulations — the procedure for editing configurations, field naming rules, what to do before deploying to production.
- Access policies — a role matrix: who edits content, who changes the structure, who only views. Taking into account user groups and section-level permissions.
- Handover kit — a backup of configurations, the deployment procedure on a new environment, contacts for questions about non-standard cases.
We separately document what fell outside the scope of the current task — so that as the project evolves, the structure doesn't have to be rebuilt from scratch. Describe your task — we'll come back with an estimate and a plan.
Case study: 4x faster catalog population
What it was before
A catalog of 1,800 items was managed by a content manager: each card was assembled manually — description, specifications, gallery, linking to sections.
One item took 25-30 minutes, and during bulk updates of prices and availability, edits had to be made line by line, cross-checking tables. Populating a new category of 120 products stretched over a week, and it was a bottleneck: other work was waiting on content.
What was changed
We set up MIGX — MODX's built-in tool for repeating blocks: specifications, packaging options, images, and section links became fields of a single form instead of manual markup.
The content manager fills in a structured card, and the template assembles the output itself — no code edits for each category.
We added import from a table: bulk updates of prices and stock go as a batch, not line by line. Input validation does not let empty required fields through — broken cards never make it into the catalog.
What it became
| Metric | Before | After |
|---|---|---|
| Time per card | 25-30 min | 6-8 min |
| New category (120 items) | ~7 days | 2 days |
| Bulk price update | line by line | as a batch, in a single pass |
| Errors in specifications | regular | filtered out by validation |
The speed of population increased 4x, manual template edits for new categories are gone — the structure is defined by the form, not by code.
Testimonial
"Previously, launching a category hinged on content — we waited for everything to be entered by hand. Now the manager fills in a form, and the output assembles itself. We update the catalog in batches, without late-night edits," — head of the e-commerce division.
How does MIGX differ from standard TVs?
Standard TVs in MODX are a flat list of fields tied to a resource: one value per parameter. As long as the content is linear, this is enough.
As soon as structure appears — a block of advantages, a pricing table, a list of branches with addresses and opening hours — the flat model breaks down, and the editor starts spawning dozens of identical TVs with suffixes in the name.
MIGX solves this differently: it stores data as a set of records with their own field schema, rather than as a single value.
You describe the configuration once — which fields a record has, what types they are — and you get a repeatable block that the editor fills in as many times as needed.
This is the key difference of migx vs tv: not a "field," but a "collection of fields with structure."
Nesting comes as the second level. Inside a record, you can declare a child group — for example, a list of phone numbers for a branch, or a set of specifications for a product.
With standard tools, this can only be assembled through separate resources and links, which for the editor turns into manual work with the tree. In MIGX, child records live inside the parent record and are edited in a single window.
Output flexibility is the third difference. The configuration delivers data to the template as a ready-made structure, and you decide how to lay it out: display it as a table, accordion, slider, or pass it to an external service.
The same set of records is reused in different representations without duplicating content in the database.
The price for this is the barrier to entry. The MIGX configuration is described manually, and an error in the field schema doesn't show up immediately, but at the output stage.
That's why we lock down the structure before filling: we agree on the composition of records, field types, and nesting, test the output on a test set — and only then hand it over to the editor. This way, the content manager gets a clear form, not a builder where it's scary to break something.
Common technical concerns when implementing MIGX
MIGX is a constructor managed from the admin panel: the field structure is stored in the configuration, and the values are stored in a separate table linked to the resource.
This gives rise to the main concerns: whether the query will slow down on a catalog with thousands of items, how to migrate already accumulated content, and what will happen when MODX is updated.
Will MIGX slow down the site on a large catalog?
The field configuration itself is cached, so the overhead for rendering the form is minimal.
The bottleneck is the queries in the templates: if you pull all values in a single query without filtering by key and without an index on the binding column, the response time grows linearly with the volume.
We add indexes for the actual queries, limit the selection to the necessary fields, and enable snippet caching where the data rarely changes. On a catalog with several thousand items, the page is served in the same time as on an empty database.
How do you migrate existing content to MIGX without losses?
We migrate the data with a script: we read the current fields, map them to the configuration structure, and write them to the table with type matching validation.
Before writing, we take a full database dump and run the migration on a copy — we verify the number of records and the control values for the key fields.
If the structure has changed, we supplement the old records with the missing fields using default values so that the templates don't break on empty spots.
Is this compatible with MODX updates and other extras?
MIGX works as a regular extra through the standard installer, so core updates don't break it. Risk arises from conflicts with other extensions that modify the same tables or intercept form output.
We pin versions in the repository, update on a copy, and test the key scenarios before rolling out to the production site.
What about support if the field structure changes six months later?
The configuration is stored in the project files, not just in the database, — edits go through review and end up in the change history. Adding a field doesn't require rewriting the templates: new values are picked up as they are filled in.
We hand over the field schema and instructions for typical edits to the client's team so that minor changes don't have to wait for us.
Let's discuss your MIGX MODX task
To come back with an estimate and work plan for MIGX MODX, we need not a brief saying "make it look nice," but a description of the content model: what entities exist, how they are related, and who will populate them.
MIGX in MODX is about arbitrary structures: multiple images with captions, repeating feature blocks, nested lists. The more precisely you describe what the editor should enter by hand, the fewer iterations will be spent on reworking TV parameters and output templates.
Describe the task — we'll come back with an estimate and work plan. What's useful for us to know before starting:
- what content types already exist in the system, and which need to be added (catalog, portfolio, team, documents);
- how entities are related to each other: one-to-one, one-to-many, with or without sorting;
- who populates the content and how technically savvy they are — this determines how simple the input form should be;
- whether existing data needs to be migrated and in what form it currently sits;
- which output templates are already coded and what needs to be inserted into them;
- whether there are restrictions on access, roles, and language versions;
- what result you consider done: timelines, acceptance, further support.
Based on these points, we assemble a map of the MIGX configuration, assess the scope of work, and come back with a plan: what we do at the setup stage, what at the output stage, and where your data and decisions are needed.
If part of the content model is not yet defined — that's fine, we'll sort it out on a call and lock it into the plan.
