-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Editor: Add extensibility to PreviewOptions v2 #64644
Editor: Add extensibility to PreviewOptions v2 #64644
Conversation
👋 Thanks for your first Pull Request and for helping build the future of Gutenberg and WordPress, @lezama! In case you missed it, we'd love to have you join us in our Slack community. If you want to learn more about WordPress development in general, check out the Core Handbook full of helpful information. |
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. |
|
Slightly off topic question here, but would we also be open to allowing extenders to define their own "Preview" modes for inside the editor? Similar to how core is currently working on the new "50%" version it would be super valuable to register custom preview sizes. |
export default compose( | ||
withPluginContext( ( context, ownProps ) => { | ||
return { | ||
as: ownProps.as ?? MenuItem, | ||
icon: ownProps.icon || context.icon, | ||
name: 'core/plugin-preview-dropdown-menu', | ||
}; | ||
} ) | ||
)( ActionItem ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The note mentioned above for clarity:
Hesitant allowing custom icons yet, but not a strong opinion. Mostly thinking that later we want to allow multi-selections with check mark, and it's hard to tell how the icon API then should look like in that scenario.
It's all supported out of the box for the PluginMoreMenuItem
:
Whenever, the sidebar is selected, it's reflected in the menu with the checkmark icon ✔️. Let's not limit the options that are supported out of the box like the icon that get inherited for all fills. That's the part that makes the More Menu item behave as a checkbox:
gutenberg/packages/editor/src/components/plugin-sidebar-more-menu-item/index.js
Lines 56 to 63 in 71e0fae
<ComplementaryAreaMoreMenuItem | |
// Menu item is marked with unstable prop for backward compatibility. | |
// @see https://github.com/WordPress/gutenberg/issues/14457 | |
__unstableExplicitMenuItem | |
scope="core" | |
{ ...props } | |
/> | |
); |
gutenberg/packages/interface/src/components/complementary-area-more-menu-item/index.js
Lines 43 to 44 in 71e0fae
role="menuitemcheckbox" | |
selectedIcon={ check } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Then, if we want to keep the icon from the plugin context, let's use the usePluginContext
hook instead of compose
and withPluginContext
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If usePluginContext
exist, then it would be so much more up to recent React standards 😄
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we allow extending dropdown in all editors, we should figure out how plugin extenders can limit to just one editor, and how their custom code can know about the editor context.
The idea was that there would be the scope
defined by the plugin's author when registering the plugin that would allow limiting where all fills gets injected. See https://github.com/WordPress/gutenberg/blob/trunk/packages/plugins/README.md#pluginarea:
import { PluginArea } from '@wordpress/plugins';
const Layout = () => (
<div>
Content of the page
<PluginArea scope="my-page" />
</div>
);
However, only the default scope is used in all editors, so it doesn't work in practice.
packages/editor/src/components/plugin-preview-dropdown-item/index.js
Outdated
Show resolved
Hide resolved
packages/editor/src/components/plugin-preview-dropdown-item/index.js
Outdated
Show resolved
Hide resolved
export default compose( | ||
withPluginContext( ( context, ownProps ) => { | ||
return { | ||
as: ownProps.as ?? MenuItem, | ||
icon: ownProps.icon || context.icon, | ||
name: 'core/plugin-preview-dropdown-menu', | ||
}; | ||
} ) | ||
)( ActionItem ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The note mentioned above for clarity:
Hesitant allowing custom icons yet, but not a strong opinion. Mostly thinking that later we want to allow multi-selections with check mark, and it's hard to tell how the icon API then should look like in that scenario.
It's all supported out of the box for the PluginMoreMenuItem
:
Whenever, the sidebar is selected, it's reflected in the menu with the checkmark icon ✔️. Let's not limit the options that are supported out of the box like the icon that get inherited for all fills. That's the part that makes the More Menu item behave as a checkbox:
gutenberg/packages/editor/src/components/plugin-sidebar-more-menu-item/index.js
Lines 56 to 63 in 71e0fae
<ComplementaryAreaMoreMenuItem | |
// Menu item is marked with unstable prop for backward compatibility. | |
// @see https://github.com/WordPress/gutenberg/issues/14457 | |
__unstableExplicitMenuItem | |
scope="core" | |
{ ...props } | |
/> | |
); |
gutenberg/packages/interface/src/components/complementary-area-more-menu-item/index.js
Lines 43 to 44 in 71e0fae
role="menuitemcheckbox" | |
selectedIcon={ check } |
Yes, there have been a few attempts in the past. Thank you so much for giving it another go. From my perspective, the only missing pieces are e2e tests (maybe one test with a supporting plugin registration is enough) that cover the extension point. All similar e2e tests live in https://github.com/WordPress/gutenberg/blob/trunk/test/e2e/specs/editor/plugins/plugins-api.spec.js. Looking through the existing names for fills: I would favor renaming |
Co-authored-by: Greg Ziółkowski <[email protected]>
Co-authored-by: Greg Ziółkowski <[email protected]>
Good call @gziolo.
Done :) |
@fabiankaegy for this initial effort, I would maintain the separation of plugins and core actions, similar to the setup in the 'More' menu. |
Sorry a bit late here
I don't think we should limit any feature per "editor". We should not see post/page editor as separate from site editor. These should be seen as the same editor. The extenders shouldn't ask themselves whether they should limit their usage to one editor, instead they should ask themselves whether they should limit their extensions per post type. More on this in the last section of this post https://make.wordpress.org/core/2024/06/18/editor-unified-extensibility-apis-in-6-6/ |
This is looking good to me. I leave the final call for the others. |
Yes, I also found that our approach with any random numbers of slot/fills used within the same registerPlugin call is not optimal in terms of performance and it doesn't provide much information to the framework to orchestrate the rendering and the plugins properly but the ship has sailed here, a change to that right now would be a big project and it's probably not the right time for it. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All feedback addressed. I tested it using the plugin created to e2e tests and it all works great:
There is some misalignment with the "preview in new tab" icon, but it's a preexisting issue. Thank you for taking it to the finish line. We will need to include this change in the dev notes for WordPress 6.7.
Thanks for driving this one through! |
Extend Preview Dropdown with Plugin API
Resolves #25309
What?
This PR introduces a new API to extend the Preview dropdown menu in the post/page editor. It builds upon the work done in #50605, #36119, and #31984, focusing specifically on allowing plugins to add custom menu items to the Preview dropdown.
Key features:
PreviewDropdownMenuItem
component for adding custom items to the Preview dropdownWhy?
This extension point allows for greater flexibility in preview functionality, enabling plugin developers to integrate custom preview options seamlessly into the WordPress editor. It addresses the need for varied publishing flows and tools, such as:
How?
ActionItem
component from@wordpress/interface
Testing Instructions
PreviewDropdownMenuItem
component in your plugin:onClick
handler is called.Testing Instructions for Keyboard
Tab
to navigate to the Preview dropdown button.Enter
orSpace
to open the dropdown menu.Enter
to activate the custom menu item.Screenshots or screencast
No icon:
With icon:
More than one item:
Future Considerations
This PR lays the groundwork for these future enhancements while providing immediate value to plugin developers wanting to extend the preview functionality.