Block Editor: Enqueue script modules via enqueue_block_assets action

[sirreal]

Trac ticket: https://core.trac.wordpress.org/ticket/64360

​The enqueue_block_assets action is used to add scripts and styles in the block editor's iframe.

It should be possible to add script modules to the block editor's iframe as well.

See:

_wp_get_iframed_editor_assets and ​its documentation.
The WP_Script_Modules class.
The block editor Iframe component in Gutenberg.
This will likely require a new method or exposing more of the script modules internal data so that a specific WP_Script_Modules instance can be used for the iframed assets. See #60597.

Requires Gutenberg changes to the block editor. See WordPress/gutenberg#73765.

---

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.

[github-actions]

Test using WordPress Playground

The 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

• The Plugin and Theme Directories cannot be accessed within Playground.
• All changes will be lost when closing a tab with a Playground instance.
• All changes will be lost when refreshing the page.
• A fresh instance is created each time the link below is clicked.
• Every time this pull request is updated, a new ZIP file containing all changes is created. If changes are not reflected in the Playground instance,
  it's possible that the most recent build failed, or has not completed. Check the list of workflow runs to be sure.

For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation.

Test this pull request with WordPress Playground.

[sirreal]

Script modules print the script tags, but also print HTML for the @wordpress/a11y module if it's enqueued. That probably needs to be injected into the editor as well?

wordpress-develop/src/wp-includes/class-wp-script-modules.php

Lines 937 to 951 in 63b3a8f

	/**
	* @access private This is only intended to be called by the registered actions.
	*
	* @since 6.7.0
	*/
	public function print_a11y_script_module_html() {
	if ( ! $this->a11y_available ) {
	return;
	}
	echo '<div style="position:absolute;margin:-1px;padding:0;height:1px;width:1px;overflow:hidden;clip-path:inset(50%);border:0;word-wrap:normal !important;">'
	. '<p id="a11y-speak-intro-text" class="a11y-speak-intro-text" hidden>' . esc_html__( 'Notifications' ) . '</p>'
	. '<div id="a11y-speak-assertive" class="a11y-speak-region" aria-live="assertive" aria-relevant="additions text" aria-atomic="true"></div>'
	. '<div id="a11y-speak-polite" class="a11y-speak-region" aria-live="polite" aria-relevant="additions text" aria-atomic="true"></div>'
	. '</div>';
	}

[westonruter]

Since print_a11y_script_module_html runs at wp_footer, yes, it seems this will need to be captured separately above with more output buffering.

The very selective nature of picking and choosing what gets captured to be injected into the editor iframe, however, gives me pause about how well the editor will replicate the frontend in which themes and plugins could be adding other arbitrary markup to wp_head and wp_footer.

[sirreal]

Good point. A specific action for the editor iframe analogous to wp_head to capture arbitrary HTML for inclusion may be best here. Then this would just run the action instead if calling select methods.