Post editor: Provide a way to view the template while editing a post

[jameskoster]

In some situations a user may wish to zoom out to see how the contents of the post they are editing will sit inside the broader page template.

This is different to a static preview as the contents of the post should remain editable. It is also different (albeit related) to editing the template (https://github.com/WordPress/gutenberg/pull/26355), because the content remains the focus, and editing the blocks that comprise the template should be restricted (https://github.com/WordPress/gutenberg/issues/27848).

[jameskoster]

Here's a simple design that would enable a user to toggle the template into view whilst editing a post or page:

Re-labelling the "Preview" button to "View" seems sensible since the options therein are more than mere previews. Whether you're in desktop, tablet, or mobile view, and regardless of the template is visible or not, you are always able to directly manipulate the canvas contents. This subtle label change will create greater flexibility in terms of what sort of options we might put in this menu in the future. Another option that might live here could be entity switching while editing a template, which is also a requirement of #27814.

I'd love to hear any input on the animations here, I'm not sure how feasible it would be to relocate the post content this way? It would however seem beneficial to do so if possible, so that you always keep track of what is post content and what is part of the template as it comes in to view. Or perhaps there are other ways to do this that do not involve animation?

[kellychoffman]

The animation is nice but I think its doing a lot of heavy lifting to primarily communicate what is happening. I think it would be clearer if it was more in context with the template dropdown. This way, the user can quickly make the connection of picking a template for their post and seeing what the post will look like in that template. It will also make the animation a nice addition instead of a must have.

[jameskoster]

I think it would be perfectly reasonable to try this without the animation to begin with. I may be entirely unfounded in my assumption that keeping visual track of the content is important in this flow.

[kellychoffman]

I think the animation is important and aids in the flow. I was only wary of solely relying on it to communicate something.

[jameskoster]

Gotcha. It may be worth ideating on a more generic loading state, as the template itself would need to be fully loaded before an animation like above could be executed.

[youknowriad]

I shared my opinion on a different PR but I wanted to just add it here. Personally I feel this is not necessary because it's not very different from the edit mode itself, the distinction of the number of modes we're adding can become too difficult to understand for the user. We'd need ways to differentiate visually the different modes and sometimes the best way to do something is to avoid doing it :P

[jameskoster]

I would agree that we probably don't need it yet.

But I still see a use case for composing a post with the template visible around it. Essentially a preview that doesn't engage the template editor. It will be helpful for understanding how things like the Featured Image fit in with the content.

I believe this use case will become most apparent for less visually elaborate content executions. WooCommerce products are a good example – the display of the product data will likely be 90% driven by the template, with the content only making up a small section of that view:

In this case having the scope of the full template visible on the canvas will be particularly useful.

We can definitely revisit this later, or perhaps not at all :D

[steveangstrom]

In some situations a user may wish to zoom out to see how the contents of the post they are editing will sit inside the broader page template.

In my case this would be "Always". They will always want to "zoom out" and see the contents of the post in the page template, with all the styles, layout elements and graphical adornments. That's my clients base expectation, and they are annoyed when they don't get it.

Case Study. The clients I create sites for are decidedly non-technical, and also forgetful about instructions. They are companies with between 10 and 50 employees. The person tasked with updating the website is perhaps an intern, guided by a PDF instruction sheet. The person perhaps has very very limited technical aptitude.

What they tend to ask for is WYSIWYG : If the content is going to be displayed in a template they want to edit it in that same template. I get bitter complaints about it "looking different in the editor, I can't tell what it looks like"

The context menu item View/Layout/Show Template will mean nothing to them. It's dark arts sorcery talk.

What they expect as the standard experience is:

1: Create New Post 2: In Gutenberg page editor they see the default page styling, background graphics, sections and layout reflected in the editor, with the key elements such as the headline LOCKED in position, but editable, likewise the hero, body text, and any graphic elements, pull quotes, all LOCKED in position.
3: They edit the text areas, and put the pullquotes in where instructed to. 4: They decide they want this article to use the Magazine Layout which has been designed for them 5: They use the Template / "Layout" selector (To many clients the Design "Layout" is the way it's express, often being from a print mentality) 6: They use the Layout selector to choose "Magazine Layout" and the content is now displayed using a new template. The client can see in the editor that there are now prompts for sub-titles, credits, and more image boxes in position, and they fill those in.

This is a very loose description of how most clients edit a page, or wish to.

At the moment to deliver this I'm using a selection of hacks, content injections and workarounds.

[jameskoster]

I think this feature could also be a solution for https://github.com/WordPress/gutenberg/issues/29821.

When you go to edit the page that is set to display latest posts, the layout toggle could be automatically enabled, and perhaps it would not be possible to hide the layout for this special use case where you're effectively editing the underlying template.

We can potentially re-use that pattern for when the homepage is configured to display latest posts, effectively giving folks a way to visually modify that "page" for the first time.

[jameskoster]

In https://github.com/WordPress/gutenberg/issues/39281 the idea of a layout toggle came up again.

https://user-images.githubusercontent.com/846565/170048479-e215dff1-8b94-46b0-a09a-4923fdcff662.mp4

[spencerfinnell]

In some situations a user may wish to zoom out to see how the contents of the post they are editing will sit inside the broader page template.

In my case this would be "Always". They will always want to "zoom out" and see the contents of the post in the page template, with all the styles, layout elements and graphical adornments.

I agree with this as well, at least for pages.

This is done automatically already in the specific scenario of using templates/front-page.html that includes the core/post-content block. If you click "Edit Site" the templates/front-page.html template is loaded as well as the full content of the designated static home page.

Editing the template itself, or the page content is clearly noted when saving:

I think having "Edit Page" in the admin toolbar open the Site Editor with the current page's template and data pre-populated would help remove distinction between the "Post Editor" and "Site Editor", as similarly described in https://github.com/WordPress/gutenberg/issues/41947. This would also be more inline with previous Customizer usage, where clicking "Customize" in the admin toolbar would open the Customizer on the current page.

Separating page content from the page template by default feels like a disservice to FSE. Currently a hybrid theme stands to be more flexible with PHP-based page templates that load a page's blocks via the_content();, while maintaining the same default editing experience FSE themes currently present when editing a page.

[spencerfinnell]

Here is a simple plugin to switch to template editing mode automatically when editing a page, but also introduces some wonkiness when toggling modes. It helps get a feel for what automatically showing both template and content might like though:

/**
 * WordPress dependencies
 */
import { registerPlugin } from '@wordpress/plugins';
import { store as editPostStore } from '@wordpress/edit-post';
import { store as editorStore } from '@wordpress/editor';
import { dispatch, select } from '@wordpress/data';

/**
 * Automatically load "template editing" mode when editing a page.
 */
registerPlugin( 'auto-edit-page-template', {
    render() {
        const postType = select( editorStore ).getCurrentPostType();

        if ( 'page' !== postType ) {
            return null;
        }

        dispatch( editPostStore ).setIsEditingTemplate( true );

        return null;
    },
} );

[jameskoster]

@spencerfinnell I don't know that we necessarily want to engage template editing mode, since it may be that content is locked there in the future. This issue is more about being able to see the template, but not edit it directly. If you have the capacity to put a PR together I think it would be excellent to try.

[fabiankaegy]

I just had a training session where I showed a first-time WordPress user how they can edit their template. They successfully went into the site editor. Selected the correct template and changed the page title block to be center aligned.

When they went back into a post they were working on they were confused and frustrated that apparently, the changes they had made were incorrect.

In this case I was able to show them that the change was in fact applying and had to explain that the post editor doesn't reflect the changes of the template directly. And that the page title on a single post needs to be though of as just a field to provide the title that has nothing to do with how the title will get displayed visually.

---

I think this is a very common occurrence and even I as someone that is working in both editors very very regularly didn't really have a great rationale I could share with the first time user for why it should work this way.

I think this is an important usability issue that we should consider more in our roadmap of making the entire site editable :)

[jameskoster]

I agree this is important, and while the solution suggested in this PR can work I'm thinking it might be better to concentrate on the site editor, particularly issues like https://github.com/WordPress/gutenberg/issues/44461.

The more pertinent UX issue then becomes making it clear and obvious which blocks are part of the template and which are part of the post.

[fabiankaegy]

@jameskoster I can see how it makes more sense to focus on reintroducing content editing in the site editing. In that case however I would really like us to pove forward with https://github.com/WordPress/gutenberg/issues/27093 remove the post title from the editor canvas. This would remove a lot of the confusion since the post content is always getting represented as it is being edited in the post editor since it is just one post-content block in the site editor.

Having the title dispalyed in the canvas when that doesn't actually match the visual presentation of the content is where the confusion is coming from :)

[annezazu]

In talking with @elmastudio, the topic of full page patterns came up, including wanting to see the header and footer when you're trying to insert a full page pattern. Without the header and footer showing, the full page pattern doesn't quite feel "full". In my mind, there's something that could be explored with this view where when you're trying to insert a full page pattern, you're able to do so while viewing the larger template at play. This is intentional vague as these designs and explorations are early but, with more of an emphasis on patterns, it felt worth connecting.

cc @WordPress/block-themers in case other folks have insights to share or want to emoji react with this for support.

[fabiankaegy]

@jameskoster After having spent some time chatting with @gziolo at Cloudfest, I do think that his issue should be prioritized again. Having content editing enabled in the site editor is geat. But it only actually affects a very small part of the userbase. Only Administrators even have access to enter the site editor. And most user accounts are not administrators but editors or other lower roles.

And these users currently have no way of actually getting the whole visual experience that shows them the template while editing the content. That is what this issue should be about.

And technically, we should have a lot of the places already in place. The contentOnly locking mechanism, the recent updates to the data API, which allows for different entities to be updated etc.

[jameskoster]

One tricky part still to figure out here is how certain template blocks behave when visible, post meta blocks for example. It might be a bit strange if you couldn't update the Featured Image via that block if it is visible on the canvas.

In that sense it's less about visibility alone, and more about how we delineate between template / content when both are visible.

Agree we have a lot of pieces to get this right, but it feels like a global concept we can apply in all editing contexts.

cc @SaxonF who has been thinking about this lately.

[fabiankaegy]

One tricky part still to figure out here is how certain template blocks behave when visible, post meta blocks for example. It might be a bit strange if you couldn't update the Featured Image via that block if it is visible on the canvas.

That is what I think the contentOnly locking would be perfect for. Essentially I think the behavior for any blocks that are part of the template but still related to the post like a featured image, meta etc should behave like when they are placed in a content only locking context. Where you cannot remove the block and most visual controls are removed. But you can change any attribute that has the __experimentalRole: "content" defined.

[jameskoster]

Oh I agree. We need to consider template-only blocks too, and how their interactions can serve as a pathway to template editing.

I suppose my underlying point is that we have this same requirement in both the site editor and the post editor. And that it would be a shame to implement divergent flows for each.

[SaxonF]

I suppose my underlying point is that we have this same requirement in both the site editor and the post editor. And that it would be a shame to implement divergent flows for each.

+1000000 . I think whatever we do should be stepping stones towards unification. A contentOnly locking experience is what we are exploring for the site editor.

https://user-images.githubusercontent.com/1072756/229383524-6577e101-9579-47ab-a1a7-cdf5c503a2e9.mp4

Having content editing enabled in the site editor is geat. But it only actually affects a very small part of the userbase. Only Administrators even have access to enter the site editor. And most user accounts are not administrators but editors or other lower roles.

This is almost a separate concern we need to be thinking about as the functionality of the site editor expands. Limiting the entire editor might not make sense anymore.

[fabiankaegy]

@SaxonF I'm really curious about your thoughts regarding the long-term vision for #41717. Is the plan to replace the post list, and the post editor entirely with the current site editor?

I opened a discussion #51938 that also tries to talk about this a bit more.

Currently, by only adding more and more features to the site editor I feel we are creating a confusing experience for users because there are multiple ways to get to a post list and single post edit screen.

And in it's current form the post editor especially for custom post types that have more intricate templates is really lacking because it breaks the WYSIWYG experience for users because it is very hard to see your content in context of the template. And since the site editor is currently still for adminstrators only, I think we should spend more focus on enhancing that experience for all the other roles :)

[annezazu]

Noting that with https://github.com/WordPress/gutenberg/pull/52674 merged, it would be interesting to explore how to bring this back into the Post Editor! cc @noisysocks @SaxonF @jameskoster

[annezazu]

We now have for block themes the ability to preview a template while working in a post or page with 6.5 beta 1 & 2 thanks to work done around unifying:

https://github.com/WordPress/gutenberg/assets/26996883/f86b35a7-851c-4d0c-9a66-1be5d0bf959e

Closing this out unless I'm missing something @jameskoster !

[spencerfinnell]

Great to see this in 6.5, however I still find the flow pretty cumbersome on sites where the majority of pages are powered by custom templates.

Until this setting is persisted (https://github.com/WordPress/gutenberg/issues/56270) my solution these days is to filter get_edit_post_link to open directly in the Site Editor with the page loaded vs. the Page editor.

/**
 * Opens pages in the site editor for editing.
 *
 * @param string $url URL to transform.
 * @param int $post_id Post ID.
 * @return string
 */
function edit_post_link( $url, $post_id ) {
    $post = get_post( $post_id );

    if ( 'page' !== $post->post_type ) {
        return $url;
    }

    return add_query_arg(
        array(
            'postType' => 'page',
            'postId' => $post_id,
        ),
        admin_url( 'site-editor.php' )
    );
}
add_filter( 'get_edit_post_link', __NAMESPACE__ . '\\edit_post_link', 10, 2 );

[Tchelet-Levi]

Great to see this in 6.5, however I still find the flow pretty cumbersome on sites where the majority of pages are powered by custom templates.

Until this setting is persisted (#56270) my solution these days is to filter get_edit_post_link to open directly in the Site Editor with the page loaded vs. the Page editor.

/**
 * Opens pages in the site editor for editing.
 *
 * @param string $url URL to transform.
 * @param int $post_id Post ID.
 * @return string
 */
function edit_post_link( $url, $post_id ) {
  $post = get_post( $post_id );

  if ( 'page' !== $post->post_type ) {
      return $url;
  }

  return add_query_arg(
      array(
          'postType' => 'page',
          'postId' => $post_id,
      ),
      admin_url( 'site-editor.php' )
  );
}
add_filter( 'get_edit_post_link', __NAMESPACE__ . '\\edit_post_link', 10, 2 );

You can also try enqueuing a small script on editor load that automatically sets the rendering mode to template preview.

Something like this maybe?

wp.data.dispatch('core/editor').setRenderingMode('template-lock')

Source: https://github.com/WordPress/gutenberg/blob/trunk/packages/editor/src/store/actions.js#L591

[taylorgorman]

Thanks for that script, @Tchelet-Levi. I had to wrap it in a function to detect when the editor is ready, which I got from this gist from @KevinBatdorf. Below is the code, which works for me. (Someone tell me if there's a native way to detect when the editor is ready; I couldn't find one. I'd love for __unstableIsEditorReady to become stable.)

/**
 * @see https://gist.github.com/KevinBatdorf/fca19e1f3b749b5c57db8158f4850eff
 */
function editorReady(callback) {
  return new Promise((resolve) => {
    const unsubscribe = wp.data.subscribe(() => {
      if (
        wp.data.select('core/editor').isCleanNewPost()
        || wp.data.select('core/block-editor').getBlockCount() > 0
      ) {
        unsubscribe()
        callback()
        resolve()
      }
    })
  })
}

/**
 * Default to show template on post edit
 * TO DO: Save setting when user changes and default to that.
 */
editorReady(function () {
  wp.data.dispatch('core/editor').setRenderingMode('template-lock')
})

[Tchelet-Levi]

Thanks for that script, @Tchelet-Levi. I had to wrap it in a function to detect when the editor is ready, which I got from this gist from @KevinBatdorf. Below is the code, which works for me. (Someone tell me if there's a native way to detect when the editor is ready; I couldn't find one. I'd love for __unstableIsEditorReady to become stable.)

What I do is I make sure that I have 'wp-dom-ready', 'wp-edit-post' as well as 'wp-data' as dependencies for my script when I enqueue it, then I use the wp.domReady() function to execute it after the DOM has loaded, knowing that the domReady function and the data API are available, and also that the Editor UI scripts have loaded.

function editor_enqueue_scripts() {
    wp_enqueue_script(
        'editor-script-js',
        plugins_url( 'editor_settings.js', __FILE__ ),
        array( 'wp-dom-ready', 'wp-data', 'wp-edit-post' ), // Dependencies.
        filemtime( plugin_dir_path( __FILE__ ) . '/editor_settings.js' )
    );
}
add_action( 'enqueue_block_editor_assets', 'editor_enqueue_scripts' );

// editor_settings.js

wp.domReady(() => {
  wp.data.dispatch('core/editor').setRenderingMode('template-lock');
});

I could be wrong about my approach, but it has worked fine for me so far. The idea comes from the Gutenberg docs.