Make WordPress Core

Opened 2 years ago

Last modified 5 weeks ago

#55023 accepted defect (bug)

get_header() notice: Theme without header.php is deprecated

Reported by: kpdaa's profile kpdaa Owned by: audrasjb's profile audrasjb
Milestone: 6.6 Priority: normal
Severity: normal Version: 5.9
Component: Themes Keywords: needs-patch
Focuses: template, multisite Cc:

Description (last modified by sabernhardt)

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)

screenshot-example.png (134.5 KB) - added by johnregan3 2 years ago.
Example Screenshot from /wp-signup.php
55023.diff (1.9 KB) - added by sabernhardt 21 months ago.
removes the deprecation notice from block themes
55023.wip.diff (3.9 KB) - added by sabernhardt 20 months ago.
an attempt at updating the theme-compat files, also replacing the special title function

Download all attachments as: .zip

Change History (38)

#1 @SergeyBiryukov
2 years ago

  • Component changed from General to Themes
  • Focuses multisite added
  • Milestone changed from Awaiting Review to 5.9.1

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, or update the multisite signup page.

Moving to 5.9.1 for investigation.

Last edited 2 years ago by SergeyBiryukov (previous) (diff)

#2 @mukesh27
2 years ago

Hi there!

I reproduce the issue in Multisite. Will ship patch soon.

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


2 years ago

#4 @audrasjb
2 years ago

@mukesh27 is this ticket still in your todo? thanks :)

#5 @metodiew
2 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 @audrasjb
2 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 @manfcarlo
2 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.


2 years ago

#9 @SergeyBiryukov
2 years ago

  • Summary changed from deprecated issue on multisite reqgister page. to get_header() notice: Theme without header.php is deprecated

#10 @SergeyBiryukov
2 years ago

#55317 was marked as a duplicate.

#11 @audrasjb
2 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.

@johnregan3
2 years ago

Example Screenshot from /wp-signup.php

#12 @ipapproval
2 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.


2 years ago

#14 @audrasjb
2 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 @manfcarlo
2 years ago

Just notifying that this was also reported at https://github.com/WordPress/gutenberg/issues/33989

#16 @SergeyBiryukov
2 years ago

#55447 was marked as a duplicate.

#17 @audrasjb
2 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 @audrasjb
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 @chandrapatel
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 and body tags and header & footer parts from block theme. Maybe add it directly to wp-signup.php file or create template file in wp-includes/theme-compat/ folder.
  • If active theme is classic theme, then call get_header() and get_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.

@sabernhardt
21 months ago

removes the deprecation notice from block themes

#21 @sabernhardt
21 months 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: @lgedeon
21 months 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 @manfcarlo
21 months 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.

@sabernhardt
20 months ago

an attempt at updating the theme-compat files, also replacing the special title function

#24 follow-up: @sabernhardt
20 months 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 @manfcarlo
20 months 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 @audrasjb
20 months 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.

#27 @SergeyBiryukov
19 months ago

#56885 was marked as a duplicate.

#28 @manfcarlo
17 months ago

#55529 was marked as a duplicate.

#29 @bbioon
15 months ago

Any news on this?

This ticket was mentioned in Slack in #core-test by robinwpdeveloper. View the logs.


15 months ago

#31 @sovetski927
4 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 @audrasjb
4 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.

#33 @sabernhardt
4 months ago

  • Focuses multisite added

#34 @poena
5 weeks ago

  • Milestone changed from Future Release to 6.6

#35 @poena
5 weeks ago

#58914 was marked as a duplicate.

Note: See TracTickets for help on using tickets.