Editor: Introduce a new dynamic templates mode and add basic post title and content blocks. #17263

epiqueras · 2019-08-29T23:20:56Z

Depends on #17207

Description

This PR implements a new custom post type for implementing a dynamic template hierarchy like in #4659. Then it makes a few changes to the editor store to load in a "template mode" when it detects that the current post has an attached template.

It also brings in the post title and post content blocks of #16565, but using the new declarative APIs introduced in #17153 and #17207.

All of this new functionality is enabled only when you enable the full site editing experiment in the experiments tab. This way we can iterate it on it, until it's ship-able.

If you try the experiment on this branch, you should see posts load in template mode where you can edit the top level template, the post title and content blocks, preview the post, etc, etc. Blocks have their own save buttons for now, until we design all the different save flows we should have and how they should interact with each other.

How has this been tested?

It hasn't 😬

Screenshots

Types of Changes

New Feature: Introduce a new dynamic templates mode and add basic 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.

westonruter · 2019-08-31T17:42:48Z

packages/block-library/src/post-title/index.php

+function render_block_core_post_title() {
+	rewind_posts();
+	the_post();
+	return the_title( '<h1>', '</h1>', false );


Shouldn't the heading level be variable? In a singular context, it should be h1. But on an archive context where there is more than one post in the loop, should it not be h2?

Perhaps this should behave like the Heading block where you can pick from among the heading levels. There could be an “auto” setting which does this, but which you could also override as desired.

Perhaps this should behave like the Heading block where you can pick from among the heading levels. There could be an “auto” setting which does this, but which you could also override as desired.

Yeah I like that.

This was more of a first step to get something on the screen. We need a major design effort to come up with how these new blocks will behave. See the questions at the end of this overview issue: #17284

lib/templates.php

westonruter · 2019-08-31T17:49:53Z

lib/templates.php

+			array(
+				'post_type'    => 'wp_template',
+				'post_name'    => 'single-post',
+				'post_content' => '<!-- wp:post-title /--><!-- wp:post-content /-->',


Should the featured image be factored in here?

If that's something we want in the default "post" post type template, sure.

This shouldn't be in Core or the plugin though. We should provide the framework and UI for users to create new templates, but default templates, if there are any, should be provided by themes.

westonruter · 2019-08-31T17:52:30Z

lib/templates.php

+	$template_query = new WP_Query(
+		array(
+			'post_type' => 'wp_template',
+			'name'      => 'single-post',


Naturally, this logic will need to be fleshed out with looking up the specific template for a given post. For example, if editing a movie post type, it should look for single-movie before single. And if single does not exist, then singular, and so on.

Yes, see #4659

westonruter · 2019-08-31T17:53:48Z

packages/block-library/src/post-content/index.php

+ */
+function render_block_core_post_content() {
+	rewind_posts();
+	the_post();


Should the post not be provided as an argument?

Not really, this block renders whatever post its context dictates.

We do need to add support for pages with multiple posts/post blocks.

felixarntz · 2019-09-02T08:16:25Z

packages/block-library/src/post-content/index.php

+function render_block_core_post_content() {
+	rewind_posts();
+	the_post();
+	return apply_filters( 'the_content', str_replace( ']]>', ']]&gt;', get_the_content() ) );


Should this not receive a wrapping element (like many themes put a div.entry-content around it)?

Yeah, I've seen that, but I'm not very familiar with everything it's used for.

Is that something we should hardcode or expect themes to add it in a filter?

I think we would need to align on a wrapping div with a certain class name. I assume based on what I've seen, one of the most common classes used for this is entry-content. An alternative would be to use a typical block class, e.g. wp-block-post-content.

This leads to a broader discussion on how the class naming scheme of Gutenberg should evolve when it comes to entire templates. Is the wp-block-... naming sufficient, should it expand to template blocks as well? Or should we constrain the typical block classes to in-content blocks and define a set of more traditional class names?

Finding a consistent solution here is crucial for themes styling Gutenberg templates.

We'll probably have to use entry-content for backwards compatibility.

I think that depends on whether we can get the approach in its entirety to be backward-compatible or not. I think a site-wide block based editing experience will require massive changes in how themes are developed either way. It shouldn't break existing themes, but I think certain features would just not be supported with an old theme.

Yeah, but keeping it as entry-content wouldn't hurt.

Yes, any existing class names from Microformats should be preserved, as they relate to semantics. And entry-content is one such example from hAtom. Use of such legacy Microformats should not preclude using Schema.org microdata.

felixarntz · 2019-09-02T08:26:18Z

packages/block-library/src/post-content/edit.js

+				onInput={ useCallback( () => {
+					setContent( ( { blocks: blocksForSerialization = [] } ) =>
+						serializeBlocks( blocksForSerialization )
+					);


Not a concern with this code, but I'm curious how this would translate to an archive context. It absolutely makes sense to start with the single post context for this exploration, and in that context combining editing of the template blocks and post blocks should work fine. But once we get to a place where there are multiple posts in one page (and the list would change over time), the UI might fill up quite a bit. This could be reduced by some kind of "zoom-in" mode where post content is mostly hidden and can be expanded on click and/or with a link to "edit this specific post" (I believe this was considered before somewhere). Another consideration might be performance - having blocks from let's say 10+ posts (plus the template blocks) in one view could be a lot, especially when assuming most people would only use the archive view for editing the template, but not individual posts.

Yeah, if the editor is not operating on a single post, the post block can easily infer that from useEntityId returning undefined, and bail out of loading anything, showing a placeholder instead.

felixarntz · 2019-09-13T13:11:22Z

packages/block-library/src/post-title/edit.js

+const saveProps = [ 'title', 'slug' ];
+export default function PostTitleEdit() {
+	const [ title, setTitle ] = useEntityProp( 'postType', 'post', 'title' );
+	const [ , setSlug ] = useEntityProp( 'postType', 'post', 'slug' );


The hard-coding of post here is probably just temporary, but we need to figure out a way to do it right, since currently this only works for posts of post type 'post' and causes an error on other post types.

The problem is that the overall current post being edited appears to be overridden by this implementation, causing getCurrentPost() to return the wp_template instead of the actual post being edited. Otherwise we could have used withSelect() to get the current post type, but that wouldn't work.

I'm a bit wary of overriding the current post context in Gutenberg to become a wp_template post when actually editing a "real" post, since it could break expectations by other plugins. We should probably think about a way we expose the current wp_template through a set of new API functions (e.g. getCurrentTemplate() etc.), where we could transform the editor accordingly based on whether these include a wp_template post or not (if not, it would be just like today).

The editor already supports editing multiple post types and the editor store has a getPostType selector.

Are you referring to getCurrentPostType()? It still returns wp_template here when I use it. How do I get the post type of the actual post being edited? It's hard-coded to post here, so we need to replace it with a function that dynamically gets the correct post type.

Sorry, I thought you were asking how to get the post type of the template. (The template is the actual post being edited after all.)

You can get the post that uses the template through editor settings:

const { postId, postType, templateId } = getEditorSettings()

felixarntz · 2019-09-16T18:24:03Z

@epiqueras I made two more small changes:

Wrap core/post-content into div.entry-content as discussed.
Put in a (temporary) fix for a possible infinite loop. This is not a proper solution, and we might need to find a better way to fix it. I haven't been able to dig to its roots, but basically the block parser continues to iterate the wp_template endlessly when processing the content in a REST API request (which also happens during admin initialization because of preloading).

epiqueras · 2019-09-16T18:47:52Z

packages/block-library/src/post-content/index.php

@@ -11,6 +11,11 @@
 * @return string Returns the filtered post content of the current post.
 */
 function render_block_core_post_content() {
+	// TODO: Without this temporary fix, an infinite loop can occur.


Let's add inline comments as to how this fixes the infinite loop and why it occurs.

@felixarntz

Put in a (temporary) fix for a possible infinite loop. This is not a proper solution, and we might need to find a better way to fix it. I haven't been able to dig to its roots, but basically the block parser continues to iterate the wp_template endlessly when processing the content in a REST API request (which also happens during admin initialization because of preloading).

Interesting, are you sure you didn't have nested post content blocks?

What are the repercussions of this fix. Will returning an empty string like this affect anything? If not, I guess we can keep it.

… selecting inside the callback.

epiqueras · 2019-10-24T19:15:57Z

It's all coming together:

https://youtu.be/HXClt6oNtcg

@youknowriad @felixarntz

youknowriad · 2019-11-12T09:27:39Z

@epiqueras Can we extract the post title and post content blocks from this PR into their own PR. These could be useful on their own to build templates in the temporary UI.

epiqueras · 2019-11-12T17:43:30Z

They can't really be tested without a template mode.

youknowriad · 2019-11-12T17:44:44Z

@epiqueras How so, I mean their "edit" version can't but their "placeholder" version and frontend rendering are very useful even without the "template mode"

epiqueras · 2019-11-12T17:47:21Z

Most of their code is the edit part though, and it would be strange to merge that in a PR where you can't test it and it could be completely broken.

youknowriad · 2019-11-12T17:49:01Z

I get that and maybe we can leave that part for this PR. That said, in several occasions, I found myself trying to see if I can build a block-based template and I don't really need the "edit" functions for this. I feel these two blocks are the missing pieces to achieve a first raw block-based theme.

epiqueras · 2019-11-12T18:00:08Z

I can open a PR for that, but I'm worried that it will just encourage this one to go stale.

Unless, your idea is to postpone any sort of "mode" switching in the near future.

youknowriad · 2019-11-12T18:04:16Z

I think this one has still a lot of design considerations to be taken care of before landing while the other one seems easier. Also I think since it reduces the changes from this PR to the template mode, it will be easier to review and land.

epiqueras · 2019-11-12T18:32:32Z

@youknowriad that's fair. Here: #18461.

epiqueras · 2019-11-20T22:40:59Z

Closing this as it will be merged in more granular PRs.

epiqueras added [Package] Core data /packages/core-data [Package] Editor /packages/editor [Package] Block library /packages/block-library [Package] Block editor /packages/block-editor [Package] Edit Post /packages/edit-post labels Aug 29, 2019

epiqueras added this to the Future milestone Aug 29, 2019

epiqueras requested review from ajitbohra, ellatrix, jorgefilipecosta, nerrad, Soean, talldan, TimothyBJacobs and youknowriad as code owners August 29, 2019 23:20

epiqueras self-assigned this Aug 29, 2019

westonruter reviewed Aug 31, 2019

View reviewed changes

felixarntz reviewed Sep 2, 2019

View reviewed changes

epiqueras mentioned this pull request Sep 7, 2019

Overview: Custom Entity Sources #17368

Closed

felixarntz reviewed Sep 13, 2019

View reviewed changes

epiqueras force-pushed the add/site-title-block branch from 5107ba2 to 009c304 Compare September 16, 2019 18:42

epiqueras commented Sep 16, 2019

View reviewed changes

epiqueras force-pushed the add/template-and-post-blocks branch from 48e9d97 to 6832752 Compare September 16, 2019 18:59

epiqueras force-pushed the add/site-title-block branch from 009c304 to ef1b9d6 Compare September 16, 2019 19:05

epiqueras force-pushed the add/template-and-post-blocks branch from 6832752 to 24e7a1f Compare September 16, 2019 19:05

epiqueras requested review from adamsilverstein, atimmer, chrisvanpatten, daniloercoli and etoledom as code owners September 18, 2019 11:37

epiqueras and others added 6 commits October 23, 2019 17:00

Core Data: Ensure hook entity saving always uses the latest edits, by…

4231591

… selecting inside the callback.

Editor: Export block serialization utility.

61556d8

Block Library: Implement Post Title and Post Content Blocks.

f599c7e

Only rewind posts when necessary in post-scoped block types.

d5f5129

Wrap core/post-content into div.entry-content.

fc18beb

Temporary fix for infinite loop.

42d9b6d

epiqueras force-pushed the add/template-and-post-blocks branch from 89db348 to 42d9b6d Compare October 24, 2019 00:01

epiqueras changed the base branch from add/site-title-block to master October 24, 2019 00:04

epiqueras added 4 commits October 23, 2019 17:41

Block Library: Change old block categories.

e2cdc43

Block Library: Update deprecated props and APIs.

de2b90e

Template Loader: Add the hijacked template ID to the editor's settings.

b1b0d4a

Editor: Introduce editing modes and support the new template loader.

3c29e6d

etoledom removed request for TimothyBJacobs, ellatrix, etoledom and jorgefilipecosta November 7, 2019 06:38

epiqueras mentioned this pull request Nov 12, 2019

Block Library: Add Post Content and Title Blocks. #18461

Merged

6 tasks

epiqueras closed this Nov 20, 2019

youknowriad deleted the add/template-and-post-blocks branch November 21, 2019 08:19

epiqueras mentioned this pull request Nov 26, 2019

Block Editor: Enable entity-synced inner blocks. #18739

Closed

6 tasks

Editor: Introduce a new dynamic templates mode and add basic post title and content blocks. #17263

Editor: Introduce a new dynamic templates mode and add basic post title and content blocks. #17263

Conversation

epiqueras commented Aug 29, 2019 • edited Loading

Description

How has this been tested?

Screenshots

Types of Changes

Checklist:

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

felixarntz commented Sep 16, 2019

Choose a reason for hiding this comment

Choose a reason for hiding this comment

epiqueras commented Oct 24, 2019

youknowriad commented Nov 12, 2019

epiqueras commented Nov 12, 2019

youknowriad commented Nov 12, 2019

epiqueras commented Nov 12, 2019

youknowriad commented Nov 12, 2019

epiqueras commented Nov 12, 2019

youknowriad commented Nov 12, 2019

epiqueras commented Nov 12, 2019

epiqueras commented Nov 20, 2019

epiqueras commented Aug 29, 2019 •

edited

Loading