#59736 closed defect (bug) (fixed)
Regression: Singular block template
Reported by: |
|
Owned by: |
|
---|---|---|---|
Milestone: | 6.4 | Priority: | high |
Severity: | normal | Version: | |
Component: | Query | Keywords: | has-patch has-unit-tests commit dev-reviewed |
Focuses: | Cc: |
Description (last modified by )
In
https://github.com/wordpress/wordpress-develop/commit/5269bf66f47be1d608fd459b17764f775a04b4b9 a problem was fixed for getting singular block templates in the main query loop.
In testing I’ve found a regression where a singular template doesn’t display its blocks. The simplest way to demonstrate this is
- create a new installation with WP 6.3.x and the
echo-knowledge-base
plugin. - Activate the plugin and use the default choices to create a new knowledge base. You must select the KB Template and use a block theme.
- View any of the KB articles.
- Use CLI to update to current 6.4-RC
- View the KB article and see that there is no content displayed.
@costdev did some great detective work and determined the above changeset introduced the regression.
Pinging @flixos90
Change History (19)
#3
@
16 months ago
- Summary changed from Singular block template regression to Regression: Singular block template
#4
@
16 months ago
We are the authors of the echo-knowledge-base plugin. We implemented the following change in our single post template file (single-article.php) that seem to fix the issue:
<?php if ( in_the_loop() ) { // KB article content; } else { while ( have_posts() ) { the_post(); // KB article content; } }
Please let us know if there is anything else we should add or change.
This ticket was mentioned in Slack in #core by hellofromtonya. View the logs.
16 months ago
#6
@
16 months ago
- Owner set to flixos90
- Severity changed from critical to normal
- Status changed from new to assigned
Thank you @afragen and @echoplugins. I have investigated the issue, and indeed the problem is that the custom block template that the plugin injects technically includes a "classic" style template file which includes a loop itself.
The plugin fix posted above should indeed resolve the problem, but I have also been looking at a core solution: When plugins hijack the block template loading mechanism to inject their own custom block template, we should probably skip this logic, as there could be virtually any logic applied at this point, including triggering a loop. I am working on a PR.
This ticket was mentioned in PR #5575 on WordPress/wordpress-develop by @flixos90.
16 months ago
#7
- Keywords has-patch has-unit-tests added; needs-patch removed
Generally, the block template loaded should always be associated with the current theme since:
- It either comes from a
WP_Query
that filters to block templates only for theget_stylesheet()
theme - Or it comes from the current theme's file system
In both cases, the template ID will begin with get_stylesheet() . '//'
.
There are rare situations (e.g. the https://wordpress.org/plugins/echo-knowledge-base/ plugin as reported in the Trac ticket) where a plugin hijacks the block template loading mechanism to inject its own block template, which thus comes from outside the theme and may use _any_ logic. In those cases, the situation is unpredictable by core and therefore the assumption that no main query loop will be present for a singular WP_Query
is no longer reliable. As such, in those cases no main query loop should be started, as that would lead to problems if the custom logic was going to attempt to start the main query loop itself. So for those cases, the PR simply falls back to the original pre-6.4 logic of just parsing blocks.
Trac ticket: https://core.trac.wordpress.org/ticket/59736
#8
@
16 months ago
The PR https://github.com/WordPress/wordpress-develop/pull/5575 addresses the bug. When applied, the Knowledge Base articles from the plugin should display correctly again.
Please read the PR description for additional context on the approach for the fix.
This ticket was mentioned in Slack in #core by hellofromtonya. View the logs.
16 months ago
#11
@
16 months ago
A colleague alerted me to an issue in WooCommerce Blocks that seems related to this issue.
In the render code for this block we just loop through
have_posts()
and then output the template part. You can see the very simple code here.
It seems that, in 6.4, however,
have_posts()
isfalse
, and so we don’t get into the while loop. This is a bit odd, as if I inspect global$wp_query
I can see it correctly. And, even calling$wp_query->have_posts()
resets the loop and makes it work correctly.
In testing PR 5575, confirmed the patch resolves the issue.
@hellofromTonya commented on PR #5575:
16 months ago
#12
Cross-sharing a test report from the ticket: WooCommerce Blocks had a related issue, which is fixed by this PR ✅
#13
@
16 months ago
I tested PR 5575 and it successfully resolved the issue. Thanks For PR @flixos90
#14
@
16 months ago
- Keywords commit dev-reviewed added
Patch: https://github.com/WordPress/wordpress-develop/pull/5575
With multiple approvals and positive test reports, the patch is ready for commit. To expedite, also approving for backport to the 6.4 branch.
#16
@
16 months ago
- Resolution fixed deleted
- Status changed from closed to reopened
Reopening for backport.
@flixos90 commented on PR #5575:
16 months ago
#17
Committed in https://core.trac.wordpress.org/changeset/57019
Regression introduced by [56507] / #58154.
Pinging those involved with that changeset: @gziolo @youknowriad @joemcgill @costdev @mukesh27 @flixos90