Add Interactivity API hooks to wp_admin #6453
Conversation
Test using WordPress PlaygroundThe changes in this pull request can previewed and tested using a WordPress Playground instance. WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser. Some things to be aware of
For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation. |
|
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 Core Committers: Use this line as a base for the props when committing in SVN: To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
sirreal
changed the title
| @@ -208,6 +208,9 @@ public function register_script_modules() { | |||
| public function add_hooks() { | |||
| add_action( 'wp_enqueue_scripts', array( $this, 'register_script_modules' ) ); | |||
| add_action( 'wp_footer', array( $this, 'print_client_interactivity_data' ) ); | |||
|
|
|||
| add_action( 'admin_enqueue_scripts', array( $this, 'register_script_modules' ) ); | |||
There was a problem hiding this comment.
The question is which hook fits better here as there are two possibilities in contrast to the front end:
admin_footer- Prints scripts or data before the default footer scripts.admin_print_footer_scripts- Prints any scripts and data queued for the footer.
There was a problem hiding this comment.
It's the configs and initial state for stores so it probably needs to be printer earlier 👍🏻
There was a problem hiding this comment.
Oh, good question! I think I'd print this as late as possible. @wordpress/interactivity is what will use this when it initializes, and because that's a module the DOM should have finished parsing before it runs.
I think we can switch this to admin_print_footer_scripts to print it as late as possible.
There was a problem hiding this comment.
I was exploring that part of the codebase for the first time today. I still don't know what should be the order of printing when taking into account also 3rd party plugins that depend on Interactivity API. My initial thinking was that 3rd party plugins would use admin_enqueue_scripts to register/enqueue their scripts. I'm not sure how folks would use wp_interactivity_store.
There was a problem hiding this comment.
I've pushed that change, I can see the script moved after the footer scripts and it continues to work as expected.
There was a problem hiding this comment.
It's @wordpress/interactivity itself that reads data from the printed store data. And because these are modules (which implies defer) there shouldn't be any problem pushing the printed script tag to be later. The module that depends on it will not execute until the DOM has been parsed completely, so the script tag it looks for will be there.
|
Committed with https://core.trac.wordpress.org/changeset/58127. |
This requires #6452 - Interactivity uses Script Modules so those hooks must also be added.
Trac ticket: https://core.trac.wordpress.org/ticket/61087
To test this, apply #6452 as well. Then enqueue any Script Module using
@wordpress/interactivityin WP Admin and it should work as expected. I have a plugin using this behavior that adds an admin menu page rendered with Interactivity that can be used as an example, although that plugin is not good for testing because it adds the necessary actions itself.This Pull Request is for code review only. Please keep all other discussion in the Trac ticket. Do not merge this Pull Request. See GitHub Pull Requests for Code Review in the Core Handbook for more details.