Editor: Move Interactivity directives processing to WP_Block class

[gziolo]

Trac ticket: https://core.trac.wordpress.org/ticket/61185#ticket

Testing performance with TT4 and homepage:

Before (trunk): wp-total (median) 55.59 ms After (branch): wp-total (median) 55.18 ms

---

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[bot]]

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 props-bot label.

Core Committers: Use this line as a base for the props when committing in SVN:

Props gziolo, cbravobernal.

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[github-actions[bot]]

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.

[cbravobernal]

Added a filter to be able to enable/disable server directives processing and an unit test for it.

[gziolo]

I documented the new filter. I renamed it to interactivity_process_directives as wp_ prefix doesn't add too much value here. It's used sometimes with functions to ensure more general names don't conflict.

I also opened https://github.com/WordPress/gutenberg/pull/62095 to have the fix in place to Gutenberg at the time of the commit so E2E tests continue to pass.

[gziolo]

Committed with https://core.trac.wordpress.org/changeset/58234.

[luisherranz]

I documented the new filter. I renamed it to interactivity_process_directives as wp_ prefix doesn't add too much value here. It's used sometimes with functions to ensure more general names don't conflict.

Since this filter is used to control whether the blocks are processed or not, wouldn't it be better to include the word "blocks" in the name of the filter? Otherwise, people can think it is related to the wp_interactivity_process_directives( $html ) function, that works for arbitrary HTML.

Like interactivity_process_directives_in_blocks or something similar...

[gziolo]

It also could be moved to the body of wp_interactivity_process_directives to cover all use cases with a single filter. This way we also won't need to change anything in the Gutenberg plugin.

[luisherranz]

What is the main use of this filter? Is it so that plugins can disable the Server Directive Processing for some reason, or is it so that Gutenberg can replace it with a more updated version?

[cbravobernal]

We have e2e tests that disable the Server Directive Processing. That's the only one that come to my mind right now. Gutenberg crashed and we had to choose between 2 options:

• Remove those tests, or update them to take into account SSR.
• Add a filter to allow developers to choose.

[luisherranz]

Ok, thanks Carlos 🙂

I don't have a strong opinion on whether we should rename the filter or also include the processing of the wp_interactivity_process_directives function, but I would do one of those.

[cbravobernal]

Ok, thanks Carlos 🙂

I don't have a strong opinion on whether we should rename the filter or also include the processing of the wp_interactivity_process_directives function, but I would do one of those.

I think disabling all SSR would make more sense than only in blocks, right?