Grouped entry types for Matrix fields

[brandonkelly]

Description

Adds the ability to group entry types within Matrix fields:

Related issues

• [5.0]: Better content management with matrix fields (UI/UX for editor + admin) #14179
• Matrix Block Grouping and Enhanced Drag-and-Drop for Craft CMS #15554
• Improvement for Matrix Fields: Use of Field Editor Instead of Clip View #15895
• Improve matrix / entry selection #17349

[linear]

CMS-1251 Grouped entry types for Matrix fields

[mmikkel]

Love this! It’s going to improve the AX in fields w/ a lot of entry types a lot.

One aspect that the PR doesn’t improve is the need for scrolling in the “New entry” disclosure menu once you get above a certain number of entry types in the field (and below a certain viewport height). I get that scrolling can’t always be avoided, but it doesn’t feel like awesome UX when it happens so I think it’d be worth exploring ways to minimize the need for it.

In cases where the viewport width would permit it, it’d be great if the “New entry” disclosure menu could become wider, allowing the entry type groups to stack both horizontally and vertically.

Another option is to render dedicated “New…” buttons/menus per group if there is enough horizontal space (but I’m guessing that’s off the table?)

[ryansupercool]

This is going to be great!

Would it be possible to have the ability to search/filter the list like we have in the "Entry Type" field when adding an Entry Type to a section?

[alexanderbuergin]

Really cool to see this feature finally coming to Craft CMS—it’s something we’ve been waiting for a long time, and great to see it being tackled!

That said, one thing I don’t quite get: why isn’t there any grouping UI for the input fields themselves, similar to how Neo (https://plugins.craftcms.com/neo) fields handled it, or how the Extend Matrix (https://plugins.craftcms.com/matrix-extended) plugin allows for grouping? Is the dropdown approach really the best possible presentation for this? Probably not. From a content-heavy perspective, this works a bit better

That kind of grouping significantly improves clarity and makes it much easier for content editors to find what they need quickly—especially without excessive scrolling. If you’re dealing with, say, 50 block types (whether that’s good practice or not is another topic), the current UI still gets very overwhelming. So I’m genuinely curious why that specific feature hasn’t been included.

One last question: why not simply reuse the existing Field Layout Designer UI here? We already have a powerful, tab-based drag-and-drop interface in the field editor. Whether placing a field or an entry type, the logic is essentially the same—so why introduce a separate UI for this instead of building on what already works?

See more here: #15895

Thanks again for the great work—this will still be a huge improvement overall!

[brandonkelly]

In cases where the viewport width would permit it, it’d be great if the “New entry” disclosure menu could become wider, allowing the entry type groups to stack both horizontally and vertically.

Another option is to render dedicated “New…” buttons/menus per group if there is enough horizontal space (but I’m guessing that’s off the table?)

My knee-jerk reaction is that I don’t love either of these ideas. I’m open to playing with them, but not going to let it hold up the changes in this PR.

[brandonkelly]

Would it be possible to have the ability to search/filter the list like we have in the "Entry Type" field when adding an Entry Type to a section?

@ryansupercool Yep! I was already thinking that would be a good addition. Done.

[brandonkelly]

One last question: why not simply reuse the existing Field Layout Designer UI here? We already have a powerful, tab-based drag-and-drop interface in the field editor. Whether placing a field or an entry type, the logic is essentially the same—so why introduce a separate UI for this instead of building on what already works?

@alexanderbuergin The field layout designer is extremely specialized for managing field layouts specifically. It would be a massive undertaking to repurpose them for this unrelated (and much simpler) use case, and without any tangible benefit. And I’m not sure it would be smart UX-wise, as it would seem like you’re editing a field layout at first glance.

[alexanderbuergin]

In cases where the viewport width would permit it, it’d be great if the “New entry” disclosure menu could become wider, allowing the entry type groups to stack both horizontally and vertically.
Another option is to render dedicated “New…” buttons/menus per group if there is enough horizontal space (but I’m guessing that’s off the table?)

My knee-jerk reaction is that I don’t love either of these ideas. I’m open to playing with them, but not going to let it hold up the changes in this PR.

To be honest, the solution Neo and now Matrix Extend use is definitely not perfect or particularly elegant—but from a user perspective, it’s still far more friendly than the current approach with the extremely long dropdown menu. As I mentioned before, if you end up with 50 blocks in that list, many of our clients really struggle to manage and edit their content efficiently. That’s why I see a real need for a better solution here.

Honestly, the tab-based approach, like the one used in Neo and Matrix Extend, is already much more user-friendly than having to scroll through such a long dropdown, especially when there are more than 15 blocks. This becomes a real pain point for clients, particularly on smaller screens like a MacBook, where the available space is limited.

If there’s some genuine commitment from your side to invest time in improving the UX, I’d be willing to contribute—maybe by sketching out concepts or working together on possible drafts. But there needs to be more willingness to go beyond the current idea.

[alexanderbuergin]

One last question: why not simply reuse the existing Field Layout Designer UI here? We already have a powerful, tab-based drag-and-drop interface in the field editor. Whether placing a field or an entry type, the logic is essentially the same—so why introduce a separate UI for this instead of building on what already works?

@alexanderbuergin The field layout designer is extremely specialized for managing field layouts specifically. It would be a massive undertaking to repurpose them for this unrelated (and much simpler) use case, and without any tangible benefit. And I’m not sure it would be smart UX-wise, as it would seem like you’re editing a field layout at first glance.

I can understand the concern that this approach might be confused with the field layout builder. However, in practice, the developers working with these tools usually know what content type they’re editing. From my point of view, my main consideration was actually a general principle from UX design: you should use as few different UI elements as possible to represent as much functionality as possible. In other words, different functions should look and feel similar wherever possible. The added benefit is that you end up with less code—less CSS, fewer unique components, and so on.

Of course, I get that your field builder is much more complex than what’s needed for grouping entry blocks within the Matrix. Still, I think it would be worth considering aligning the UI of the Matrix group manager a bit more closely to the field manager. You could even offer visual variants—so it’s clear it’s the same component, just adapted with an extra layer or two to highlight the difference in context.

If there’s interest, I’d also be happy to contribute some concepts or sketches here. But if you’d prefer to keep things as they are now, that’s understandable. As I said, the current solution isn’t bad at all—the idea was just that there’s already a UI element that essentially serves the same purpose from a visual and functional point of view. What’s going on technically behind the scenes isn’t always relevant for the UX; what matters is what the user sees and experiences. In both cases, you’re assigning items to a group—whether it’s the field manager or the new Matrix group manager.

[mmikkel]

Finally took this feature for a real spin. Love it, but I have a couple of thoughts 😅

1. When creating new Matrix fields, it'd be great if the Entry Types setting would be pre-populated with an initial "General" group – similarly to how new field layouts have an initial "Content" tab available without having to create one.

A lot of Matrix fields (e.g. with few types) won't have a need for grouping, so always having to create that required initial group (and name it) when creating new fields, is probably going to feel like a little bit of an hurdle in the long run.

2. I love the search field being added to the author-facing entry type selector – it's really going to help with fields w/ a ton of types, and it also mitigates the scrolling thing. But, the search input admittedly feels a little bit redundant/weird in fields with very few types 😅 I think it'd make sense to maybe have the search field appear only in type selectors with a certain minimum amount of types (maybe 5? 10?).

3. For the search feature, it'd be great if group names were included (similarly to how field group names were included in the FLD search in Craft 4). Devs might create a group called "Visuals", but if authors search for "visuals", no entry types will display unless there are some actual types w/ that phrase in their name. I'm pretty sure this will become a minor annoyance because authors will search for "visuals", expecting all the entry types in the "Visuals" group showing up.