#59629 closed defect (bug) (fixed)
Header and Footer template parts broken in 6.4-beta4
Reported by: |
|
Owned by: |
|
---|---|---|---|
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)
Change History (48)
#2
@
8 weeks 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
@
8 weeks 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
@
8 weeks 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.
8 weeks ago
#6
@
8 weeks 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.
8 weeks ago
This ticket was mentioned in Slack in #core by nicolefurlan. View the logs.
8 weeks ago
#10
@
8 weeks 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
@
8 weeks 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
@
8 weeks 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.
#15
@
7 weeks 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
@
7 weeks 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.
#17
@
7 weeks 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'.
@
7 weeks ago
"Template part has been deleted or is unavailable: header" error on Page with wide image template
@
7 weeks ago
"Template part has been deleted or is unavailable: header" issue appears on all templates except Blog Home
#18
follow-up:
↓ 20
@
7 weeks ago
I've just noticed on the WP.org theme demos, headers and footers are completely missing from the theme previews. Is this related?
#19
@
7 weeks ago
I also tested it and found the similar issue on on WordPress 6.4-beta4 with the Twenty Twenty Four theme activated.
#20
in reply to:
↑ 18
@
7 weeks 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?
#21
@
7 weeks 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 weeks ago
#23
@
7 weeks 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
@
7 weeks ago
Apologies, I wasn't working yesterday and only saw this now. Will investigate shortly.
#25
@
7 weeks 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
andfooter
template parts, respectively, i.e. tohttp://localhost:8889/index.php?rest_route=%2Fwp%2Fv2%2Ftemplate-parts%2Fundefined%2F%2Fheader&context=edit&_locale=user
(and to the same URL withheader
replaced byfooter
). - 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
@
7 weeks 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
@
7 weeks 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.
This ticket was mentioned in PR #5509 on WordPress/wordpress-develop by @Bernhard Reiter.
7 weeks ago
#28
- Keywords has-patch has-unit-tests added
This reverts commit 33870e19246a54a72f8f3ae0f4d4cb1096306121.
Trac ticket: https://core.trac.wordpress.org/ticket/59629
#29
@
7 weeks 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
@
7 weeks 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.
#32
@
7 weeks ago
I too can reproduce the issue on TT4. The revert of [56896] (using the PR) resolves it.
#33
@
7 weeks 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 weeks ago
#35
@
7 weeks ago
- Owner set to Bernhard Reiter
- Resolution set to fixed
- Status changed from new to closed
In 56960:
@Bernhard Reiter commented on PR #5509:
7 weeks ago
#36
Committed to Core in https://core.trac.wordpress.org/changeset/56960 😊
This ticket was mentioned in PR #5514 on WordPress/wordpress-develop by @Bernhard Reiter.
7 weeks 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 weeks 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?
7 weeks 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 weeks 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 weeks 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 weeks ago
#42
setting
REST_REQUEST
totrue
right before preloading in the first place (and back tofalse
right after -- if that's possible in PHP withdefine
? 🤔 )
Ah nevermind, can't redefine a constant. Fair enough 😬
@flixos90 commented on PR #5514:
7 weeks 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 weeks 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.
👍
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.