Craft 5 nested entries vs Matrix: why we’re sticking with Matrix (mostly)

With Craft 5 came the ability to nest entries inline within CKEditor, dropping structured components straight into the flow of rich text. It's a big leap in flexibility, and our dev team has had it on our radar for a while. As a team, we make a point of keeping an eye on how other developers we respect across the Craft community are approaching the same problems, and seeing how others structure their page builders prompted me to revisit the question: should we be using nested entries, or is our current Matrix page builder still the right call? And does all that flexibility risk giving content authors an overwhelming amount of choice?

Our current Matrix setup is something that has been refined over time. We generally have a page builder Matrix along with an article builder Matrix. They may share some components, however, the article builder will likely be more editorial in style, while the page builder will house more interactive and dynamic components.

This approach has always worked really well for us. It allows the client to create custom pages as required. Editors can mix and match blocks, drag them into any order and build pages that look completely different from one another, all without developer input. At the same time, it keeps guardrails in place so editors don’t stray too far from the design decisions taken by our team.

With larger sites there is a need to create a large number of custom blocks. Our page builder template page becomes a really important resource here, displaying all the blocks available to the user, neatly signposted with clear labelling and organisation. We’ve also refined how we group blocks, so the user isn’t faced with a cumbersome list.

However, the possibility of an entirely nested entry setup intrigued me. This could give the editor a near infinite level of flexibility, which is exactly what made me cautious. In theory, they could adjust the layout of any element through nested entries. For example adjusting the position of an image within a block without the need for a developer to redefine the CSS or adjust the fields within the backend of Craft.

We are always looking for ways to improve, so I decided to give it a go and see what the benefits of this approach could be - I spun up a fresh Craft install to test.

This approach still uses a conventional Matrix block for the overall structure of the page, however, instead of predefined blocks, rows of CKEditor fields can be added. Within these predefined fields, alongside the text, we can add nested entries. These can be buttons, CTAs, images or pretty much any block that we choose.

The biggest win was flexibility. Editors could now place components inside the flow of the text itself, with images sitting inline alongside copy and CTAs dropped mid-paragraph. Our page builder already lets editors add, remove and drag blocks into any order, but each block is a self-contained section. Nested entries take that a level deeper. If an editor wanted a row of four CTAs, they could build one themselves, without needing a new block from us.

On the development side, it was easier to maintain than I expected. In Craft 5, entry types can be shared, so our existing page builder blocks could be reused as nested entries, with the same template partials behind both. Setting up the rows themselves was straightforward too, with a dropdown allowing you to choose both the number of columns and how they should be laid out on the page. From here the corresponding number of CKEditor fields will be displayed for the editor’s content.

The main drawback for me was control over spacing. Working in Twig and Tailwind, I’m used to having precise control over the padding and margins between every element, because each of our blocks is designed with its own spacing built in, so they sit together cleanly in any order. With nested entries inside CKEditor, authors can place blocks almost anywhere, so spacing is harder to predict and content doesn’t always sit the way the design intends.

Baseline rules, such as a standard bottom margin on most elements and larger spacing around images or quotes, would still work. But it isn’t immediately obvious how to handle every combination of blocks, and getting it right would likely need new or different spacing rules. That needs further investigation, and it adds complexity for a benefit authors may not need.

The bigger concern is on the editor side. With this much flexibility, it’s easy to create layouts that simply don’t work. Our team is always happy to help, but I think this approach would mean a lot more hand-holding, especially for clients who are new to Craft.

Our predefined blocks put the design decisions in the hands of the designer. Editors pick from a set of components that have already been designed and tested, which makes building a good-looking page simple. With a row builder, that responsibility shifts onto the editor.

For most of our clients, I don't think nested entries is the right approach. They value the structure our blocks give them. Each block follows rules set by our designers during the design phase, so this means there are guidelines in place to present their content easily and quickly on their site, without risking design integrity.

A row builder is also much harder to test. With so many possible combinations, it would be very difficult to cover every scenario during testing and be confident nothing breaks on the front end.

Where I can see it working is a controlled article builder. A pared-back set of nested entries, perhaps with just two columns would give editors more freedom with editorial content, without the need to make complex design decisions.

The next step is to carry out some further testing. So far we’ve only tried it on a basic Craft install, without real brand rules or guidelines. We'll be putting them through it's paces on a full build with a full design system behind it. It won't necessarily be a live project, but it will be realistic enough to show whether the spacing and consistency challenges hold up under real-world conditions.

We'll also be handing it to our client services team and designers to populate with test content and report back on the editing experience. They work alongside clients every day and understand how content authors actually use the CMS, which makes them the best proxy we have for real-world usability.