DataForm: openAs:menu

[oandregal]

Follow-up to #75290

What?

This PR introduces a new openAs: 'menu' in the panel layout, that complements the existing modal and dropdown options.

Why?

To support complex behaviors, like editing the template, which includes multiple contextual actions:

Screen.Recording.2026-02-11.at.14.30.32.mov

How?

• Introduce a new openAs: 'menu' option for the panel layout.
• Update the template field Edit function to render a menu.

Testing Instructions

QuickEdit:

• Enable the experiment, and visit Site Editor's Page screen. Click the "QuickEdit" action to open the modal.
• Interact with the template field.

Storybook:

• Run locally (npm run storybook:dev) and visit the panel layout story.
• Switch between menu, modal, and dropdown modes.

[github-actions]

Flaky tests detected in 0e232bc.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/21907134695
📝 Reported issues:

• [Flaky Test] Should save the changes #43174 in /test/e2e/specs/editor/plugins/wp-editor-meta-box.spec.js

[oandregal]

Alternatives considered:

• Style tweaks to the template edit so that it resembles the panel layout, even though it uses the regular one. This is fragile. Every style change in the panel layout needs to be ported to the field as well.
• Surface actions in the modal, like we do in the post editor. Doable, though we need to make sure to filter the action that opened the modal. Interaction-wise, it's weird that the modal opened by an action has the same actions.

All things considered, something like this PR feels more future-proof, robust, and flexible.

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: oandregal <oandregal@git.wordpress.org>
Co-authored-by: jameskoster <jameskoster@git.wordpress.org>
Co-authored-by: ntsekouras <ntsekouras@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[jameskoster]

Are we certain this is an api we want to add, does it have any immediate use beyond the template example? My initial reaction is that it seems quite niche which makes me a bit apprehensive. A menu with a single item isn't ideal from a UX perspective either.

I understand that the Template 'field' in the editor Inspector has additional actions like "Edit template", but this feels tangential and a bit unrelated to the field value, so should arguably live elsewhere in the UI.

Stepping back, the Template option is essentially a select or radio mechanic. I think what I'd most like to see is a richer radio-based component—something like this Radio Card example—that we could use here. That way it's just a case of rendering the control (either inline, or in a modal etc.) as we do for all other fields types. Quick mockup to illustrate the idea:

I recognise it's too late to get something like this done for 7.0. But unless we're confident about the api maybe we omit the template field from Quick Edit initially, or just use something simple like SelectControl?

[ntsekouras]

That's a tough one.. I've thought for a while, explored a few things and maybe this API makes sense with some things to iron out.

To start with, right now template field is a special field that seems to render properly in regular layout, but unusable in panel and maybe more. Here with the change of the edit to return MenuGroup, it probably makes it more usable in more layouts. Additionally if we change the placement of the panel/menu.tsx to:

anchor: popoverAnchor,
placement: 'bottom-end' as const,
shift: true,

It feels quite natural to me. Also note in the below video how the field is rendered in regular layout (we'd probably need a few adjustments to the edit to render the label in different positions).

What I don't love is that the consumer of the field would need to use the openAs: 'menu'. Could this be absorbed somehow by the field in config or something? 🤔

Screen.Recording.2026-02-13.at.11.31.41.AM.mov

[oandregal]

I'm not fully sold on the exact details of the API (more on this below), but the ability to create action-like experiences in fields feels useful. It's also true that I haven't yet seen more places that require experiences like these:

The reason I'm not sold on the current details is because this PR makes the Edit not a standalone control: half of it is defined by the field, the other half is defined by the panel layout (menugroup). I'm not convinced this is the final form factor we want. I feel there’s something here, but I can’t quite put my finger on it yet.

I like the RadioCard idea. There are a few pieces to connect here: the elements have a value/label (the value could be the template' slug), a WordPress-agnostic RadioCard control, and then another piece to connect the two (that fetches templates from the slug and feeds them to the RadioControl). Or perhaps we extend the elements to contain more info (url, image, etc.). This can take a few days to get the details right.

I'm going to switch gears to make template selection a select control, like in wp-admin:

Screen.Recording.2026-02-13.at.10.47.12.mov

[oandregal]

Prepared the select approach at #75518