Repository navigation
Conversation
|
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 If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
|
Warning: Type of PR label mismatch To merge this PR, it requires exactly 1 label indicating the type of PR. Other labels are optional and not being checked here.
Read more about Type labels in Gutenberg. Don't worry if you don't have the required permissions to add labels; the PR reviewer should be able to help with the task. |
3b424bb to
9af01bd
Compare
|
Size Change: +440 B (+0.01%) Total Size: 8.6 MB 📦 View Changed
|
9af01bd to
932e351
Compare
|
Flaky tests detected in c5a8daa. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/27680650741
|
db95375 to
e741ce1
Compare
e741ce1 to
c5a8daa
Compare
|
I've been looking at this:
So I'm opening a small PR out of this just for the PluginArea changes. |
Nothing rendered a PluginArea, so every plugin registered with registerPlugin was inert: its sidebars, document panels and menu items had no mount point and never reached their slots. Mount one in both roots, inside the SlotFillProvider the fills need, and surface a plugin that throws as a notice naming it rather than losing the screen. At the root rather than with the editor. A plugin's fills mostly target editor slots, but the component holding them is also where it registers commands and extends a list, and the routes without a canvas need that too. Extracted from #79222, which also carried the preferences modal since landed in #81630, and a REST context change that deserves its own review. Co-Authored-By: Ben Dwyer <ben@scruffian.com> Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
Closing this one as I landed a simpler alternative for now. |
What?
Adds
PluginAreamounting to the v2 boot shell so registered plugin UI can render in both full app and single-page modes, mounts the editor Preferences modal in the v2 lazy editor path, and loads v2 lazy-editor settings/assets with a Site Editor context.Why?
The v2 Site Editor shell already provides
SlotFillProvider, but it did not mountPluginArea, soregisterPlugin()render callbacks had no shell-level mount point outside the editor canvas. The lazy editor path also openededitor/preferencesfrom the editor more menu without rendering the corresponding modal shell.The lazy editor settings/assets requests also used the generic post editor context. That meant plugins enabled for the Site Editor could be missed when they enqueue assets or filter settings based on
core/edit-site, thesite-editorscreen, the oldsite-editor.phpadmin hook, or global$pagenow.How?
This adds a boot-local
PluginAreawrapper with the same error-notice behavior used by the v1 Site Editor, mounts it in both boot roots, declares the@wordpress/pluginsdependency and TypeScript reference, and rendersPreferencesModalfrom the private editor APIs inside the lazy editor.The boot canvas now renders lazy editor with
context="site-editor". For that context, lazy editor requests/wp-block-editor/v1/settingsand/wp-block-editor/v1/assetswithcontext=site-editor, and the REST controller maps that tocore/edit-site, thesite-editorscreen,site-editor.phphook suffix, and$pagenowduring asset collection.Testing Instructions
npm run lint:js -- packages/lazy-editor/src/hooks/use-editor-assets.tsx packages/lazy-editor/src/hooks/use-editor-settings.tsx packages/lazy-editor/src/components/editor/index.tsx packages/boot/src/components/canvas/index.tsx packages/boot/src/components/plugin-area/index.tsx packages/boot/src/components/root/index.tsx packages/boot/src/components/root/single-page.tsx../node_modules/.bin/tsc -p packages/lazy-editor/tsconfig.json --noEmit --pretty false && ./node_modules/.bin/tsc -p packages/boot/tsconfig.json --noEmit --pretty false.php -l lib/experimental/class-wp-rest-block-editor-settings-controller.php.Testing Instructions for Keyboard
When testing a registered plugin UI in the v2 shell, use the keyboard to tab to any plugin-provided controls and confirm they can be focused and operated.
Screenshots or screencast
N/A
Use of AI Tools
This PR was prepared with AI assistance from Codex. The resulting code and checks were reviewed before submission.