Allow blocks with interactivity support inside core/query (useUnsupportedBlocks)

[poof86]

What problem does this address?

I want to create blocks that I can use in the core/query block, but because my custom blocks don't start with the prefix "core/" they are flagged as unsupported while support for interactivity is set to true or support for interactivity.clientNavigation is set to true.

Edit: The server side part is already using the supports instead of core/-- string, so it differs from the edit part when checking the Interactivity supports.

What is your proposed solution?

Allow for prefixes other then "core/" and check if the block has support for interactivity instead.

[cbravobernal]

Hi there!

When you mention the unsupported flag, you mean the client side navigation that is handled here?

gutenberg/packages/block-library/src/query/index.php

Line 124 in 72b9ffa

/**

[poof86]

Hey,

I’m referring to this hook that is called in the editor that doesn’t allow non core blocks to be present for interactivity to be enabled

gutenberg/packages/block-library/src/query/utils.js

Line 369 in f3c0586

export const useUnsupportedBlocks = ( clientId ) => {

[colinduwe]

I'll take a quick stab at this one. One quick question is what is the history of this check? Why was it implemented in its current form @gziolo do you know that bit of history or perhaps know who to ask? Are we overlooking a some pitfall?

[colinduwe]

@poof86 PR submitted. Please give it a whirl.

[gziolo]

I’m referring to this hook that is called in the editor that doesn’t allow non core blocks to be present for interactivity to be enabled

It looks like the logic on the server and on the client differ when making the decision whether the page can be loaded without the full reload.

I'll take a quick stab at this one. One quick question is what is the history of this check? Why was it implemented in its current form @gziolo do you know that bit of history or perhaps know who to ask? Are we overlooking a some pitfall?

@DAreRodz and @c4rl0sbr4v0, should be able to help resolve this issue.

[colinduwe]

It looks like the logic on the server and on the client differ when making the decision whether the page can be loaded without the full reload.

The php logic makes sense; it checks if interactivity or interactivity.clientNavigation are set true. If so, the page can be loaded without refresh.
I've updated the PR so it makes the same check. It also allows any 'core/' block to be in the query loop, although I think they all already have their block.supports attributes set.

[sethrubenstein]

Yes please, I've tried numerous ways to hijack the force disabling of enhanced pagination with no luck... even though my interactive blocks work perfectly fine in the query block.

[cbravobernal]

It looks like the logic on the server and on the client differ when making the decision whether the page can be loaded without the full reload.

And because of that, I think this issue is a bug instead of an enhancement 😅

[colorful-tones]

I sense that although this is noted as a bug it may not be critical enough to include in 6.5.1 (timeline to be determined), but would be nice to have, correct? I just wanted to evaluate and clarify the impact.

@c4rl0sbr4v0 perhaps you have an impending pull request for review?

[cbravobernal]

The PR is almost ready (I would like the contributor to remove just one "bool" word, I can do it my self, but is not critical).

• Update the query block to permit non-core interactive blocks #60006

It's not critical, but is a really nice to have. Cause right now, nobody can have a Core Query block with "force reload" disabled and an Interactive block or a client side navigation compatible block inside that Query block.

You would need a block variation, and that is adding too much hustle just for that. The server side is already allowing that, but we forgot to update that logic in the edit part.

[gziolo]

The fix was released in WordPress 6.5.2.

[kelvin-xu]

Can anyone get the same fix to the most recent version of the Gutenberg plugin as well?

[kelvin-xu]

I'm running version 18.1.2 of the Gutenberg plugin. And the same issue happens. I have checked the code within the plugin and it is still looking for 'core/' blocks only.

[colinduwe]

This fix is in 18.2 which is scheduled for release tomorrow, 4/24

[kelvin-xu]

@colinduwe Thank you so much.