Add ability to set default rendering mode per 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 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 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}_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->name}_default_rendering_mode", $post_type->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 string $post_type_name  The current post type name
 */
$rendering_mode = apply_filters( 'post_type_default_rendering_mode', $post_type->rendering_mode, $post_type->name );

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 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 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(
    '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 rendering_mode parameter to template-lock:

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

10. Visit the editor for your custom post type and confirm it loads with the Template UI.
11. Remove the rendering_mode argument from your post type registration & confirm the editor now loads with the default Post UI.

[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 <[email protected]>

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

[github-actions]

Warning: Type of PR label mismatch

To merge this PR, it requires exactly 1 label indicating the type of PR. Other labels are optional and not being checked here.

• Type-related labels to choose from: [Type] Automated Testing, [Type] Breaking Change, [Type] Bug, [Type] Build Tooling, [Type] Code Quality, [Type] Copy, [Type] Developer Documentation, [Type] Enhancement, [Type] Experimental, [Type] Feature, [Type] New API, [Type] Task, [Type] Technical Prototype, [Type] Performance, [Type] Project Management, [Type] Regression, [Type] Security, [Type] WP Core Ticket, Backport from WordPress Core.
• Labels found: .

Read more about Type labels in Gutenberg. Don't worry if you don't have the required permissions to add labels; the PR reviewer should be able to help with the task.