Header and Footer template parts broken in 6.4-beta4

[mmcalister]

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.

[mmcalister]

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.

[swissspidy]

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.

[thelovelist]

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/

[hellofromTonya]

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.

[pbiron]

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.

[Pauthake015]

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

[richtabor]

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).

[nicolefurlan]

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

[hellofromTonya]

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.

[huzaifaalmesbah]

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

6.4-beta4

6.4-beta3

[annezazu]

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

[kafleg]

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.

[aegkr]

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.

[sunitarai]

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]

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

[sunitarai]

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

[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

[shresthaaman]

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

[shresthaaman]

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

[kafleg]

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

[andraganescu]

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.

[hellofromTonya]

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.

[Bernhard Reiter]

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

[Bernhard Reiter]

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.

[Bernhard Reiter]

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.

[Bernhard Reiter]

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.

This reverts commit 33870e19246a54a72f8f3ae0f4d4cb1096306121.

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

[hellofromTonya]

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.

[hellofromTonya]

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.

[pbiron]

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.

[hellofromTonya]

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

[gziolo]

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.

[Bernhard Reiter]

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.

Committed to Core in https://core.trac.wordpress.org/changeset/56960 😊

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

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?

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.

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.

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 🤔 )

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 😬

@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.

@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.

👍