Introduce concept of block templates for full site editing #17512
Description
Based on ideas previously explored in #3588 (and PR #4659) and recently discussed via @mtias in https://make.wordpress.org/core/2019/09/05/defining-content-block-areas/ (see also particularly this comment by @westonruter), let's further specify how today's paradigm of hard-coded theme template files can transition to enable full-site editing using blocks.
There are two major technical pieces needed for this:
- An infrastructure to store blocks outside regular post content (in "block templates") and load these templates based on the current context (e.g. query variables and the main
WP_Queryinstance). This issue is focused on introducing said infrastructure. - Block types to cover the minimum requirements, both functionally and semantically, to cover what is currently handled by theme template files. These necessary block types are discussed via Suite of Post Blocks #15623 (and explored in PRs like Add Site Title block and required functionality. #17207 and Editor: Introduce a new dynamic templates mode and add basic post title and content blocks. #17263).
Based on these two pieces, several UI decisions need to be made on how to expose these features to the user, and we will likely need some iterations to get this right. While we'll out of necessity probably touch on some of those ideas here, I suggest we focus on finding a solid under-the-hood solution first.
Here's the concrete suggestion:
- Introduce a post type
wp_template, of which each post represents a single top-level template. In other words, a template that renders an entire page's markup (to be differentiated from so-called template parts). - Fully maintain the existing template hierarchy, which is currently used to determine which theme
/*.phptemplate file to load. Basically, eachwp_templatepost represents a specific one of those template files. - Provide a basic skeleton taking care of printing the non-visual markup (
<html>,<head>,wp_headhook,<body>opening and closing tag, etc.). Visually, it will render the actual blocks from the current template. - Skip the templates provided by themes entirely, since a hybrid approach would present unnecessary obstacles and confuse the user. Since this will drastically change how themes need to be developed, let's put it behind an experimental flag for now. Eventually, it could possibly become something that requires explicit
add_theme_support(), at least in a transitional phase.
Based on this, a few further thoughts:
- We will also need a way to reuse certain "template parts". This could be accomplished with e.g. the existing reusable blocks feature, or a separate post type
wp_template_part, or an alternative variant of reusable blocks that only applies to template content (i.e. not individual post content, for better separation). - WordPress theme developers are typically familiar with the template hierarchy, and thus will easily be able to understand the block-based version of it. Given that the necessary block types are present, porting existing templates over will be trivial.
- For the eventual UX, we probably should not expose template identifiers (such as
index,category,singular,single-product, etc.) to the user because these are rather technical. While every theme developer has been exposed to them, they have (for a reason) never been used in WordPress UI. We will need to find a solid way for a user to understand which template they are editing, and for them to decide in which context/scope they'd like to edit the template. For an initial (experimental) implementation, it's fine to just expose block templates with these names. - We also need to think about how themes can provide default block templates. A theme could for example provide general layouts to choose from when creating a new
wp_templatepost. Or it could include default block content (in place of today's template files) to use even if no user-created variant of that template exists as awp_templatepost. Or on theme activation, thesewp_templateposts could be automatically created. - Developing a theme will be greatly simplified by this methodology. A theme will be responsible for the style and default layouts/templates, and most likely also it will still control some level of user-facing customization options (whether using the Customizer or an alternative interface). However, several other theme features today will become obsolete. In a block-based world, something like
custom-header, widget areas, or nav menu locations probably don't make sense anymore. Other "features" like adding theme support fortitle-tagcould potentially be automatically enabled.