-
Notifications
You must be signed in to change notification settings - Fork 4.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
FSE: Incorrect template archive.html used for custom post type archive #27177
Comments
I came across this issue today as well, while working on #27128 gutenberg/lib/template-loader.php Lines 151 to 158 in cfb3696
@youknowriad what is the purpose of that code? 🤔 $priority_a = $slug_priorities[ $template_a->post_name ] * 2 + ( 'publish' === $template_a->post_status ? 1 : 0 );
$priority_b = $slug_priorities[ $template_b->post_name ] * 2 + ( 'publish' === $template_b->post_status ? 1 : 0 );
|
I believe that what's missing is any matching to what was asked for. It just picks the first array entry. |
The idea there was to give priority to the "published" templates over the "auto-draft" ones but without really affecting the order of the "slug_priorities". Maybe I got the condition inverted inadvertantly. |
Hmmm so if I have a published |
I changed the return from the
Results:
I then noticed that for
|
To resolve this additional issue I tried logging out, so that the auto-draft for author 0 was rebuilt. If I now log in again I expect there'll be new autodrafts created. |
I have now tested |
No no, if by mistake you end p with both archive-recipe as an auto-draft and one published, we'd prefer published. That's it but archive-recipe should always be more priotary than archive. I believe even the auto-draft/published check might not be required anymore after the refactoring of auto-drafts. |
Understood. 👍
Yeah, I believe we can just go ahead and replace the logic there with something as simple as this: usort(
$templates,
function ( $template_a, $template_b ) use ( $slug_priorities ) {
return $slug_priorities[ $template_a->post_name ] - $slug_priorities[ $template_b->post_name ];
}
); On my test site that seems to return the right result |
@aristath Would you be able to create a PR for that? |
Done. PR on #27303 👍 |
I think there is another behavior that got broken. Consider the case where you have a theme template named "front-page". You also create your own "front-page" template manually in wp-admin. Both are published. Currently, we are resolving the theme template, but the expected behavior is to resolve the user-created template. |
@noahtallen I believe that use-case should never happen, you shouldn't be able to create two CPT entries for the same theme and the same template name. |
I explained more about it here: #27322 (comment) The thing is that the "theme" gets set automatically to the current theme when you create a template, but in reality it's just something you made yourself |
It doesn't matter for me, what purpose there is in making two "front-page" templates. It shouldn't be possible. |
What if I have a customized |
If your front page was just a bunch of template parts would you expect it to load these from the old theme?
|
Yeah, that's a good point. I wonder if (at this time) we are marking template parts as customized + published if their parent template is modified. And then, what if each template part is also customized? Do we discard everything when switching themes, or do we allow users to keep one or two templates which they might want to stay the same? |
@noahtallen I'm sure you're aware that this whole business of template and template part loading and reconciliation is currently being reviewed by a number of parties, working on different Issues and PRs. I think that what's missing is a documented set of expectations for the Site Editor's and front end's behaviour when certain events occur. Requirements and proposed solutions are required for:
I've been looking at supporting multiple language versions. I intend to document my proposals today. They are based on prototype work I've been doing in bobbingwide/oik-i18n/issues/7 and bobbingwide/fizzie/issues/46. |
See #27402 |
Describe the bug
When I updated to Gutenberg 9.4.0 the template file being used for the archive display of my Blocks CPT changed to
archive.html
.Previously, in Gutenberg 9.3.0 the correct template file was being used:
archive-block.html
.Looking at
gutenberg_resolve_template()
I can't see how it can determine the correct template to use withoutreference to the post type or taxonomy.
It's the same problem for
single
templates.I've not tried post ID or post name specific templates but I imagine it's the same.
To reproduce
Steps to reproduce the behavior:
block
that supports archives.archive-block.html
andarchive.html
template files.Expected behavior
With 9.3.0 the template used was
archive-block
.Screenshots
Gutenberg 9.4.0 on the left, 9.3.0 on the right.
Both using the same Experimental FSE theme - Fizzie
with no custom
wp_template
orwp_template_part
posts except the 'auto-draft's.Editor version (please complete the following information):
Desktop (please complete the following information):
Additional context
This trace output shows the values of variables
$slugs
$templates
$slug_priorities
After the sort
$templates[0]
contains the archive post ( ID 1333 ).The text was updated successfully, but these errors were encountered: