-
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
Plugin sorting via priority property in registerPlugin #16384
base: trunk
Are you sure you want to change the base?
Conversation
This was broken out based on comments from @youknowriad on #13361 |
@youknowriad have you had a chance to think on this any further? Happy to make any changes as needed. |
31be67b
to
247a1a2
Compare
Adding in what @youknowriad mentioned during the core editor meeting on the 11th September: |
Based on comments in the last #core-editor meeting, I feel I need to better explain this PR. I have created a new issue #18064 to track the intent. @mcsf commented:
The items that would be affected by this change are very much visually based. They appear in a certain locations of the admin - ie. Menu Items and sidebar panels
I want to make it clear, that this PR does not affect how a SlotFill is rendered and it doesn't interact with the SlotFill system in any way. It simply controls the order in which plugins( that contain SlotFIlls ) are rendered inside the |
@ryanwelcher Hallo!! I just took a peak at this PR. I think the Note: I don't have context from the previous JS meetings. Coming into this, I was curious how this would play out once more and more custom blocks are registered. I think when you have your own blocks, you have (basically) maximum control on ordering. But when you have a collection of blocks from other people, you have far less control. When something like I'm not sure how they're sorted by now... The only sort order I can think of that makes sense (given the above scenario) would be alphabetical. That said, I'm not against this idea! Just wanted to share my thoughts :) From the WordPress PHP side, there's https://wordpress.stackexchange.com/questions/272067/how-to-enqueue-scripts-in-order-of-head-section |
Hi, @ItsJonQ! Thanks for taking the time to review the PR. All input is greatly appreciated here 😄 . I just wanted to address some of your comments/concerns.
Unfortunately, this is going to be inherent with this approach. Authors can abuse this option but they can do similar things now in the Hooks API which also uses the concept of priority to control the order in which hook callbacks are run.
There is no sorting now at all. It is based on the order in which the code is loaded. This PR is meant to provide some control here.
To your point above, authors can simply register a plugin called
I understand your point here but that link above has more to do with how order is used when it comes to dependencies. The PR isn't meant to address that. If there are plugins that rely on each other, that should be addressed in a different way. |
packages/edit-post/src/components/sidebar/plugin-sidebar/index.js
Outdated
Show resolved
Hide resolved
@@ -58,16 +59,22 @@ class PluginArea extends Component { | |||
} | |||
|
|||
getCurrentPluginsState() { | |||
return { | |||
plugins: map( getPlugins(), ( { icon, name, render } ) => { | |||
const plugins = compose( |
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.
It would be great to have a test which validates whether components are rendered in the order enforced by priorities.
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.
Sounds great! I'll get those in place ASAP.
Related #19485 |
Not that I am aware of. |
…orts the registered plugins by priority before rendering them in PluginArea
…orts the registered plugins by priority before rendering them in PluginArea
…orts the registered plugins by priority before rendering them in PluginArea
…orts the registered plugins by priority before rendering them in PluginArea
56c536b
to
e590e69
Compare
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 Unlinked AccountsThe following contributors have not linked their GitHub and WordPress.org accounts: @[email protected], @nicolad, @ItsJonQ, @etoledom, @michaelmcandrew. Contributors, please read how to link your accounts to ensure your work is properly credited in WordPress releases. 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. |
Description
As is stands now, there is no way to control the order of the items being rendered in Slots. This PR adds a new
priority
property to the settings object that is passed toregisterPlugin
. This property is optional and has a default value of 10. I chose 10 as that is the default priority for Hooks and familiar to most WordPress developers and so that we can move items ahead of the default position without using negative numbers.The approach adds the
priority
property when the plugin is being registered and then usessortBy
to sort the plugins before they are rendered inside the<PluginArea />
component.How has this been tested?
This has been tested locally and using the unit and e2e tests.
Types of changes
New feature (non-breaking change which adds functionality)
Checklist: