Add query loop block variation namespace to query_loop_block_query_vars filter

[creative-andrew]

Problem Statement

When extending the query loop block by registering a variation, it's imperative to ensure that the custom query works seamlessly on the front-end. The recommended approach involves adjusting the query using the query_loop_block_query_vars filter, ensuring it doesn't interfere with other queries.

However, implementing this solution can lead to unintended consequences, as subsequent queries might be affected due to the application of the filter.

For example, the following snippet will cause a problem as the filter will be applied for subsequent queries.

add_filter( 'pre_render_block', __NAMESPACE__ . '\pre_render_block', 10, 2 );
function pre_render_block( $pre_render, $parsed_block ) {
	if ( isset( $parsed_block['attrs']['namespace'] )
	&& YOUR_NAMESPACE === $parsed_block['attrs']['namespace'] ) {
		add_filter('query_loop_block_query_vars',
			function ( $default_query, $block ) {
		          ...
		          return $default_query;
			},
			10,
			2
		);
	}
	return $pre_render;
}

Current Limitations

The current recommended method involves checking the namespace of the registered query loop variation within the pre_render_block filter. However, this approach poses challenges, particularly when attempting to perform specific checks based on the namespace or other conditions. The issue arises because the $block instance passed as the second parameter to the query_loop_block_query_vars filter refers to the Post Template block rather than the registered variation block. Consequently, retrieving references to the variation or its namespace becomes problematic, hindering effective condition checking.

Right now it's not possible to do checks like:

add_filter( 'query_loop_block_query_vars',  __NAMESPACE__ . '\filter_my_query', 10, 2 );
function filter_my_query( $query, $block ) {
	if ( isset( $block->parsed_block['attrs']['namespace'] ) 
&& YOUR_NAMESPACE === $block->parsed_block['attrs']['namespace'] ) {
            ...
	}
	return $query;
}

as proposed here https://wordpress.org/support/topic/you-should-replace-your-query/

To mitigate the potential impact on other queries and improve condition checking, it is possible to use the queryId parameter. By leveraging the queryId, we can ensure that modifications to the query are applied only to the intended query loop block, thus preventing unintended consequences for subsequent queries.

The best way I have found some far to prevent other queries from being affected is to use the queryId:

function pre_render_block( $pre_render, $parsed_block ) {
	if ( isset( $parsed_block['attrs']['namespace'] )
	&& YOUR_NAMESPACE === $parsed_block['attrs']['namespace'] ) {
		add_filter(
			'query_loop_block_query_vars',
			function ( $default_query, $block ) use ( $parsed_block ) {
				if (isset( $block->context['queryId'] )
				&& $block->context['queryId'] === $parsed_block['attrs']['queryId'] ) {
				 ...
				}
				return $default_query;
			},
			10,
			2
		);

	}
	return $pre_render;
}

Feature request

While the proposed solution addresses the immediate issue and enhances query customization, there remains scope for further improvements. Ideally, the query_loop_block_query_vars filter could be enhanced to include additional context, such as the query loop block it pertains to, facilitating more comprehensive condition checking and enabling finer control over query adjustments. Such enhancements would contribute to a more streamlined and intuitive development experience, ensuring the continued effectiveness of query loop block extensions.