Only run block bindings Gutenberg logic for sites using WordPress versions below 6.5

[SantosGuillamot]

What?

Ensure the Gutenberg block bindings logic only runs on sites using a WordPress version below 6.5.

Why?

At this moment, if users have WordPress 6.5 or above, and the Gutenberg plugin installed, block bindings are processed twice. Once by core and once by Gutenberg. This seems unnecessary because the Gutenberg logic was only added for compatibility with older WordPress versions.

How?

Checking that the class WP_Block_Bindings_Registry doesn't exist before running the block bindings compact logic in Gutenberg.

Aspects to consider

Some aspects to consider with this approach:

• This would limit ourselves to make changes to this logic in Gutenberg first. On the other hand, I believe it should be fine to work directly in core for this. Additionally, we can always use the render_block filter again in the future if we want.
• Is there a better way to check if the bindings are being processed? I tried checking the methods, but they are private so I believe it is not possible.
• Is it okay to hide the existing Gutenberg functions? With this change, WordPress sites above 6.5 can't use gutenberg_block_bindings_replace_html and gutenberg_process_block_bindings. However, they were meant to be internal, so I assume that shouldn't be a problem, right?

Opinions?

Testing instructions

Before
After creating a binding, check that both WP_Block->replace_html (link) and gutenberg_block_bindings_replace_html run.

After
After creating a binding, check that only WP_Block->replace_html (link) runs.

[github-actions]

Warning: Type of PR label mismatch

To merge this PR, it requires exactly 1 label indicating the type of PR. Other labels are optional and not being checked here.

• Type-related labels to choose from: [Type] Automated Testing, [Type] Breaking Change, [Type] Bug, [Type] Build Tooling, [Type] Code Quality, [Type] Copy, [Type] Developer Documentation, [Type] Enhancement, [Type] Experimental, [Type] Feature, [Type] New API, [Type] Task, [Type] Technical Prototype, [Type] Performance, [Type] Project Management, [Type] Regression, [Type] Security, [Type] WP Core Ticket, Backport from WordPress Core.
• Labels found: [Type] Enhancement, [Type] Performance, [Feature] Block bindings.

Read more about Type labels in Gutenberg. Don't worry if you don't have the required permissions to add labels; the PR reviewer should be able to help with the task.

[github-actions]

Warning: Type of PR label mismatch

To merge this PR, it requires exactly 1 label indicating the type of PR. Other labels are optional and not being checked here.

• Type-related labels to choose from: [Type] Automated Testing, [Type] Breaking Change, [Type] Bug, [Type] Build Tooling, [Type] Code Quality, [Type] Copy, [Type] Developer Documentation, [Type] Enhancement, [Type] Experimental, [Type] Feature, [Type] New API, [Type] Task, [Type] Technical Prototype, [Type] Performance, [Type] Project Management, [Type] Regression, [Type] Security, [Type] WP Core Ticket, Backport from WordPress Core.
• Labels found: [Type] Enhancement, [Type] Performance, [Feature] Block bindings.

Read more about Type labels in Gutenberg. Don't worry if you don't have the required permissions to add labels; the PR reviewer should be able to help with the task.

[github-actions]

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.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: SantosGuillamot <santosguillamot@git.wordpress.org>
Co-authored-by: gziolo <gziolo@git.wordpress.org>
Co-authored-by: cbravobernal <cbravobernal@git.wordpress.org>

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

[github-actions]

This pull request has changed or added PHP files. Please confirm whether these changes need to be synced to WordPress Core, and therefore featured in the next release of WordPress.

If so, it is recommended to create a new Trac ticket and submit a pull request to the WordPress Core Github repository soon after this pull request is merged.

If you're unsure, you can always ask for help in the #core-editor channel in WordPress Slack.

Thank you! ❤️

View changed files

❔ lib/compat/wordpress-6.5/blocks.php

[cbravobernal]

This would limit ourselves to make changes to this logic in Gutenberg first. On the other hand, I believe it should be fine to work directly in core for this.

Be careful with this, working directly in Core is not the fastest approach, and could be committed/tested in production environments only a few days before the next Beta. If render_block filter allows to add new iterations in the future, then is ok, that way performance checks with Gutenberg will be more accurate.

Is there a better way to check if the bindings are being processed?

IMHO checking that the class exists is really a common approach.

Is it okay to hide the existing Gutenberg functions?

Gutenberg is a plugin for feature development and experiments, but if we can, we should add a deprecation notice before not allowing to use them.

[gziolo]

This is what I see in the mode with whitespace changes excluded:

I think it makes perfect sense. If we need to change the processing, we can always move this handling to a different compat folder related to a future WP major version and apply all necessary changes.

Is it okay to hide the existing Gutenberg functions?

Gutenberg is a plugin for feature development and experiments, but if we can, we should add a deprecation notice before not allowing to use them.

Internal Gutenberg functions prefixed with gutenberg_ were never documented and considered public API. Sometimes, we offer earlier access to public API, but then we use the final name to avoid the need for extenders to change their implementations.

[SantosGuillamot]

Be careful with this, working directly in Core is not the fastest approach, and could be committed/tested in production environments only a few days before the next Beta. If render_block filter allows to add new iterations in the future, then is ok, that way performance checks with Gutenberg will be more accurate.

I agree with this part. However, as mentioned above, I believe we can always add the render_block filter in another compat folder if needed.

[SantosGuillamot]

I can see that the "Verify Core Backport" workflow is failing: link.

However, I would say we don't need a backport for that. Any idea how to proceed here?

[gziolo]

However, I would say we don't need a backport for that. Any idea how to proceed here?

I handled it 😄

[cbravobernal]

However, I would say we don't need a backport for that. Any idea how to proceed here?

I handled it 😄

YOLO 😆