Set editor rendering mode by post type

[TyB]

Sync ticket for ​https://github.com/WordPress/gutenberg/pull/62304

Allow extenders to set the default rendering mode for a specific post type. It seems logical to default the page post type to the template editor, and the post post type to the block editor. Editors should retain the ability to swap between them while in the editor, this setting should only apply to what the editor sees by default.

Extenders should have the ability to define the rendering mode for a post type on registration, and change the rendering mode of an existing post type through a filter.

# Trac ticket: https://core.trac.wordpress.org/ticket/61811

This Pull Request is for code review only. Please keep all other discussion in the Trac ticket. Do not merge this Pull Request. See ​GitHub Pull Requests for Code Review in the Core Handbook for more details.

Supersedes: ​https://github.com/WordPress/wordpress-develop/pull/7129
Gutenberg PR: ​https://github.com/WordPress/gutenberg/pull/68549

This update updates the page post-type definition and sets template-locked as the new default rendering mode for the block editor.

Trac ticket: https://core.trac.wordpress.org/ticket/61811

Closing in favor of #8123.

@TylerB24890, do you mind commenting on a new PR so I can give the props when the the feature is merged into the core?

Thanks for the fixes! 😃

I'm considering making the new default mode for Pages conditional and only setting it when wp_is_block_theme is true. Why?

• The users get the most out of this rendering mode when using block themes.
• It will eventually work for hybrid themes, but there are some known issues that I'm not sure we can resolve for WP 6.8 (but I'll try my best). See ​https://github.com/WordPress/gutenberg/issues/64341.
• This is also the original direction, which got lost during refactorings. See ​https://github.com/WordPress/gutenberg/pull/62304.

Is the create_initial_post_types (still) the best place to enable the new default mode for Pages based on conditions? cc @swissspidy, @peterwilsoncc

Yes, I don't see why not. Given that create_initial_post_types runs on init, it should be safe to use wp_is_block_theme() at that point.

I'm considering making the new default mode for Pages conditional and only setting it when wp_is_block_theme is true.

Anyway, I think it would be safer to implement this step by step, and perhaps not making it the default behavior for page-like post types for now, at least in hybrid/classic themes.

Synced the latest changes from ​https://github.com/WordPress/gutenberg/pull/69160. This is ready for testing and approval.

Thanks. Option persistence is being tracked separately: ​https://github.com/WordPress/gutenberg/issues/68250. I'll try to push an alternative PR for it before beta.

However, that compromise seems to fall into the grey area of the "decisions, not options" philosophy. Let's continue the discussion on the issue.

@Mamaduka One other observation about this PR is that it doesn't include the same post_type_default_rendering_mode filter for controlling this behavior that #7219 included. Given that we don't tend to offer filters for post type supports, this is probably ok, but we will want to consider the ways developers can easily customize these settings, given that they are registered after the post type, so hooking to registered_post_type will be too late for someone to change this value. Instead they'll need to do something like:

add_action(
        'init',
        function() {
                // Overwrite the editor support to remove default-mode.
                add_post_type_support( 'page', 'editor' );
        },
        99 // Fire after post types are registered.
);

Yes, that’s correct way to override it. I was planning including similar snippet in dev note.

@Mamaduka I took the liberty of merging in trunk to allow for dev environments that have upgraded to bcrypt hashing to log in.

While the page template is locked in the new render mode, the edit links remain for template parts. Is this intended?

I figured out the failing tests:

The is_block_theme() call added to this function populates the options cache for the stylesheet and template. In the test suite's default set_up() function, this adds data to the cache after the global scope has been cleaned, including the cache.

​https://github.com/WordPress/wordpress-develop/blob/9acdbb9d8db4eba90d623eefd5ad312cde140593/tests/phpunit/includes/abstract-testcase.php#L117-L134

Reflushing the cache after setting the post types up causes additional failures so I am not sure what the most straight forward approach is for ensuring the test suite is in an expected state.

Thanks, @peterwilsoncc!

While the page template is locked in the new render mode, the edit links remain for template parts. Is this intended?

IIRC, the edit link should only be available for users with the correct capabilities. They're also displayed in WP 6.7, if you enable show template from the sidebar.

Is the failing tests something we can resolve in test suite or do we need to change how new default is setup for Pages?

## Screenshot

Is the failing tests something we can resolve in test suite or do we need to change how new default is setup for Pages?

It looks like we just need to fix the tests. Probably calling the cleanup process again in the tear_down_after_class() method would be plenty.

It looks like we just need to fix the tests. Probably calling the cleanup process again in the tear_down_after_class() method would be plenty.

@joemcgill, @peterwilsoncc, I would appreciate some guidance on that.

[peterwilsoncc]

In 59885:

Editor: Set new default rendering mode for Pages.

This update updates the page post-type definition and sets template-locked as the new default rendering mode for the block editor.

Props mamaduka, wildworks, joemcgill, tyb, swissspidy, audrasjb.
Fixes #61811.

Yes, that’s correct way to override it. I was planning including similar snippet in dev note.

Is there a way to force the the rendering mode to 'post-only' and have the 'Show template' button removed?

Is there a way to force the the rendering mode to 'post-only'.

See code examples from Gutenberg PR - ​https://github.com/WordPress/gutenberg/pull/68549.

have the 'Show template' button removed?

This is part of general UI. There's no separate setting for it.

Is there a way to force the the rendering mode to 'post-only'.

See code examples from Gutenberg PR - ​WordPress/gutenberg#68549.

have the 'Show template' button removed?

This is part of general UI. There's no separate setting for it.

@Mamaduka thank you for your response. From what I understand, this code only sets the default rendering mode but doesn’t enforce it and still allows switching (and keep that as default).

add_action( 'init', function() {
	add_post_type_support( 'page', 'editor' );
} );

Please consider a way to disable 'Show template' and force 'post-only' as rendering mode. For clients, the fewer options, the better.

[Mamaduka]

This regressed after r59968. See ​https://github.com/WordPress/gutenberg/issues/69543.

The wp_set_editor_default_mode should use init hook and run after create_initial_post_types.

I'll create PR shortly. cc @joemcgill

## Testing Instructions

1. Create a new editor or admin user.
2. Switch to this user.
3. Create a page.
4. Confirm that it loads with template-locked as the default rendering mode.

Trac ticket: https://core.trac.wordpress.org/ticket/61811#comment:25

[joemcgill]

In 60033:

Editor: Change hook for 'wp_set_editor_default_mode'.

This is a follow up to [59968], which moves the wp_set_editor_default_mode() callback to init to make sure the subsequent call to create_initial_post_types() doesn't overwrite the post type support settings.

Props mamaduka, psykro.
Fixes #61811.

Thanks for commiting this, @joemcgill!