Editor: Operate on template CPT posts and add a default template with post title and content blocks.

[epiqueras]

cc @youknowriad

Closes #16281

Description

This PR builds on @aduth 's work on #16402 to add backwards compatible support for making the editor operate on and persist to template CPT posts instead of the actual edited post.

It adds a single, default, editable template to the "post" post type which contains a new post-title block, which persists to the edited post's title, followed by a new post-content block, which persists to the edited post's post_content. Note that this post-content block produces no markup on save so that the template only stores the location of post-content relative to the other blocks in the template. When the template is rendered by a theme, either explicitly or dynamically like in #4659, a render callback for the block could fill in the viewed post's content.

Future work will be needed to allow users or theme authors to create a template hierarchy and apply them to specific posts.

How has this been tested?

Posts were edited and saved and it was verified that the template updated correctly when making changes outside of the post-content block, as well as the title for the post-title block, and the content for the post-content block.

Screenshots

Types of Changes

New Feature: Operate on template CPT posts and add a default template with post title and content blocks.

Checklist:

• My code is tested.
• My code follows the WordPress code style.
• My code follows the accessibility standards.
• My code has proper inline documentation.
• I've included developer documentation if appropriate.

[aduth]

Is there an intermediate step where we refactor what exists today in editing the title and content to blocks, and leave the work with templates custom post type as a future iteration?

[aduth]

I might think to call this property, particularly if we just consider the post an object from which we're picking property values. Also avoids ambiguity on block attributes.

[epiqueras]

I went with attributes because all the selectors use "post attributes" as the terminology.

[aduth]

I went with attributes because all the selectors use "post attributes" as the terminology.

Hmm, that's fair. In retrospect I think they might have been more canonically referred to as properties of the post, but I'm fine targeting consistency if even for consistency's sake.

[epiqueras]

Yeah I like "properties" more too.

[epiqueras]

Is there an intermediate step where we refactor what exists today in editing the title and content to blocks, and leave the work with templates custom post type as a future iteration?

I could remove the persistence to the template CPT post, but don't you think it's pretty trivial?

[youknowriad]

@epiqueras I don't really think persistence is trivial. There's a lot of unanswered questions:

• How do themes define these templates
• Can we assign a persisted and a theme template (file)?
• How do they relate to the template hierarchy, and how to show them in frontend?
• What does it mean to save a "draft"? Do we update the template and save the post as a draft or both as a draft? What about scheduling?

[epiqueras]

@youknowriad Right, these are all the right questions. What I meant is that it's trivial in the way that it's implemented in this PR and all those questions can be solved/answered by building on top of this. Currently, the fact that it is even persisted, is just an implementation detail. We still only care about what is saved to post.post_content and post.title in the front end.

I think we should also discuss the vision for how we'll answer those questions. This is what I have in mind:

How do themes define these templates

Using a registerBlockTemplate PHP API.

Can we assign a persisted and a theme template (file)?

Yes, but the persisted one should take precedence like in #4659.

How do they relate to the template hierarchy, and how to show them in frontend?

We should take the approach taken in #4659 and also allow for template files to explicitly render persisted templates through a simple function call in the file.

What does it mean to save a "draft"? Do we update the template and save the post as a draft or both as a draft? What about scheduling?

Both as a draft, same for scheduling. I think this makes the most sense as you are editing everything at the same time.

To support a different approach we would have to redesign the interface to clearly differentiate between when you are selecting/editing a template block and a post content block and provide two different save buttons. Doing this in a user friendly and not clunky way will be hard.

[epiqueras]

Ran

$ git rebase --onto master ac70c2f3c6f61a458f03f0739f95048da5ad7ea9 try/expanding-the-editor-outside-post-content

and changed the base of this PR to master because #16402 was merged.

[aduth]

Can you clarify: For custom post types which register their own template, does this pull request change so that suddenly they'll start storing a new wp_template custom post type when saving the post?

[epiqueras]

Can you clarify: For custom post types which register their own template, does this pull request change so that suddenly they'll start storing a new wp_template custom post type when saving the post?

That would be one of the next steps.

[epiqueras]

There was actually an incompatibility with the current template format, but it's fixed here now:

5afab34 Editor: Keep compatibility with current template format.

[epiqueras]

I think I found a better approach for this. Closing for now.

[epiqueras]

Reopened in #16565