FSE themes should have a way to set a default header and footer that maps to traditional header.php and footer.php in terms of backwards compatible loading

[caseymilne]

What problem does this address?

During a test of experimental FSE theme Proto we found that content from Better Docs plugin was rendered without our custom header and footer. The cause is that like many plugins it ships a page template that uses get_header() and get_footer(). These calls try to find header.php and footer.php and when the theme does not provide them it load a WP Core template header and footer. Instead we should add a mapping so that when the theme is determined to be FSE, the search is done for header.html under /block-template-parts. If a default header.html and footer.html is not found, only then should WP load a core template. Loading a core template is generally still needed because without it sites break due to no script loading.

What is your proposed solution?

Rework the template locate functionality in core so that it detects FSE and searches for header.html and footer.html under block-template-parts/ in the FSE theme. If found, load them in place of the PHP versions.

Although automatic detection seems sensible and mirrors the current approach where themes can expect header.php to be automatically loaded during a get_header call, there is also with FSE themes the possibility of defining a default header in theme.json. This doesn't seem entirely useful to me, but it would allow someone to define "header-sticky.html" as their default rather than swapping the content from a header-sticky.html into header.html. In the event of switching themes or portability of template perhaps that would be a benefit. I still think default function should mirror the header and footer autoloading currently done for classic themes.

[fwazeter]

This makes a lot of sense - as is, if you have a .php file with a higher specificity than your .html file, the .php file will take priority in rendering. For example - if you have singular.html in your /block-templates/ dir, and a single.php in your normal directory, the single.php will take priority over the singular.html.

Currently, some of the backward compatibility / use as much of FSE as possible w/o Gutenberg plugin shims we've been using have been to do something like adding:

//header.php echo do_blocks( file_get_contents( get_theme_file_path( '/block-template-parts/header.html' ) ) );

Which works, because it's just embedding the HTML markup in the .php template - but it gets a little tricky when you're, for example, doing that in an index.php file and when referencing markup in the index.html to include a header template-part - it doesn't affect front end rendering, but does throw a 'block type not supported' message in template editor, which throws people off. It also kind of works to help prevent a little bit of this, but the setup can get complex fast when trying to figure out what's rendering what.

So as it currently is, once you start mix and matching all the different template types in an effort for backwards compatibility, it can get very tricky in determining what's taking over priority over what and where the issue is unless you already know all the in's and outs of the template hierarchy.

[htmgarcia]

@fwazeter how do you render the html and head tags?
echo do_blocks( file_get_contents( get_theme_file_path( '/block-template-parts/header.html' ) ) );

[fwazeter]

It depends on what you're trying to achieve - since if you were using the above rather than simply using FSE HTML templates you could do your hooks in your .php file as you normally would, and then do the do_blocks(); line to pull from an html file for blocks.

If you're using an FSE theme, you might have to get a little creative - like a function that isn't in a template that's adding elements to the header, since I believe the FSE themes will just default to pulling HTML files to handle this.

[aristath]

Also worth noting:
In WP 5.9, 2 new functions were included, block_header_area() and block_footer_area() that you can use instead of echo do_blocks( file_get_contents( get_theme_file_path( '/block-template-parts/header.html' ) ) ); 👍

[jhnpldng01]

Also affects the following plugins. BasePress(inner kb pages), WCFM Frontend Manager(dashboard page) & Youzify(front end page)

Use any of those in conjunction with any FSE theme, including 2022, and the Header/Footer Template Parts go bye bye on their front end pages.

[sabernhardt]

Core's multisite registration and activation pages also need default header and footer templates. See Trac 55023.

[dansdev]

Hi there! I would love to know if there's been any movement on this?

In my use case I have a complex menu not suitable for the header.html part, which the header.php solves. In my own testing, I have created a header.php that is called in templates page.php etc.. (in place of FSE html templates) using get_header() which renders fine on the front end. Though when creating templates using the site editor, the header.php is excluded.

The proposed solution by @caseymilne of having a fall back to header.php and footer.php if the html counterparts are not found, would be a great!

[xs-mahbub]

Also worth noting: In WP 5.9, 2 new functions were included, block_header_area() and block_footer_area() that you can use instead of echo do_blocks( file_get_contents( get_theme_file_path( '/block-template-parts/header.html' ) ) ); 👍

Can anyone help me to put the block_header_area() function on the FSE theme where it needs to be placed?