Opened 3 years ago
Last modified 4 months ago
#55023 accepted defect (bug)
get_header() notice: Theme without header.php is deprecated
Reported by: | kpdaa | Owned by: | audrasjb |
---|---|---|---|
Milestone: | 6.7 | Priority: | normal |
Severity: | normal | Version: | 5.9 |
Component: | Themes | Keywords: | needs-patch |
Focuses: | template, multisite | Cc: |
Description (last modified by )
1) i had install 2022 theme on one of the multisite (site.alakh.co.in)
2) Overall theme works well. Just found one issue.
3) on my site's register/signup page (https://site.alakh.co.in/wp-signup.php). i see following error in header and footer.
error msg:
Deprecated: Theme without header.php is deprecated since version 3.0.0 with no alternative available. Please include a header.php template in your theme. in .../wp-includes/functions.php on line 5516
kindly help me in solving this issue.
Attachments (3)
Change History (40)
#1
@
3 years ago
- Component changed from General to Themes
- Focuses multisite added
- Milestone changed from Awaiting Review to 5.9.1
This ticket was mentioned in Slack in #core by audrasjb. View the logs.
3 years ago
#5
@
3 years ago
hey hey,
We have the same deprecation notice for the footer.php
file as well:
Deprecated: File Theme without footer.php is <strong>deprecated</strong> since version 3.0.0 with no alternative available. Please include a footer.php template in your theme. in /var/www/html/wpbleedingms/src/wp-includes/functions.php on line 5516
I run a quick test by adding
if ( function_exists( 'register_block_pattern' ) ) { return; }
in src/wp-includes/theme-compat/footer.php
and src/wp-includes/theme-compat/header.php
just for the experiment but this is displaying a blank HTML page :)
What would be the best approach to apply a fix for these?
#6
@
3 years ago
- Milestone changed from 5.9.1 to 5.9.2
Given this ticket still needs a patch and as 5.9.1 RC1 is tomorrow, let's move it to the next point release.
#7
@
3 years ago
This happens when wp-signup.php
calls the get_header and get_footer template tags. There are new template tags block_header_area and block_footer_area that could be used instead, but it would probably make more sense for block template parts to be automatically retrieved through the get_header and get_footer template tags if they exist, so that the caller does not need to check whether it's a block theme or not.
This ticket was mentioned in Slack in #core by sergey. View the logs.
3 years ago
#9
@
3 years ago
- Summary changed from deprecated issue on multisite reqgister page. to get_header() notice: Theme without header.php is deprecated
#11
@
3 years ago
- Milestone changed from 5.9.2 to 5.9.3
Moving to milestone 5.9.3 since we're about to release 5.9.2.
#12
@
3 years ago
Hope this isn't too 'off topic'..
We use add_action('get_header', 'function');
in our ip-approval.php file, to trigger the plugin to run before a page or post is loaded. Because get_header();
is not called our plugin fails to execute.
Being that the header is currently required, our plugin should work fine will any Theme. This change will break our plugin's functionality.
Technically we can use add_action('get_head', 'function');
however loading the plugin before the page/post starts to load would be preferred.
That said, if we do not use one of the two above add_action's, to trigger our plugin on a page/post, and just try to use is_page()
is_page does not work. is_page()
will be false (or at least not true) even though it is a page.
For reference, at the bottom of our ip-approval.php file, we have the following code (non-explanatory code omitted);
/* Add IP Approval IP Checker to page/post --------------------------------------------------------------------*/ add_action('wp_header', 'ip_checker_action'); function ip_checker_action(){ if (is_page()){ // if it is a page, do page stuff } else { // else it is a post, do post stuff } } /* Add IP Approval IP Checker to login --------------------------------------------------------------------*/ add_filter('login_init', 'ip_login_action'); function ip_login_action() { // triggered only on the login page }
This ticket was mentioned in Slack in #core by audrasjb. View the logs.
3 years ago
#14
@
3 years ago
- Owner set to audrasjb
- Status changed from new to accepted
Self assigning for further investigation, and hopefully ship a patch in 5.9.3.
#15
@
3 years ago
Just notifying that this was also reported at https://github.com/WordPress/gutenberg/issues/33989
#17
@
3 years ago
- Milestone changed from 5.9.3 to 5.9.4
Since WordPress 5.9.3 Release Candidate is supposed to be released today, and as this ticket is still waiting for a patch, let's move it to milestone 5.9.4.
This ticket was mentioned in Slack in #core by mike. View the logs.
2 years ago
#19
@
2 years ago
- Milestone changed from 5.9.4 to 6.1
Moving this ticket to next major release since it wasn't addressed during this cycle. Anyone is welcome to move it back to 6.0.x minor releases cycle if a patch is ready to ship.
#20
@
2 years ago
I was trying loading header and footer parts of block theme on signup page using block_header_area()
and block_footer_area()
functions but having some issues like some CSS was not loading and header and footer parts looks broken. Currently, I don't know how CSS loads for block theme. I have checked with 2022 theme. Header and footer parts in block theme do not render html
, head
and body
tags so I have tried those functions in header.php
and footer.php
files in wp-includes/theme-compat/
folder for testing.
Those functions load main header
and footer
parts. In block theme, user can add custom header and footer parts but since signup page is not template, so user can't use custom header/footer parts.
To give support of block theme's header and footer parts for signup page,
- If active theme is block theme, then render
html
,head
andbody
tags and header & footer parts from block theme. Maybe add it directly towp-signup.php
file or create template file inwp-includes/theme-compat/
folder. - If active theme is classic theme, then call
get_header()
andget_footer()
.
I'm not sure whether it's correct approach. I think until block theme support for signup page, don't throw deprecation warning if active theme is block theme.
#21
@
2 years ago
- Description modified (diff)
- Keywords has-patch added; needs-patch removed
If someone could make a patch that fetches the block theme's header and footer templates, that would be better than mine. But the deprecation notice is not meant for block themes, so it should not display.
Perhaps a patch like this could be committed (and backported?), and then discussion about a better method could continue on GB33989.
Also, I'm curious why wp-activate.php did not show the warning even though it uses the same theme-compat files as wp-signup.
#22
follow-up:
↓ 23
@
2 years ago
If block themes do not require header.php and footer.php, then they must have an alternative. If that alternative is in place then the compatibility files will never be reached and so they are still deprecated.
The solution of only showing the deprecation for classic themes misses the point that these files should not be used for either block or classic themes. They contain hard-coded <hr /> tags and other content that does not make sense for block themes.
These files should never be loaded. Deprecation is correct, but it needs to be expanded with an explanation of how block themes can avoid these files being loaded.
#23
in reply to:
↑ 22
@
2 years ago
Replying to lgedeon:
If block themes do not require header.php and footer.php, then they must have an alternative. If that alternative is in place then the compatibility files will never be reached and so they are still deprecated.
The solution of only showing the deprecation for classic themes misses the point that these files should not be used for either block or classic themes. They contain hard-coded <hr /> tags and other content that does not make sense for block themes.
These files should never be loaded. Deprecation is correct, but it needs to be expanded with an explanation of how block themes can avoid these files being loaded.
Agreed. The patch essentially un-deprecates these files for block themes, which was probably not the intention.
I previously suggested to use block_header_area
and block_footer_area
and a few other people suggested the same, but after a closer look, I have changed my mind about this.
The issue is that header.php
is expected to include <!DOCTYPE html>
, <html>
, wp_head();
, <body>
and also typically includes the opening tag of a max-width container, while footer.php
will close all of these tags and also call wp_footer();
. Block headers and footers do not and can not do any of these things, because it is not possible to open and close the same block in two different template parts.
In other words, using block_header_area
and block_footer_area
in this context will not only put browsers into quirks mode, but will also fail to apply any max-width containers to the signup form, which will leave the page looking rather ugly.
The code that is really needed here is located in https://core.trac.wordpress.org/browser/tags/6.0/src/wp-includes/template-canvas.php and one suggestion is to move this code directly into the get_header
and get_footer
functions for block themes and also call those functions from the template canvas file.
@
2 years ago
an attempt at updating the theme-compat files, also replacing the special title function
#24
follow-up:
↓ 25
@
2 years ago
- Keywords needs-patch added; has-patch removed
I did not think the deprecation notice was appropriate when the problem is in Core, but it does tell theme authors how they might work around that problem.
I tried adding block theme markup to the theme-compat files and attached it here in case someone would like to continue working on that concept. It seems less and less like a viable solution, even temporary.
- The styles and scripts are still wrong, yet disallowing the separate assets option helped some.
- The pages lack a skip to content link.
- At first, the title and viewport meta tags were not included with
wp_head
. Updating the_wp_render_title_tag
function and removing its Gutenberg replacement might help, regardless of whether the other changes are made.
We may need to prioritize the refactoring tickets in the next release cycle (#31928 and #33500).
#25
in reply to:
↑ 24
@
2 years ago
Replying to sabernhardt:
We may need to prioritize the refactoring tickets in the next release cycle (#31928 and #33500).
Addressing those tickets would certainly be welcome, but it would not solve this particular issue. https://github.com/WordPress/gutenberg/issues/33989 indicates that the same problem occurred through a plugin that was calling the get_header
and get_footer
functions, which plugins are (and should be) allowed to do.
#26
@
2 years ago
- Milestone changed from 6.1 to Future Release
With WP 6.1 RC 1 scheduled tomorrow (Oct 10, 2022), there is not much time left to address this ticket. Given it still needs a decision and a patch, let's move this ticket to Future Release
.
Ps: if you were about to send a patch and if you feel it is realistic to commit it in the next few hours, please feel free to move this ticket back to milestone 6.1.
This ticket was mentioned in Slack in #core-test by robinwpdeveloper. View the logs.
19 months ago
#31
@
9 months ago
- Focuses template added; multisite removed
- Severity changed from normal to critical
Hi, any update please? It is a very anoying problem, it comes with each WordPress default themes.
#32
@
9 months ago
- Severity changed from critical to normal
Hello @sovetski927 this ticket still needs a patch. Anyone is welcome to propose a patch or even a first workaround to address this issue, but for now it appears we don't have anything ready to ship yet either here or in the related Gutenberg issue. Once we get a patch, we can put the ticket in the next milestone.
Hi there, welcome back to WordPress Trac! Thanks for the report.
The deprecation messages for files in
wp-includes/theme-compat/
were added in [14365] / #13009. Looks like we may need to update them to account for block themes. Moving to 5.9.1 for investigation.