query-loop block: Run the main query when queryId is not set (#25377)

[bobbingwide]

Description

• Theme developers need an easy way to get a template to run the main query
• They don't want to have to create a tempate for each category, tag, date, author, etc.
• This solution kicks in when the core/query-post block is not an inner post of core/query.
• In this situation $block->context['queryId'] is not set.
• When it's set we run the query defined by the outer block
• When it's not we run the main query.

The function to run the main query is basically the same loop as previously developed but using standard loop functions have_posts(), the_post() and get_post() to process the main query and WP_block->render() to render each posts content.

This solution supports standard pagination.

How has this been tested?

• I first developed the solution for my experimental theme Fizzie, documenting the tests in wp:query-loop doesn't dynamically use the chosen category bobbingwide/fizzie#11
• I tested it with categories, tags, custom taxonomies and dates.
• Later I used the same solution for my custom post type archives.
• For this PR I used the Twenty Twenty-One Blocks theme with the following in index.html

<!-- wp:template-part {"slug":"header","theme":"twentytwentyone-blocks","align":"full", "tagName":"header","className":"site-header"} /-->

<!-- wp:query-loop -->
<!-- wp:post-title /-->
<!-- wp:post-excerpt {"showMoreOnNewLine": "false" } /-->
<!-- wp:post-tags /-->
<!-- wp:post-hierarchical-terms {"term":"category"} /-->
<!-- wp:post-date /-->

<!-- /wp:query-loop -->

<!-- wp:template-part {"slug":"footer","theme":"twentytwentyone-blocks","align":"full","tagName":"footer","className":"site-footer"} /-->

I created block posts with different categories, tags and dates:

title	tags	categories	date
Archives		Uncategorised	2020/11/09
Issue #26010	#26010	issues	2020/11/09
Test #25377	#25377	issues, Uncategorised	2020/11/06
Issue #26731	#26731	issues	2020/10/31
Hello world!		Uncategorised	2020/11/06

and clicked in the links available to display categories or tags or months.

Screenshots

Types of changes

Fixes #25377

I imagine that some developer and user documentation will be required to enable other developers and users
to understand how to construct templates.
The core/query block will be needed when something other than the main query is to be run.

Checklist:

• My code is tested.

• My code follows the WordPress code style.

• My code follows the accessibility standards.

• My code has proper inline documentation.

• I've included developer documentation if appropriate.

• I've updated all React Native files affected by any refactorings/renamings in this PR.

• I've not PHPunit tested the code. I don't have a wp-env environment

• I expect there will be coding standard violations. I can't run lint and I don't trust my PhpStorm's Coding standards configuration one inch.

• The same solution ( testing queryId ) can be used to improve the 'core/query-pagination' block.

[ntsekouras]

Het @bobbingwide - thanks for exploring this!

I think that a solution like this: #25377 (comment), proposed by @aristath, with query merging etc.. seems to be enough for server-side, as it will still work with get_posts without a similar render method.

The main problem that needs solving regarding the context, includes showing the proper results in the client side as well. I've started exploring this as well, with no clear proposal yet.

The no results part though is something we need to handle in the current implementation of Query/Loop.

[bobbingwide]

The main problem that needs solving regarding the context, includes showing the proper results in the client side as well.

Hi @ntsekouras. I don't understand what you're saying. What do you mean by "showing the proper results in the client side"?

[ntsekouras]

Hi @ntsekouras. I don't understand what you're saying. What do you mean by "showing the proper results in the client side"?

Query block is meant to be used for FSE, so the detection and handling of a query with inherited global query or not, needs to be consistent in the site editor as well. For example if you have a category.html template in an FSE blocks theme, it should be able to show the proper results in the site editor as well. Not only when we look the final result in the front-end (rendered by php).

Makes sense? If not please tell me and I'll try to rephrase.

[bobbingwide]

Query block is meant to be used for FSE, so the detection and handling of a query with inherited global query or not, needs to be consistent in the site editor as well. For example if you have a category.html template in an FSE blocks theme, it should be able to show the proper results in the site editor as well.

The challenge is for the Site Editor to know which main queries are going to be handled by the template and to simulate those queries.

But how would category.html know which category to use in its simulated query?
For archive.html the problem is harder, which has to cater for author, category, archive-$posttype, etc.
And for index.html, in my opinion, all bets are off.

I submitted this PR since I wanted to make progress with my own experimental theme.
I was able to find a solution that works in the front end, which is where I actually need it right now.
It has partially satisfied one of my requirements. I have many more for which I can't yet envisage solutions using FSE.

[ntsekouras]

But how would category.html know which category to use in its simulated query?
For archive.html the problem is harder, which has to cater for author, category, archive-$posttype, etc.
And for index.html, in my opinion, all bets are off.

Yeah, I know this is quite a problem... I don't have a clear solution yet myself.

Nevertheless, I believe a solution should involve clear decisions on that first and then handle the front-end as well. Another problem with handling this in QueryLoop alone is that you cannot customize it with the other options provided by Query block, like postsPerPage, order etc..

[bobbingwide]

Another problem with handling this in QueryLoop alone is that you cannot customize it with the other options provided by Query block, like postsPerPage, order etc..

With the code I've delivered the core/query-loop runs against the main query using the query options filtered by the plugins and/or theme.

In this example the content being displayed is oik-blocks, the number of posts per page is 6, and the orderby is title asc.
Here my plugins decide the order in which the archive is displayed.

The template being used is archive.html

<!-- wp:template-part {"slug":"header-2-columns","theme":"fizzie"} /-->
<!-- wp:template-part {"slug":"a2z-pagination","theme":"fizzie"} /-->
<!-- wp:template-part {"slug":"breadcrumbs","theme":"fizzie","className":"breadcrumbs"} /-->
<!-- wp:template-part {"slug":"archive-query","theme":"fizzie","tagName":"section","className":"archive"} /-->
...

and the archive-query.html template part file is

<!-- wp:query-loop -->
<!-- wp:group {"className":"article"} -->
<div class="wp-block-group article"><div class="wp-block-group__inner-container">
    <!-- wp:post-title {"isLink":true} /-->
    <!-- wp:post-featured-image {"isLink":true} /-->

</div></div>
<!-- /wp:group -->
<!-- /wp:query-loop -->

<!-- wp:query-pagination /-->

Note: the use of the core/query-pagination block, also working with the main query

The same template file is used to display the oik-plugins CPT, with no need for the core/query block.

It would be nice if the core/query and core/query-posts blocks could work together to enhance the main query.
In the mean time, I've implemented a pragmatic solution that enables me to continue with my theme development
and, if implemented in Gutenberg, will enable others to do the same.

After all, this is still experimental.

[bobbingwide]

Nevertheless, I believe a solution should involve clear decisions on that first and then handle the front-end as well.

You have to start from somewhere. I chose to get the server side logic for the front end to work.

I have many more (requirements) for which I can't yet envisage solutions using FSE.

I have a theme where the main blog page is currently implemented using the main query but has three separate display formats:

1. The hero post at the top.
2. Blocks of posts on the current page for posts that had featured images - in multiples of 4.
3. The remainder of the posts for the current page displayed as links.

The pagination applies to the whole page.

[ntsekouras]

Thanks so much for your efforts here @bobbingwide, really appreciate it!

I'll close this PR now though, as this has been implemented here: #27128