Possibility to disable "Detect inner plugin blocks" in query block enhanced pagination

[them-es]

What problem does this address?

First of all, the Interactivity API (in particular the enhanced pagination feature) is awesome and will definitely initiate a new era in WordPress development.

Unfortunately https://github.com/WordPress/gutenberg/pull/55714 disables the enhanced pagination in query blocks when a custom block is detected on render - even if the custom blocks declare compatibility with the Interactivity API via block.json - and there seems to be no way to overrule this behavior.

What is your proposed solution?

The limitation seems to be required for WP 6.4 to prevent possible quirks with non-core blocks on production sites.

However, for developers who would like to test the new query pagination and need to include custom blocks in the queries, it would be useful if the custom block detection could be disabled (e.g. via Gutenberg > Experiments > Enable enhanced pagination even if custom blocks are detected) for the time being until a suitable solution for Core has been introduced.

[luisherranz]

I agree that it would be useful for experimentation, but it doesn't sound as a Gutenberg experiment to me because it doesn't contain new functionality that people should test.

Why don't you simply remove the filter instead?

remove_filter( 'render_block_data', 'block_core_query_disable_enhanced_pagination' );

[gziolo]

The same filter is part of WordPress 6.4 so it's part of the public API now.

https://github.com/WordPress/wordpress-develop/blob/d66ef46847e2340c613d0a01c36d4fcc4b5f3a6b/src/wp-includes/blocks/query.php#L214

To remove it with the Gutenberg plugin installed and active you would need to also remove it with:

remove_filter( 'render_block_data', 'gutenberg_block_core_query_disable_enhanced_pagination' );

It probably gets executed twice in that case.

[luisherranz]

It probably gets executed twice in that case.

Is that expected or something we need to fix on a per-filter basis?

[gziolo]

@luisherranz, It really depends on how you look at it. My perspective is as follows: there should be only an init filter in use for core blocks as that one is responsible for bootstrapping all necessary dependencies and to register the core block. This way, when the Gutenberg plugin runs, it simply unregists the block. When you start adding additional filters to the files that are copied to WordPress core, you need to have a way for them to co-exist, and that's why all function names need to have different signatures so they don't throw fatal errors in PHP due to function re-declaration. The side effect is that the same functionality gets registered twice and then executed twice. If you want to prevent that, then you need to seek alternative approaches which are difficult to reason about.

[luisherranz]

That makes sense. Do you know about a core block that is already using that pattern to avoid running filters twice? I can't seem to find any.

[gziolo]

That makes sense. Do you know about a core block that is already using that pattern to avoid running filters twice? I can't seem to find any.

I don't think that is the case. In many places, the filters are added and immediately removed after executing some code. However, for the filters that get added outside of other functions, in most cases they just work fine because the operations applied take exactly the same effect. In most cases, the solution would be to change the WordPress core instead to perform the same operations.

[luisherranz]

In most cases, the solution would be to change the WordPress core instead to perform the same operations.

Can you explain this in a bit more detail? I feel like I do not fully understand the issue here and why block_core_query_disable_enhanced_pagination is different than the filters of the rest of the core blocks.

[them-es]

@luisherranz and @gziolo

Removing the two filters (1. Core and 2. Gutenberg) in an 'init' action worked fine. Thanks for the hint and keep up the good work. 👍

remove_filter( 'render_block_data', 'block_core_query_disable_enhanced_pagination' );
remove_filter( 'render_block_data', 'gutenberg_block_core_query_disable_enhanced_pagination' );

[luisherranz]

@them-es, that's great 🙂

But please keep in mind that disabling the filters is not something that is officially supported, and that functionality is likely to change in WP 6.5, so you'd need to keep an eye on that.

I'm going to close this issue as resolved but feel free to reopen if something related arises.

[gziolo]

In most cases, the solution would be to change the WordPress core instead to perform the same operations.

Can you explain this in a bit more detail? I feel like I do not fully understand the issue here and why block_core_query_disable_enhanced_pagination is different than the filters of the rest of the core blocks.

It's the same in all instances. It's possible but, at the same time, tricky to remove these filters from WordPress core with the Gutenberg plugin activated. That's why we should avoid is possible using this type of core blocks related filters in the PHP files in the @wordpress/block-library package.