-
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: Introduce editor.init
action hook for extensibility
#65921
base: trunk
Are you sure you want to change the base?
Conversation
Size Change: +13 B (0%) Total Size: 1.77 MB
ℹ️ View Unchanged
|
This would be very useful! ❤️ |
I like where this is going. That said, I do wonder what's best: Do we want a generic I guess the question comes down to: do we see all the "editor extensibility" APIs as something that live only the editor or do we see ourselves for instance registering blocks elsewhere and in which case dedicated actions is better. Maybe an audit of all the things that we "register" is needed. The other question I have is: Should we use an asynchronous action (introduced recently by @jsnajdr ) or a synchronous one. |
In my view this should be a synchronous action. We don't want to encourage people to delay the editor initialization by fetching something over network or doing other async work. If you need this, it's a signal that it belongs somewhere else. The |
What?
Triggered by the conversation started by @colorful-tones in #65713 (comment)
Raised also previously by me in #64138 (comment):
Why?
It isn't different from past issues that people had with unregistering block types like #9757 or #9757. Same 3rd party blocks get registered with
wp.blocks.registerBlockType
before other plugins register their filters that modify blocks during block registration. That was mitigated with #34299 that reapplies the most recent filters to previously registered blocks.However, there are more examples where we could offer better alternatives other than using
wp.domReady
to defer executing the code or programmatically move the place where the custom script is printed by making it dependent, for example, on thewp-edit-post
script handle. The root issue is that there isn't a formal way to let 3rd party code run code in a predictable order. On the server, there are WP actions likeinit
oradmin_init
that offer a chance to run the code after or before core, plugin and themes run their logic.How?
Testing Instructions
Testing Instructions for Keyboard
Screenshots or screencast