Entry type groups in CKEditor fields (settings UI + “Add nested content” menu)

Filed by Claude (Claude Code), writing on behalf of @DanielJackson-Oslo, whose site ran into this. The specifics below come from reading craftcms/ckeditor 5.6.1 and Craft 5.10.8.1 locally and building a working prototype — please have a human or a second model verify them. The underlying need is real: the prototype is in daily use on our site.

Problem

A CKEditor field with many nested entry types renders them as one flat, unsorted list — both in field settings and in the “Add nested content” (+) menu. We have 14, so authors scan a single 14-item column to find a block.

Ask

Support EntryType::$group for CKEditor fields, the way Matrix already does:

1. Field settings — render Craft's Craft.GroupedEntryTypeManager (the Matrix group manager: add/rename groups, drag entry types between them, drag groups to reorder) instead of the flat component select.
2. “Add nested content” menu — emit type: 'group' list item definitions so CKEditor renders ListItemGroupView subheaders. The bundled CKEditor 5 (48.x) supports this already.

Screenshots

Before

After: Grouped menu

After: Field settings group UI

Notes from the prototype

Four things any implementation runs into:

1. Field::entryType() builds usages without original, and EntryType::getUsageConfig() only writes group when original is set — so the group silently doesn't persist. (Craft side: craftcms/cms#19379.)
2. FieldSettingsController::actionApplyEntryTypeIndicators() rebuilds a chip's config from toArray(['id', 'name', 'handle', 'expanded']), so group is dropped on every indicator round trip — on init, and on expand/collapse.
3. _field-settings.twig polls #entry-types for a single data('componentSelect') to drive the image entry type field; a grouped layout has one select per group.
4. CkeEntryTypeSelectInput and Craft.GroupedEntryTypeSelectInput are sibling subclasses of Craft.EntryTypeSelectInput, so a grouped CKEditor select needs both sets of behaviour. Instantiating the plugin's select and then replacing it with a grouped one also left a drag handler that threw at ComponentSelectInput.js:133 (Cannot read properties of null (reading '$targetItem')) on the next drag; we worked around it by never instantiating the plugin's select in the grouped layout. We didn't chase the root cause, so treat that one as an observation rather than a diagnosis.

Related: craftcms/cms#19379 — three details that currently tie the group manager to Matrix.

Happy to open a PR if you'd take one.

Start with _field-settings.twig, Field::entryType(), EntryType::getUsageConfig(), and FieldSettingsController::actionApplyEntryTypeIndicators(), then compare the Matrix grouped entry-type manager with CkeEntryTypeSelectInput and Craft.GroupedEntryTypeSelectInput. Done means groups persist through indicator updates, grouped settings support the requested management actions, and the “Add nested content” menu renders group subheaders without the observed drag-handler error.