Do not look for block variants, if not supporting block-templates

[spacedmonkey]

What?

Do not look for block variants if theme does not support them. Saving a database query.

Original ticket here.

Why?

How?

Testing Instructions

Screenshots or screencast

[codesandbox]

  Open in CodeSandbox Web Editor | VS Code | VS Code Insiders

[t-hamano]

I don't know the details of how it works, but I am concerned that it may affect the classic theme that supports template parts. In the Classic theme, opt-in the Template Parts Editor as follows:

function add_block_template_part_support() {
    add_theme_support( 'block-template-parts' );
}
add_action( 'after_setup_theme', 'add_block_template_part_support' );

Then, when we try to load other template parts within the template parts editor, the behavior changes.

On trunk

On this branch

[peterwilsoncc]

This looks good to me based on manual testing.

Note:

On my Gutenberg development box, I needed to modify the equivelant path in WordPress, /wp-includes/blocks/template-part.php, to confirm this change.

For whatever reason, the plugin wasn't using its version of the PHP files.

Per @t-hamano's concerns.

[peterwilsoncc]

Having dug in to this following @t-hamano 's comment above, I think it needs to return early with the following:

if (
	! current_theme_supports( 'block-templates' )
	&& ! current_theme_supports( 'block-template-parts' )
) {
	return [];
}

block-templates support implies block-template-parts support but this doesn't appear to be reflected when calling current_theme_supports().

[talldan]

This is a performance issue? The ticket/PR is a bit light on details.

This idea behind this PR seems like an ok patch for a short term improvement in 6.1.1, but doesn't really get to the core of the issue. Other code can still call get_block_templates and reintroduce the problem.

The two questions I have:

• Why does get_block_templates go as far as making a DB query if templates/template parts are not supported? Could the early return be added to that function?
• Why is the template part block registered for themes that don't support template parts? Not registering it would also avoid this code being triggered and avoid a bunch of unnecessary work.

It might be good to look at a different fix for 6.2.

[Mamaduka]

block-templates support implies block-template-parts support

@peterwilsoncc, I don't think that's true. Those are two separate "flags" for classic themes.

[peterwilsoncc]

@Mamaduka This is what I see in TT3, which includes template parts but doesn't indicate block-template-parts support:

$ wp shell
wp> get_stylesheet_uri();
=> string(69) "http://vagrant.local/wp/wp-content/themes/twentytwentythree/style.css"
wp> current_theme_supports( 'block-templates' )
=> bool(true)
wp> current_theme_supports( 'block-template-parts' )
=> bool(false) 

Maybe there is some nuance that I am missing re the purpose the theme support flags serve.

@talldan Yeah, a perf issue to avoid unneeded DB queries. Thanks for tagging appropriately.

I think you're right, there is room to improve further in 6.2 by basically nooping any of the database queries template blocks make.

[Mamaduka]

@peterwilsoncc, the block-template-parts is a new flag that partially enables Site Editor for classic themes. Since block themes already have full access to Site Editor, there was no need to set the theme support for them.

Internally the flag controls what pieces of the UI are hidden/inaccessible.

Here's a dev note for more details: https://make.wordpress.org/core/2022/10/04/block-based-template-parts-in-traditional-themes/.

[spacedmonkey]

Can you pull and tests again @t-hamano

[t-hamano]

I have checked the behavior again and it is working as expected.

I also checked again the support variations in the classic theme, and I believe they are as follows:

Support block-templates only

We can use the template editor in the post editor. The template parts editor menu is not accessible. However, we can call template parts defined in the theme from within the template editor.

Support block-template-parts only

We cannot use the template editor in the post editor. we can access the template parts editor menu, and in the template parts editor we can also call template parts defined in your theme.

Support block-templates and block-template-parts

We can use the template editor in the post editor. We can access the template parts editor menu, and in the template parts editor, we can also call template parts defined in the theme.

Therefore, I think it would be appropriate not to query only for template parts unless both block-templates and block-template-parts are supported.

[spacedmonkey]

I guess the question is, do we even need to register this block on themes that do not support them anyway. Seems like it would never be used.

[spacedmonkey]

I would love some context here from @talldan.

[Mamaduka]

The changes here look good to me. Thank you, @spacedmonkey!

I agree with @talldan that we should explore a more general solution for WP 6.2.

Even for the block themes, variations are only needed by the editors. There's no use in querying them when a user visits a page.

One option we can explore for the next major release is the lazy initialization of block variables.

[spacedmonkey]

One option we can explore for the next major release is the lazy initialization of block variables.

Created a ticket #45601.

[sybrew]

Could the concerns of #45362 (comment) above also be addressed, please?

I think no database queries for theme support, and especially not anything via WP Query, should be performed before a template can be determined (template_redirect).