Feature: Set editor rendering mode by post type

[TylerB24890]

What?

Related Issue & PR:

• Add an option to change default renderingMode of Post Editor #58038
• Move default redering mode setting to block_editor_settings_all hook in PHP to allow customizing it #61844

This PR adds a filterable default_rendering_mode property to the WP_Post_Type object allowing users to define the default rendering mode for the editor for that post type.

The default_rendering_mode property can be added to the arguments when registering the post type via register_post_type() and can be overwritten using the available filters:

• post_type_{$post_type}_default_rendering_mode: To target an individual specific post type.

/**
 * Filters the block editor rendering for a specific post type.
 *
 * The dynamic portion of the hook name, `$post_type->name`, refers to the post type slug.
 *
 * @param string       $rendering_mode The current rendering mode set with the post type registration.
 * @param WP_Post_Type $post_type      The current post type object.
 */
$rendering_mode = apply_filters( "post_type_{$post_type->name}_default_rendering_mode", $post_type->default_rendering_mode, $post_type );

• post_type_default_rendering_mode: To target all (or multiple) post types.

/**
 * Filters the block editor rendering for a post type.
 *
 * @param string       $rendering_mode  The current rendering mode set with the post type registration.
 * @param WP_Post_Type $post_type_name  The current post type object.
 */
$rendering_mode = apply_filters( 'post_type_default_rendering_mode', $post_type->default_rendering_mode, $post_type );

Why?

Currently there is no way to set the default rendering mode of the block editor. You can select the mode while in the block editor, but upon refreshing that mode is reset back to the default post-only. With this update developers have more control over the editing experience and provides a means of setting the default view for the block editor.

How?

The linked PR has a discussion that mentions this setting should be applied at the post type level, allowing for a difference editing mode per post type. This PR applies the default_rendering_mode property to the WP_Post_Type object itself and provides multiple ways of overriding or setting the default for a custom (or core) post type.

Testing Instructions

1. Create a new post post type and observe the default editor UI.
2. In your functions.php file (or similar) use one of the available filters to set the default_rendering_mode property to template-lock:

add_filter(
    'post_type_default_rendering_mode',
    function () {
        return 'template-lock';
    }
);

3. Refresh the post editor and confirm you are now seeing the Template UI instead of the default Post UI.
4. Create a new page post and confirm the page editor also loads with the Template UI.
5. Update the filter in functions.php to target only the page post type:

add_filter(
    'post_type_page_default_rendering_mode',
    function () {
        return 'template-lock';
    }
);

6. Reload the page editor and confirm it still renders the Template UI.
7. Refresh the post editor and confirm it now renders the default Post UI.
8. Update the filter in functions.php to set the rendering mode for the post and page post types, but no others:

add_filter(
    'post_type_default_rendering_mode',
    function ( $mode, $post_type ) {
        if ( 'page' === $post_type || 'post' === $post_type ) {
            return 'template-lock';
        }

        return $mode;
    },
    10,
    2
)

9. Register a custom post type using register_post_type and set the default_rendering_mode parameter to template-lock:

register_post_type(
    'my_custom_type',
    [
        'show_in_rest'           => true,
        'supports'               => [ 'title', 'editor' ],
        'default_rendering_mode' => 'template-lock',
    ]
);

10. Visit the editor for your custom post type and confirm it loads with the Template UI.
11. Visit the Site Editor and select Pages in the left navigation.
12. Select a page and confirm it loads with the Template view (if the code from step 8 is still in place).
13. Change the filter value from step 8 to output post-only and refresh the Site Editor.
14. Confirm the Page now loads with the Post Content instead of the template UI.

[fabiankaegy]

Thanks for you work on this @TylerB24890 🚀

This is working exactly as I hoped it would. :) I left some minor notes and will request some additional reviews :)

[youknowriad]

This is looking very good to me. I'd appreciate broader review as well. @jameskoster @jasmussen @mcsf

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: TylerB24890 <tyb@git.wordpress.org>
Co-authored-by: fabiankaegy <fabiankaegy@git.wordpress.org>
Co-authored-by: youknowriad <youknowriad@git.wordpress.org>
Co-authored-by: ramonjd <ramonopoly@git.wordpress.org>
Co-authored-by: mcsf <mcsf@git.wordpress.org>
Co-authored-by: jasmussen <joen@git.wordpress.org>
Co-authored-by: annezazu <annezazu@git.wordpress.org>
Co-authored-by: jameskoster <jameskoster@git.wordpress.org>
Co-authored-by: dinhtungdu <dinhtungdu@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[ramonjd]

This is working great for me for what it's worth. Nice addition.

I also checked what would happen if I logged in as an Author with template-locked enabled - it activates the "Show template" option 👍🏻

Just left a comment about value checking, though even if it's a valid remark, I don't think it should block the first version of this.

[jasmussen]

Nice PR. Took it for a quick spin. In a very superficial test—this could use broader opinions—this seems to work as intended. If I change the default post-editor rendering mode to show templates, it does:

Otherwise it still shows the current default:

I think of these defaults as valid user settings to set as well at some point, user settings that are reasonable to persist, so if we add this, it would be good that a future user-setting could also unset whatever a plugin or theme might do. I.e. if my theme sets my page editor to omit the template preview, but I really prefer editing with that, I should be able to override that in my user settings. Make sense?

[fabiankaegy]

@jasmussen Agree that there should also be a user setting for this :) We can look into that as follow up 👍

[jasmussen]

Not necessarily urgent, IMO, just something to consider for the technical review!

[youknowriad]

Any reason for separating the two useSelect calls?

[TylerB24890]

Nope! I've merged them now 🙂

[youknowriad]

At the moment, the defaultRenderingMode for pages is "post-only", I guess we should make the update to "template-locked" as discussed above.

[youknowriad]

Can we use post.type here, it seems it's the only thing we need.

[TylerB24890]

All set!

[youknowriad]

Would love some help testing this properly. (Maybe @fabiankaegy if you find some time) but this is looking good to me.

[annezazu]

@WordPress/outreach for anyone who can help test and review this PR ❤️

[ramonjd]

This is working well for me 🎉

If @fabiankaegy is happy that it satisfies #58038 then I suppose the next step is the accompanying Core patch?

Happy to help test that as well. Cheers!

[ramonjd]

Not a blocker, just a question - I'm assuming that this will be wp_rendering_modes or rendering_modes when it eventually makes it to Core.

What about making the name be more specific, e.g., gutenberg_post_type_rendering_modes or even gutenberg_get_post_type_rendering_modes?

[TylerB24890]

That's a good question, and I assume you're correct about it being renamed to wp_rendering_modes in Core.

I think it makes sense to prefix it with post_type_ so the final function would be wp_post_type_rendering_modes()

I'm also not opposed to using get_ in the prefix, if the general that's the general consensus. In the meantime I've updated it to use gutenberg_post_type_rendering_modes() -- happy to update again if necessary!

[fabiankaegy]

For me this is exactly doing what I had in mind and testing perfectly! :)

I'm not sure about the failing tests though. They don't seem to be related but I'm not sure.

@youknowriad would love to get your eyes on that if you have a moment <3

[youknowriad]

I looked at this earlier today, and it's good to ship to me as well.

I think tests are somewhat stable these days, so if restart (or rebasing) doesn't really fix them than there must be a relationship with this PR.

I think the switch to "template by default" for pages is probably impactful for e2e tests for instance.

[ramonjd]

I've kicked off the tests again. 🤞🏻 🤞🏻 🤞🏻 🤞🏻

The final thing to do is create a Core backport PR.

See: https://github.com/WordPress/gutenberg/blob/trunk/backport-changelog/readme.md

Getting a draft PR up would be enough, and then I think the CI tests will be happy and the discussion about how to integrate into Core can move there.

Thanks a lot!