Make WordPress Core

Opened 7 months ago

Closed 7 months ago

Last modified 7 months ago

#59629 closed defect (bug) (fixed)

Header and Footer template parts broken in 6.4-beta4

Reported by: mmcalister's profile mmcalister Owned by: bernhard-reiter's profile Bernhard Reiter
Milestone: 6.4 Priority: high
Severity: normal Version: 6.4
Component: Themes Keywords: has-patch has-unit-tests needs-testing commit
Focuses: Cc:

Description

Hi there,

I'm testing on 6.4-beta4 and there seems to be an issue with template parts in the site editor. The issue is not seen on 6.3.2.

I'm getting the following error on any templates that use header/footer template parts and patterns. Potentially related to work done on #59583.

Template part has been deleted or is unavailable: header

I'm testing on my Ollie theme, but have also confirmed the issue in other block themes.

To replicate, get on the 6.4-beta4 via the Beta Tester plugin, activate Ollie, go to the Site Editor and you should see the header/footer errors.

Previously, I had a suspicion that something with the Create Block Theme plugin was causing this, but after testing in a few different environments, it seems specific to the latest beta.

Attachments (4)

image.png (65.7 KB) - added by aegkr 7 months ago.
page-with-wide-image-template-error.png (433.5 KB) - added by sunitarai 7 months ago.
"Template part has been deleted or is unavailable: header" error on Page with wide image template
all-templates-except-Blog-Home.png (3.0 MB) - added by sunitarai 7 months ago.
"Template part has been deleted or is unavailable: header" issue appears on all templates except Blog Home
page-with-sidebar.png (423.7 KB) - added by shresthaaman 7 months ago.
Found error of header and footer on the Page with Sidebar.

Change History (48)

#1 @mmcalister
7 months ago

To clarify on the testing instructions, when you go into the editor, click into one of the templates like Page (Full Width, No Title) to see the template part error. The error is not shown on the default blog index.

#2 @swissspidy
7 months ago

  • Component changed from Editor to Themes
  • Milestone changed from Awaiting Review to 6.4

Saw this too in local development, but thought it was just a glitch with my setup or a stale cache.
This was not in the site editor though, I simply visited the site‘s homepage.

#3 @thelovelist
7 months ago

To address issues with broken Header and Footer template parts in WordPress 6.4-beta4, follow these steps:

Check for Theme/Plugin Conflicts:
Disable all plugins.
Switch to a default theme (e.g., Twenty Twenty-One).
See if the issue persists.

Clear Cache

Debugging

Check the PHP error logs for any related errors.
Inspect your theme and template files for errors.

I have personally applied these methods on my website daily media insight.my problem has been solved. thats;why sharing this tips.

Thanks
Daily Media Insight
https://dailymediainsight.com/french-tip-nails-ideas/

#4 @hellofromTonya
7 months ago

I'm getting the following error on any templates that use header/footer template parts and patterns. Potentially related to work done on #59583.

Hey @bernhard-reiter, can you check if this bug is related to #59583. Thanks!

Also pinging 6.4 Editor Tech/Triage Leads @mikachan @siobhyb @karmatosed @annezazu @bph.

This ticket was mentioned in Slack in #core-editor by hellofromtonya. View the logs.


7 months ago

#6 @pbiron
7 months ago

I can confirm this problem.

I hadn't seen a problem with any site I'd tested 6.4-beta4 on until I saw this ticket (all of which use custom themes).

I switched those sites from their custom themes to one of the bundled themes (TT4, TT3, TT2) and/or Ollie and the problem surfaced. Switched back to their custom themes and the problem went away.

This left be baffled. I then realized that, yes, in my custom themes the template part blocks in all the templates all used the "theme" attribute (e.g., <!-- wp:template-part {"slug":"header","theme":"my-theme","tagName":"footer"} /-->). If I remove that attribute from the template part blocks in my custom themes, then problem surfaces with my custom themes.

So, it definitely looks related to #59583.

This ticket was mentioned in Slack in #core by hellofromtonya. View the logs.


7 months ago

#8 @Pauthake015
7 months ago

I also experienced this while testing TT4, TT3 and Blue Note themes yesterday.

This ticket was mentioned in Slack in #core by nicolefurlan. View the logs.


7 months ago

#10 @richtabor
7 months ago

Came here to report the same. I can replicate with a fresh site and Twenty Twenty-Four active. Open the site editor, then click on "Templates" and then any of the templates within that view.

It looks like template parts loaded from patterns work fine, but template parts loading from templates do not. The reason the home.html template works on a blank site running TT4 is that the template is technically loading a pattern (template-home-business.php).

#11 @nicolefurlan
7 months ago

This ticket was discussed in today's bug scrub.

This needs to be fixed as it was introduced in the 6.4 cycle. If the root cause can't be identified by RC1, we may leave it in the cycle to get fixed by RC2.

Props @hellofromTonya

#12 @hellofromTonya
7 months ago

  • Priority changed from normal to high

Heads up: I've moved this ticket to a high priority. Why? The bug was introduced during the 6.4 cycle and has the potential to be problematic for users. IMO this bug needs to be fixed for 6.4, if the root cause can be found.

Have pinging folks here and in Make/Core #core and #core-editor channels. Will closely monitor its progress.

#13 @huzaifaalmesbah
7 months ago

I noticed this issue in 6.4-beta4. Beta3 is fine.
I'm testing on TT4 theme.

6.4-beta4

https://i.ibb.co/s63sj80/Screenshot-2023-10-17-at-12-41-18-AM.png

6.4-beta3

https://i.ibb.co/DK6256R/Screenshot-2023-10-17-at-12-40-29-AM.png

#14 @annezazu
7 months ago

Can replicate and confirm the problem. +1 to this being high priority to fix.

#15 @kafleg
7 months ago

Oh, I was also checking in InstaWP and noticed the same thing. It's not only the header and footer template part missing, it is missing all template parts.

#16 @aegkr
7 months ago

I checked with Twenty Twenty-Three theme as well and found similar issue. Initially I was thinking theme issue but after checking Twenty Twenty-Three theme I see that it is editor issue.

@aegkr
7 months ago

#17 @sunitarai
7 months ago

I can also replicate the error. I tested on the Local WP environment with the Twenty Twenty Four theme activated. The issue appears on all templates except 'Blog Home'.

@sunitarai
7 months ago

"Template part has been deleted or is unavailable: header" error on Page with wide image template

@sunitarai
7 months ago

"Template part has been deleted or is unavailable: header" issue appears on all templates except Blog Home

#18 follow-up: @mmcalister
7 months ago

I've just noticed on the WP.org theme demos, headers and footers are completely missing from the theme previews. Is this related?

Ollie demo
Gutenify
BoostUp

#19 @shresthaaman
7 months ago

I also tested it and found the similar issue on on WordPress 6.4-beta4 with the Twenty Twenty Four theme activated.

@shresthaaman
7 months ago

Found error of header and footer on the Page with Sidebar.

#20 in reply to: ↑ 18 @kafleg
7 months ago

Yes, good catch. Org preview is not working. WordPress.org is also using Beta 4.

Replying to mmcalister:

I've just noticed on the WP.org theme demos, headers and footers are completely missing from the theme previews. Is this related?

Ollie demo
Gutenify
BoostUp

#21 @andraganescu
7 months ago

I would like to confirm this bug as well - seen on my production blog.
The home template loads parts but other templates like archives do not, they err out in the editor with a not found message.

This ticket was mentioned in Slack in #core by hellofromtonya. View the logs.


7 months ago

#23 @hellofromTonya
7 months ago

Discussing in Make/Core slack.

This is a high priority that needs to be fixed in 6.4.

If it needs more time, advising for it to stay in the release to be fixed by RC2.

#24 @Bernhard Reiter
7 months ago

Apologies, I wasn't working yesterday and only saw this now. Will investigate shortly.

#25 @Bernhard Reiter
7 months ago

Some preliminary findings:

  • When I open the network console while in the site editor, I see two failed network requests (404) for the header and footer template parts, respectively, i.e. to http://localhost:8889/index.php?rest_route=%2Fwp%2Fv2%2Ftemplate-parts%2Fundefined%2F%2Fheader&context=edit&_locale=user (and to the same URL with header replaced by footer).
  • The theme attribute is present in the preloaded templates in the page source.
  • Does that mean that something on the client side is removing the theme attr?
  • Reverting [56896] seems to fix the issue.

#26 @Bernhard Reiter
7 months ago

The theme attribute is present in the preloaded templates in the page source.

Correction, I saw it present for the single template, but not e.g. for the page template.

Maybe this is the reason: In [56896], we made theme attribute conditional on the presence of the REST_REQUEST constant; but that constant isn't set when outputting the preloaded templates.

#27 @Bernhard Reiter
7 months ago

To validate, let's maybe add a unit test for rest_preload_api_request to check for presence of the theme attr.

For a more short-term solution, we might consider reverting [56896]. That will impact performance negatively but shouldn't have any other adverse side-effects.

Last edited 7 months ago by Bernhard Reiter (previous) (diff)

This ticket was mentioned in PR #5509 on WordPress/wordpress-develop by @Bernhard Reiter.


7 months ago
#28

  • Keywords has-patch has-unit-tests added

This reverts commit 33870e19246a54a72f8f3ae0f4d4cb1096306121.

Trac ticket: https://core.trac.wordpress.org/ticket/59629

#29 @hellofromTonya
7 months ago

  • Keywords needs-testing added

Also discussing in Make/Core slack.

If the revert does indeed solve the editor regression of a broken experience, then I support doing the revert.

What about performance?
[56896] provided a 2.5% to 3.3% performance gain for rendering the TT4 home page. The revert could mean these boosts will be lost.

Performance is indeed important.

But in this case, IMO a broken editor experience is the more critical consideration. Given that RC1 is today, I think a revert is needed.

Next steps

@bernhard-reiter prepared a revert patch. Test report(s) is needed to further confirm the regression is resolved.

#30 @hellofromTonya
7 months ago

Noting @gziolo observation (from Make/Core slack):

One surprising thing in the reports on the ticket about missing template parts is that it also applies to the front end. I’m wondering if the revert will help with the listed themes. With the changes introduced, the Template Part block should use the current theme name as a fallback, which aligns with what the injecting mechanism did before. Anyway, I hope I’m wrong and the patch from Bernie is all that’s necessary at this stage.

#31 @pbiron
7 months ago

I can confirm that the PR to revert #59583 does, indeed, resolve the problem...with all the bundled themes, Ollie, and some of my own custom themes.

#32 @hellofromTonya
7 months ago

I too can reproduce the issue on TT4. The revert of [56896] (using the PR) resolves it.

#33 @gziolo
7 months ago

  • Keywords commit added

I confirm that the revert looks correctly and it works correctly in my local testing with TT4 on both the front end and in the site editor covering template editing and pages editing screens.

This ticket was mentioned in Slack in #core by bernhardreiter. View the logs.


7 months ago

#35 @Bernhard Reiter
7 months ago

  • Owner set to Bernhard Reiter
  • Resolution set to fixed
  • Status changed from new to closed

In 56960:

Patterns, Templates: Inject theme attr into Template Part blocks.

It was found that Template Part blocks were broken in the Site Editor, showing the Template part has been deleted or is unavailable message, due to a missing theme attribute.

This bug seems to have been introduced by [56896], whose goal was to only inject that attribute into the markup returned by the templates and patterns REST API endpoints but not on the frontend, in order to improve performance. It has been demonstrated locally that reverting that changeset fixes the bug.

Reverts [56896].
Props mmcalister, swisspidy, thelovelist, hellofromTonya, pbiron, Pauthake015, richtabor, nicolefurlan, huzaifaalmesbah, annezazu, kafleg, aegkr, sunitarai, shresthaaman, andraganescu, onemaggie, gziolo.
Fixes #59629.

This ticket was mentioned in PR #5514 on WordPress/wordpress-develop by @Bernhard Reiter.


7 months ago
#37

Not planning to land this for 6.4, it's been too much of a 🎢

WIP, early stages.

Since we had to revert our previous attempt at this, I'm starting a new draft PR based on the notes I posted here.

TODO:

  • [ ] Move hooked blocks insertion to the patterns controller so we can remove it from WP_Block_Patterns_Registry
  • [ ] Make sure hooked block insertion is run on the frontend. We can probably achieve that through running it in the Pattern block's render_block.
  • [ ] Apply the same changes to Templates?

_When testing, make sure that this doesn't cause this regression (it currently still does; needs more tweaking!)_

Trac ticket: TBD

@flixos90 commented on PR #5514:


7 months ago
#38

Thanks for the ping @ockham. Do we know _why_ the revert in #5509 fixed the problem? Why did the ( defined( 'REST_REQUEST' ) && REST_REQUEST ) not work? Is it because the relevant REST endpoint that needs this is preloaded via PHP (in which case REST_REQUEST would not be defined)? Or why was that insufficient / unreliable as a solution?

@gziolo commented on PR #5514:


7 months ago
#39

Why did the ( defined( 'REST_REQUEST' ) && REST_REQUEST ) not work? Is it because the relevant REST endpoint that needs this is preloaded via PHP (in which case REST_REQUEST would not be defined)?

I haven't had a chance to have a closer look, but it would be my understanding that this check won't work with the preloading feature. I'm wondering if it would be possible to create a helper function like wp_is_rest_request which would account for preloading requests with some magic global, too.

@Bernhard Reiter commented on PR #5514:


7 months ago
#40

Yeah, my best guess is that REST_REQUEST isn't set to true when preloading. I didn't verify 100% but did notice that at the time, the theme attribute was missing for a number of template parts on trunk but was correctly injected on the revert branch.

@Bernhard Reiter commented on PR #5514:


7 months ago
#41

BTW if that's indeed the reason, it raises the question why we're not setting REST_REQUEST to true right before preloading in the first place (and back to false right after -- if that's possible in PHP with define? 🤔 )

It seems like we'd like to mimic a REST API request context as closely as possible when preloading routes (not just in this case, but for all routes really 🤔 )

@Bernhard Reiter commented on PR #5514:


7 months ago
#42

setting REST_REQUEST to true right before preloading in the first place (and back to false right after -- if that's possible in PHP with define? 🤔 )

Ah nevermind, can't redefine a constant. Fair enough 😬

@flixos90 commented on PR #5514:


7 months ago
#43

@ockham That's why there is this ticket: https://core.trac.wordpress.org/ticket/42061

If it was moving forward, it would allow us to more properly test REST API specific logic, as there would be a filter to use instead of being limited to the constant.

@Bernhard Reiter commented on PR #5514:


7 months ago
#44

@ockham That's why there is this ticket: https://core.trac.wordpress.org/ticket/42061

Ah, TIL! Thank you for the pointer :)

If it was moving forward, it would allow us to more properly test REST API specific logic, as there would be a filter to use instead of being limited to the constant.

👍

Note: See TracTickets for help on using tickets.