Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
wants to merge 12 commits into
base: add/site-title-block
from

Conversation

@epiqueras
Copy link
Contributor

commented Aug 29, 2019

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

Screen Shot 2019-08-29 at 4 14 04 PM

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.
function render_block_core_post_title() {
rewind_posts();
the_post();
return the_title( '<h1>', '</h1>', false );

This comment has been minimized.

Copy link
@westonruter

westonruter Aug 31, 2019

Member

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?

This comment has been minimized.

Copy link
@westonruter

westonruter Aug 31, 2019

Member

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

This comment has been minimized.

Copy link
@epiqueras

epiqueras Aug 31, 2019

Author Contributor

Perhaps this should behave like the Heading block where you can pick from among the heading levels. There could be an 鈥渁uto鈥 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 Show resolved Hide resolved
array(
'post_type' => 'wp_template',
'post_name' => 'single-post',
'post_content' => '<!-- wp:post-title /--><!-- wp:post-content /-->',

This comment has been minimized.

Copy link
@westonruter

westonruter Aug 31, 2019

Member

Should the featured image be factored in here?

This comment has been minimized.

Copy link
@epiqueras

epiqueras Aug 31, 2019

Author Contributor

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.

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

This comment has been minimized.

Copy link
@westonruter

westonruter Aug 31, 2019

Member

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.

This comment has been minimized.

Copy link
@epiqueras

epiqueras Aug 31, 2019

Author Contributor

Yes, see #4659

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

This comment has been minimized.

Copy link
@westonruter

westonruter Aug 31, 2019

Member

Should the post not be provided as an argument?

This comment has been minimized.

Copy link
@epiqueras

epiqueras Aug 31, 2019

Author Contributor

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

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

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

This comment has been minimized.

Copy link
@felixarntz

felixarntz Sep 2, 2019

Member

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

This comment has been minimized.

Copy link
@epiqueras

epiqueras Sep 2, 2019

Author Contributor

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?

This comment has been minimized.

Copy link
@felixarntz

felixarntz Sep 9, 2019

Member

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.

This comment has been minimized.

Copy link
@epiqueras

epiqueras Sep 9, 2019

Author Contributor

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

This comment has been minimized.

Copy link
@felixarntz

felixarntz Sep 13, 2019

Member

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.

This comment has been minimized.

Copy link
@epiqueras

epiqueras Sep 13, 2019

Author Contributor

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

This comment has been minimized.

Copy link
@westonruter

westonruter Sep 14, 2019

Member

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.

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

This comment has been minimized.

Copy link
@felixarntz

felixarntz Sep 2, 2019

Member

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.

This comment has been minimized.

Copy link
@epiqueras

epiqueras Sep 2, 2019

Author Contributor

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.

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

This comment has been minimized.

Copy link
@felixarntz

felixarntz Sep 13, 2019

Member

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).

This comment has been minimized.

Copy link
@epiqueras

epiqueras Sep 13, 2019

Author Contributor

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

This comment has been minimized.

Copy link
@felixarntz

felixarntz Sep 15, 2019

Member

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.

This comment has been minimized.

Copy link
@epiqueras

epiqueras Sep 15, 2019

Author Contributor

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

This comment has been minimized.

Copy link
Member

commented Sep 16, 2019

@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 epiqueras force-pushed the add/site-title-block branch from 5107ba2 to 009c304 Sep 16, 2019

@@ -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.

This comment has been minimized.

Copy link
@epiqueras

epiqueras Sep 16, 2019

Author Contributor

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

This comment has been minimized.

Copy link
@epiqueras

epiqueras Sep 16, 2019

Author Contributor

@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.

@epiqueras epiqueras force-pushed the add/template-and-post-blocks branch from 48e9d97 to 6832752 Sep 16, 2019

@epiqueras epiqueras force-pushed the add/site-title-block branch from 009c304 to ef1b9d6 Sep 16, 2019

@epiqueras epiqueras force-pushed the add/template-and-post-blocks branch from 6832752 to 24e7a1f Sep 16, 2019

Merge branch 'add/template-and-post-blocks' of github.com:WordPress/g鈥
鈥tenberg into add/template-and-post-blocks
felixarntz added 3 commits Sep 18, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can鈥檛 perform that action at this time.