[6.x] Restore field action menus and handles in the new form system - #19480
Draft
brianjhanson wants to merge 1 commit into
Draft
[6.x] Restore field action menus and handles in the new form system#19480brianjhanson wants to merge 1 commit into
brianjhanson wants to merge 1 commit into
Conversation
`BaseField::formNode()` never called `->actions()`, so the "⋮" menu every
field carried in Craft 5 — Field settings, Copy field handle — was absent from
every form the new system renders, along with the inline handle chip admins see
with the "Show field handles in edit forms" preference on.
Everything feeding that menu survived the port but had no caller:
`actionMenuItems()`, `copyAttributeAction()`, `showAttribute()`, the six native
field overrides, and `FieldLayoutActionMenuItemsResolving` (whose yii2-adapter
bridge to `DefineFieldActionsEvent` was already wired and waiting). The
`inputHtml()` tier was orphaned too, which left `copyAttributeAction()` with no
live call sites at all.
Adds `craft:action-menu` and `craft:copy-attribute` Form Nodes, emitted from
`formNode()` into the Field node's existing `actions` slot. Node UIDs derive
from the control path, not the layout element UID: that UID is nullable, and
one layout element can emit several Fields (`LatLongField`).
Item behavior is now declarative. `HtmlStack::jsWithVars` registers JS on a
full page load only, so a menu built that way is inert on exactly the
Inertia-rendered screens this targets. Items instead carry `BaseAction`
descriptors that `craft-action-item` runs, with listeners in
`resources/js/modules/fields`. Matrix's expand/collapse-all and the Matrix and
Addresses copy-all items are converted the same way; their listeners scope to
the invoking item's own `craft-field`, preserving the direct-descendant
scoping the old jQuery selectors relied on, which the two render paths spell
differently.
`ElementHtml`'s three private action-menu rendering methods move to a shared
`Cp\Components\ActionMenu`. Both renderers now consume one canonical item
shape, so the HTML and Vue paths can't drift.
Two known gaps: the old handlers hid or disabled items on menu open (expand-all
only when something was collapsed, copy greyed out when empty), which isn't
reproduced; and "Copy value from site…" is still absent, since it needs a
`values` key on `CopyElementValuesController`'s response, a Vue site picker,
and a listener that calls `setValue()` — the legacy modal resolves its field
through `.closest('.menu').data('disclosureMenu')`.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
📚 Storybook previews@craftcms/ui — open Storybook No changed components detected in this Storybook. resources/js — open Storybook No changed components detected in this Storybook. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
BaseField::formNode()never called->actions(), so the "⋮" menu every field carried in Craft 5 — Field settings, Copy field handle — was absent from every form the new system renders, along with the inline handle chip admins see with the "Show field handles in edit forms" preference on.Everything feeding that menu survived the port but had no caller:
actionMenuItems(),copyAttributeAction(),showAttribute(), the six native field overrides, andFieldLayoutActionMenuItemsResolving(whose yii2-adapter bridge toDefineFieldActionsEventwas already wired and waiting). TheinputHtml()tier was orphaned too, which leftcopyAttributeAction()with no live call sites at all.Adds
craft:action-menuandcraft:copy-attributeForm Nodes, emitted fromformNode()into the Field node's existingactionsslot. Node UIDs derive from the control path, not the layout element UID: that UID is nullable, and one layout element can emit several Fields (LatLongField).Item behavior is now declarative.
HtmlStack::jsWithVarsregisters JS on a full page load only, so a menu built that way is inert on exactly the Inertia-rendered screens this targets. Items instead carryBaseActiondescriptors thatcraft-action-itemruns, with listeners inresources/js/modules/fields. Matrix's expand/collapse-all and the Matrix and Addresses copy-all items are converted the same way; their listeners scope to the invoking item's owncraft-field, preserving the direct-descendant scoping the old jQuery selectors relied on, which the two render paths spell differently.ElementHtml's three private action-menu rendering methods move to a sharedCp\Components\ActionMenu. Both renderers now consume one canonical item shape, so the HTML and Vue paths can't drift.Two known gaps: the old handlers hid or disabled items on menu open (expand-all only when something was collapsed, copy greyed out when empty), which isn't reproduced; and "Copy value from site…" is still absent, since it needs a
valueskey onCopyElementValuesController's response, a Vue site picker, and a listener that callssetValue()— the legacy modal resolves its field through.closest('.menu').data('disclosureMenu').Description
Related issues