Problem/Motivation

Today, overriding a display hands the editor the full builder — every panel, every style control, site-wide blocks. Fine for a site builder. Wrong for an occasional editor tweaking one node.

This adds a second profile, editor, config only, no code. It keeps just what that job needs: place components from a curated library, configure them, undo/redo, publish. It drops what it doesn't: Styles, Blocks, Visibility conditions, Scaffold, Navigator, the Instances panel — anything that's site structure or design-system territory, not this one node's content.

Proposed resolution

Same mechanism that already powers default. One new .yml file, one permission (auto-derived), nothing else changes.

Remaining tasks

User interface changes

API changes

Data model changes

Issue fork display_builder-3620224

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

About issue forks

Comments

mogtofu33 created an issue. See original summary.

mogtofu33 opened merge request !367

pdureau’s picture

pdureau commented
Assigned: Unassigned » pdureau
Issue tags: +Rotterdam2026

From discussion with users and curious in DrupalCon Rotterdam, it seems this addition is expected.

pdureau’s picture

pdureau commented
Assigned: pdureau » mogtofu33
Status: Needs review » Needs work

Test:

  • Start sidebar: only libraries ✅ because Instances (which is not showing much for users with restricted permissions) and Navigator (no need for simple usage)
  • Toolbar: the same as the default profile ❌ except translations. Are we sure content editors don't need to edit translations?
  • Main view: only Canvas ⚠️ it is OK until the moment a component is not easily usable with preview (collapsible, sliding...). Are we sure we don't need Scaffold or Navigator?
  • Libraries: no blocks. ❌ Content editors needs blocks, like Fields in a content entity override
  • Menu items: ✅ no "save presets", that's good because presets are config entities so content editors can use them but not create them.
  • Floating: ✅ no highlights, which is OK. ⚠️ there is "Scaffold options" without "Scaffold", but it is OK because it is simply not load.

Is there a way to make it the default value of content entity overrides without hardcoding its config entity ID anywhere?

mogtofu33’s picture

mogtofu33 commented
Assigned: mogtofu33 » pdureau

This profile was a starting point, would be better you create what you think is best for me to review.

Is there a way to make it the default value of content entity overrides without hardcoding its config entity ID anywhere?

You mean you want a mix of profiles we already set? I thought more of a necessary configuration from admin at the beginning of the project.

Keep default everywhere, and the editor is a suggestion, as it needs other related settings on the website I guess.
Could integrate in a Recipe but I am not sure about that being Display Builder core.

pdureau’s picture

pdureau commented

Keep default everywhere, and the editor is a suggestion, as it needs other related settings on the website I guess.

OK, let's keep things simple.

This profile was a starting point, would be better you create what you think is best for me to review.

OK, I will add at least translation button and block library.

We can consider Scaffold later if we get feedback asking for this.

pdureau’s picture

pdureau commented
Assigned: pdureau » mogtofu33
Status: Needs work » Needs review