[brianjhanson]

Stacked on #20276. Core's control panel JavaScript no longer needs jQuery or Garnish; the Yii2 adapter loads them for itself and for plugins.

Description

 CpAsset (core)
   AnimationBlockerAsset, D3Asset, ThemeAsset
-  JqueryAsset, GarnishAsset (+ touch events, Velocity)

 CraftJsAsset (adapter)
   CpAsset
+  GarnishAsset (+ jQuery, touch events, Velocity)
   jQuery UI, other vendor assets

What moved where:

core (native DOM)                         adapter (jQuery, for plugins)
├── grid, slideout, charts, modals        ├── Craft.BaseElementSelectInput,
├── element select inputs                 │   EntrySelectInput, AssetSelectInput,
│   <craft-element-select-input> etc.     │   TagSelectInput (jQuery copies)
├── MenuHtml::disclosureMenu()            ├── LegacyMenuHtml → legacy disclosure markup
│   → <craft-action-menu>                 │   (its Matrix drives it with jQuery)
└── legacy screens' tabs → <craft-tabs>   └── Craft.Tabs

• The ported classes drop their $-prefixed jQuery getters. A GitHub search found few plugins reading them. CpScreenSlideout keeps $container for adapter callers.
• elementSelect.twig always renders the custom element. A plugin's jsClass boots through input-class, so subclasses of the adapter's Craft.BaseElementSelectInput keep working.
• Server-rendered menus keep group headings, the current item, statuses and info icons. A slideout opened from one returns focus to the menu's button.
• The inline scripts that core templates emit no longer call $.

Evidence

New regression tests fail on the old code and pass now:

LegacyAssetsTest
  CpAsset html  → contains theme CSS, no jquery.js, no garnish.js
  MoneyAsset    → garnish.js before Money.js
MenuHtmlTest
  disclosureMenu(items with heading, selected, status, info)
    → <craft-action-menu> with group heading, current item, status dot, info icon
slideout.browser.test
  open from craft-action-menu item, item hidden, close
    → focus lands on the menu's invoker
base-element-select-input.test (native)
  add/remove/reorder chips without jQuery on the page

In a browser on a core-only install (window.jQuery undefined), these load with no console errors: the dashboard, the entry editor and its tabs, the entry type and section settings, the assets and users indexes, and the system report. The element select inputs and a rendered menu work there too.

Local CI run on this branch:

• vp fmt --check, vp lint, lint:styles, the Tailwind class check, typecheck, @craftcms/ui#check:types: pass
• test:ui 3409, unit 2315, browser 122: pass
• pint, rector --dry-run, phpstan: pass
• pest 12,039 passed; composer tests-adapter 784 passed

Server-built menus on a bridged cp/Screen, driven in Chromium on a core-only install: a throwaway asCpScreen() route with action and context menu items, plus the breadcrumb template rendered into its content.

• Action menu: group heading, current item, status dot, info icon and destructive item all render.
• Context menu: labels itself from its current item.
• All three menus open from their buttons. Escape closes them and returns focus to the button, arrow keys move between items, and a link item navigates.
• There were no console errors, and window.jQuery was undefined.

In core, breadcrumbs reach the page as data and Breadcrumbs.vue renders them, so _layouts/components/crumbs.twig only runs for a screen that turns off fragment collection. Nothing in core does that.

🤖 Generated with Claude Code

[github-actions]

📚 Storybook previews

@craftcms/ui — open Storybook

No changed components detected in this Storybook.

resources/js — open Storybook

No changed components detected in this Storybook.

[Copilot]

🟡 Changes recommended

Wrapped initialization scripts no longer execute in modal content, which can break plugin controls across the affected modal and deletion flows.

1 open issue

• Wrapped initialization scripts are not executed · New

2 resolved since last review

• Custom select is inert when the Yii2 adapter is unavailable
• Form serialization turns spaces into literal plus signs

_{Review effort: Balanced}

[Copilot]

🟡 Changes recommended

Descendant scripts bypass awaited asset loading, allowing initialization to run before dependencies load and the returned promise to resolve prematurely.

1 open issue

• Await loading of descendant scripts before running initialization · New

1 resolved since last review

• Wrapped initialization scripts are not executed

_{Review effort: Balanced}

[Copilot]

🟡 Changes recommended

Unawaited blocker-details insertion can leave controls uninitialized and execute body scripts before dependencies load, while unstable nested action IDs can recreate grouped actions and lose keyboard focus.

2 open issues

• Await blocker details insertion before initializing controls · New
• Strip nested action IDs to preserve focus on refresh · New

1 resolved since last review

• Await loading of descendant scripts before running initialization

_{Review effort: Balanced}

[Copilot]

🔵 Needs a closer look

Human assessment is needed to evaluate asynchronous preview races and overlapping image-editor handlers that can cause stale content or duplicate editors.

No open issues 🎉

2 resolved since last review

• Await blocker details insertion before initializing controls
• Strip nested action IDs to preserve focus on refresh

_{Review effort: Balanced}

[brandonkelly]

@brianjhanson Claude made some changes in response to a few rounds of Copilot reviews. If they look good to you, feel free to merge.

[brianjhanson]

After chatting with @i-just this morning, I'm doing a pass of this branch against CKEditor to make sure we still have everything we need in place. Hoping to wrap that up today.

[brianjhanson]

Collapsed into #20378, which carries this work plus #20276 and #20359 on a single branch rebased onto 6.x. Reviewing one branch beats keeping three bases in sync.

Everything here came across unchanged, including the LegacyAssetsTest and MenuHtmlTest regression tests.