Lazy initialization of block variants.

[spacedmonkey]

What problem does this address?

Follow issue related to #45362 (review)

The template part block, loads block variants what load WP_Query and result in database queries. This means that when a block is registered ( on every page request ), that an mostly unnecessary database query is run. There needs to be a way to load lazily the block variants, only when needed.

Props @talldan @Mamaduka

What is your proposed solution?

[sybrew]

Blocks, or any derivative thereof (such as templates), shouldn't be part of the Post Type API, for they aren't Post Types.

In that, I think wp_template's foundation should be rewritten without considering Post Types but instead something bespoke --- perhaps having a new database table if deemed necessary. This is how you can get rid of the WP_Query request permanently.

I'm confident the Post Type API eased the integration for storing and filtering, but it should be a short-term strategy. Keeping the system as-is will cause it to be maintained into an indomitable blob of code debt.

[spacedmonkey]

@talldan @Mamaduka @gziolo @sybrew Can you provide some context of when varients are needed for the template part block. At the moment, variants are loaded on EVERY page request. Is there anyway to only load them in the site editor? Is there any other places where these variants are needed.

[Mamaduka]

@spacedmonkey, what's your plan for making the block variations lazily loadable? Changing type for $WP_Block_Type::$variations from array[] to array[]|callable and lazily initializing callables when needed?

A good start would be get_block_editor_server_block_settings and WP_REST_Block_Types_Controller. We could also modify WP_Block_Type::__get and handle lazy loading there; this probably would be the most backward-compatible way.

[talldan]

Can you provide some context of when varients are needed for the template part block.

Sorry for the slow reply. They're only needed where template parts can be edited, currently I believe that's only in the site editor.

[spacedmonkey]

If you are right @talldan could we just register the variants when a user is logged in.

gutenberg/packages/block-library/src/template-part/index.php

Lines 261 to 273 in 0ff9e08

	/**
	* Registers the `core/template-part` block on the server.
	*/
	function register_block_core_template_part() {
	register_block_type_from_metadata(
	__DIR__ . '/template-part',
	array(
	'render_callback' => 'render_block_core_template_part',
	'variations' => build_template_part_block_variations(),
	)
	);
	}
	add_action( 'init', 'register_block_core_template_part' );

function register_block_core_template_part() {
        $args = array(
            'render_callback' => 'render_block_core_template_part',
        );
        if ( current_user_can( 'edit_theme_options' ) ) {
               $args['variations'] = build_template_part_block_variations(),
        }
	register_block_type_from_metadata( __DIR__ . '/template-part', $args );
}

This seems like a simple change.

[Mamaduka]

My preference would be the general solution via the Blocks API, instead of handling this per-block basis.

It would be easier to document, and we can always recommend lazy initialization for variables that are generated from DB.

cc @gziolo

[spacedmonkey]

Using the blocks api sounds related to #22812

[Mamaduka]

While it's definitely a related issue, I don't think it should be a requirement for the enhancement.

[spacedmonkey]

I don't know how site editor ues these variants, so it is hard to make a recommendation. If you need to load this data via the REST API, I can help with that, but someone with javascript knowledge will need to help with making this change.

The long this is left, the more of a B/C break this will be, so I want to get this fixed ASAP.

[Mamaduka]

There shouldn't be any JS involved in this enhancement.

The blocks are bootstrapped via get_block_editor_server_block_settings() on editor pages or loaded via API (WP_REST_Block_Types_Controller). Both places need to handle lazy block variation init. See my previous comment #45601 (comment).

The main problem we might face here is that we'll need to land changes in the core before the Gutenberg plugin can use it.

[spacedmonkey]

@Mamaduka This change is going to be hard to do in gutenberg. Should I work on it in core then?

[Mamaduka]

Correct, we can't change those files in the plugin. The core PR sounds good to me. We can conditionally provide variations values for blocks and use lazy loading.

[spacedmonkey]

I put together a little POC PR - WordPress/wordpress-develop#4857.

It is a same breaking change. We need to investigation more.

[Mamaduka]

This was resolved via WordPress/wordpress-develop#5718.