Wp-calypso: FSE: The header and footer template parts need to render on dynamic pages on the front end

[apeatling]

Any pages that are dynamically rendered like a post permalink page, or 404 page, or archives page will not render the header or footer template part.

Our current modern business theme and child themes will instead render the existing header and footer built into the theme files.

All pages static or dynamic will need to render these header and footer template parts on the front end. We don't need them in the editor for dynamic pages, but rendering on the front end is a must.

[vindl]

There are two approaches that we can investigate for solving this:

1. Override the theme template in the plugin, in a similar fashion that we do for static pages now.
2. Modify the theme template files to render FSE header and footer. This will only work with the restricted set of compatible themes.

[noahtallen]

I noticed a similar issue if you have the front page set to "Show Latest Posts" (the default page on the 2019 theme.) Is that page also dynamically rendered by themes or is that a separate case?

[vindl]

To expand a bit on the previous comment and try to advocate for one of the options - I think that we should move away from option 1 (hijacking in plugin) and override the the template part areas in child theme's header.php and footer.php instead.

This should help decouple some of the required plugin and theme functionality. It should allow us to build new child or even parent themes that support FSE more easily, and not necessarily require changes in the plugin to accommodate each one of them.

The above holds true as long as the header and footer template parts that plugin creates by default structurally match what given theme expects or requires to replicate its design. Otherwise, in order to handle separate themes with different header structure/content, the plugin will have to provide and pre-populate those alternative CPTs too and use them for rendering based on the theme that's currently active.

I think the above is less then ideal because of coupling between plugin and theme functionality - building a theme with different header structure will require modifying to plugin to store it. I'm open to other suggestions for better ways to solve it, and delegate all of these concerns to themes instead of the plugin. I would also consider the above solution as a short-term compromise to get to a working version faster.

[vindl]

One thing that occurred to me in the meantime - currently the plugin is responsible for creating the default template CPTs which are then used during for rendering template part content.

We could instead just keep the CPT and taxonomies registration in the plugin and provide a default fallback there, and leave the option for themes to populate the actual content of the header and footer by creating and populating their own versions of template part CPTs . 🤔

That way themes could override the default header and footer that's now provided by FSE, and introduce arbitrary changes to their structure while keeping the plugin intact.

[apeatling]

I noticed a similar issue if you have the front page set to "Show Latest Posts" (the default page on the 2019 theme.) Is that page also dynamically rendered by themes or is that a separate case?

This is also a dynamic page, unless you create a static "Blog Posts" page and assign that to show latest posts.

[apeatling]

@vindl We have a whole load of page templates that we store on WordPress.com right now, should we be storing all the different header and footer templates in the same fashion? I don't think they should be stored in the plugin or in the theme.

That way we don't have to modify the plugin at all. If I am not way off base, it's then the job of headstart to make sure they get the right header template populated in signup. We'd still need to make sure that on theme switch the correct header template is pulled and used depending on what the theme has asks for.

@michaeldcain Interested in your thoughts on this.

[vindl]

_Note_: I'll use Header in the following text to make things easier, but everything should be applicable to arbitrary template parts. In this context the _Header_ refers to an instance of wp_template_part CPT.

@vindl We have a whole load of page templates that we store on WordPress.com right now, should we be storing all the different Header and footer templates in the same fashion?

I think those are stored globally, and our Header is stored on per-site basis in wp_template_part CPT. I don't think we should move away from this scheme, given that we want to allow users to make arbitrary changes to Header in Gutenberg on per site basis (note that page templates get this for free because they are saved in post_content, which we must avoid).

I don't think they should be stored in the plugin or in the theme.

I definitely agree that we should move away from storing the Header content in the plugin. However, I think that having themes be responsible for providing it could be beneficial in multiple ways.

1. We can delegate Header CPT data setup that's now handled by the plugin to each theme that will support FSE and execute it on after_switch_theme hook (on theme activation).
2. Depending on how things are set up on Dotcom, this might remove the need to do anything with Headstart (need to verify this).
3. This will work for any self-hosted and Jetpack site, which is not the case if we rely on Headstart which is Dotcom specific (or some global storage on Dotcom). I know this is not an immediate priority or concern but if we get it for free - why not.
4. We avoid bloating the plugin with Header variants for each supported theme, and introducing undesirable coupling between the plugin/Headstart and the themes.
5. Switching to different theme that supports FSE on Dotcom is handled out of the box - after the switch, the theme is immediately set up with its default content, and not the one that will be carried over from previous theme (with any custom modifications) that might be completely unsuitable for the new one.
6. Each theme can still provide multiple variants of the Header during its initialization steps.

Unless I'm missing something, I think the above makes sense because it provides maximum flexibility to theme developers in terms of what they can insert in the Header - we can't expect to predict the needs of all the different themes with a limited set of shared variants.

This should make theme development easier too - creating a new theme with current setup will unavoidably entail some plugin and Headstart modifications, which is bad because we have to update code in multiple repositories. With the new approach, all of the required changes to ship a new theme will be contained to theme repo.

[vindl]

The fix for this issue along with the PoC of the approach described above is available in:
https://github.com/Automattic/wp-calypso/pull/34640
https://github.com/Automattic/themes/pull/1062