Feature: Set editor rendering mode by post type #62304

TylerB24890 · 2024-06-04T20:14:25Z

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

Track Ticket: https://core.trac.wordpress.org/ticket/61811
Backport PR: WordPress/wordpress-develop#7129

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

Create a new post post type and observe the default editor UI.
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';
    }
);

Refresh the post editor and confirm you are now seeing the Template UI instead of the default Post UI.
Create a new page post and confirm the page editor also loads with the Template UI.
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';
    }
);

Reload the page editor and confirm it still renders the Template UI.
Refresh the post editor and confirm it now renders the default Post UI.
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
)

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',
    ]
);

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

…to API response.

…cess.

…deringMode value into the Editor rendering function.

…ration.

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

lib/compat/wordpress-6.6/post.php

lib/compat/wordpress-6.6/class-gutenberg-rest-post-types-controller-6-6.php

packages/edit-post/src/editor.js

youknowriad

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

…perty to read default_rendering_mode.

github-actions · 2024-06-05T14:29:30Z

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: Sidsector9 <nomnom99@git.wordpress.org>
Co-authored-by: fabiankaegy <fabiankaegy@git.wordpress.org>
Co-authored-by: youknowriad <youknowriad@git.wordpress.org>
Co-authored-by: dcalhoun <dpcalhoun@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.

lib/compat/wordpress-6.7/post.php

jasmussen · 2024-06-06T07:51:44Z

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?

The setting was added in WordPress/gutenberg#62304 and is needed with the newest Gutenberg version. [MAILPOET-6319]

Mamaduka · 2024-12-12T07:16:24Z

It's been a few weeks, and I still find the new default rendering mode confusing for pages. Maybe the pages should default to template-locked only in the Site Editor and post-only in the post-type Editor.

IMO, this is a significant behavior change for Pages in the post editor. Unfortunately, we'll only get real feedback after WP 6.8 is released.

Update: The change also breaks page editing for non-Administrator users with edit_pages capability, such as Editors.

P.S. There's already a report about the changes in List View behavior for page - #67857.

Screenshot (broken page for Editors)

fabiankaegy · 2024-12-12T07:39:25Z

@Mamaduka I'll say that I have shipped 3 projects where we used the hacky JS approach to change the default rendering mode:

import { registerPlugin } from '@wordpress/plugins';
import { useDispatch, useSelect } from '@wordpress/data';
import { useEffect } from '@wordpress/element';
import { store as editorStore } from '@wordpress/editor';

// Define post types that show the full template locked site editor by default.
const TEMPLATE_LOCKED_POST_TYPES = ['page', 'post'];

registerPlugin('namespace-set-default-template-rendering-mode', {
	render: function Edit() {
		const { setRenderingMode } = useDispatch(editorStore);

		const [postType] = useSelect((select) => [select(editorStore).getCurrentPostType()], []);

		useEffect(() => {
			if (!TEMPLATE_LOCKED_POST_TYPES.includes(postType)) {
				return;
			}
			setRenderingMode('template-locked');
		}, [setRenderingMode, postType]);

		return null;
	},
});

And have had great success with it. However when we changed it, we changed it across the board for all content types so the behavior was consistent.

I agree that it is a big change and we should definitely be careful about rolling it out.

I hope that if we decide to roll it back though, that we keep the underlying property on the CPT so that we can override the default rendering mode much easier than we do it today since the solution today creates some unstyled flashes of content whilst loading

fabiankaegy · 2024-12-12T07:40:42Z

@Mamaduka

Do you have any more details about:

Update: The change also breaks page editing for non-Administrator users with edit_pages capability, such as Editors.

This here only changes the default? It was long before possible to preview the template even as a non admin. Sounds like there is a regression there 🤔

swissspidy · 2024-12-12T07:51:11Z

Can we please rename default_rendering_mode to something else that makes it clearer that it‘s about the editor? Maybe prefix it with editor_ at least.

Also, have you considered using the post type supports feature for that, rather than adding a new top level prperty?

fabiankaegy · 2024-12-12T07:55:02Z

@swissspidy all open on the name 👍

Also, have you considered using the post type supports feature for that, rather than adding a new top level property?

Yes but deemed it not the right choice here because even before this was merged in a block theme every single post type supports the ability to preview the template as you are editing the post. So this is not a new support, it is just enabling it by default. (Allowing you to change the default)

Since there are multiple possible options here we would need a key value pair of some kind 🤔 which post type supports are not

Mamaduka · 2024-12-12T07:56:23Z

@fabiankaegy, I'm not saying we should revert the whole feature; I quite like it.

I think we should consider whether Pages will ship with template-locked as the default rendering mode. IMO, it makes sense for the site editor, but for a post-block editor, it's a big leap. Maybe we should make it opt-in for all post types.

Do you have any more details about.

I don't have them now, but when the default rendering mode is set to template-locked, nothing is rendered in the post editor when accessing it as an Editor. We should also test other capabilities and CPTs to see what is failing.

Also, have you considered using the post type supports feature for that, rather than adding a new top level prperty?

That would require changing the shape of the supports property since it is a one-dimensional array.

swissspidy · 2024-12-12T08:58:22Z

Since there are multiple possible options here we would need a key value pair of some kind 🤔 which post type supports are not
That would require changing the shape of the supports property since it is a one-dimensional array.

So? :) That sounds feasible to implement and has come up in the past already anyway. It could be added as a config to the editor support.

Definitely worth exploring IMO. Way more future proof if you need any more configs in the future.

all open on the name 👍

If post type support doesn‘t work, I‘d suggest editor_rendering_mode at least.

Mamaduka · 2024-12-12T09:35:24Z

Maybe we should fold editor-specific settings into a new object. Technically speaking, template and template_lock are also block editor specific.

youknowriad · 2024-12-12T09:40:55Z

One thing that I personally value is the consistency between site and post editors, these are not separate editors, these are just how things have evolved and it will "merge" fully at some point (single url).

That said for the choice of the default rendering mode for pages, I think it's a very hard question to answer, I've seen feedback in both ways: some folks (mostly devs) have a clear separation in their head so they prefer just the abstracted view, some users prefer to see the full page.

swissspidy · 2024-12-12T09:42:34Z

Since there are multiple possible options here we would need a key value pair of some kind 🤔 which post type supports are not
That would require changing the shape of the supports property since it is a one-dimensional array.

So? :) That sounds feasible to implement and has come up in the past already anyway. It could be added as a config to the editor support.

Definitely worth exploring IMO. Way more future proof if you need any more configs in the future.

all open on the name 👍

If post type support doesn‘t work, I‘d suggest editor_rendering_mode at least.

I take it back, this actually is supported!

A feature can also be specified as an array of arguments to provide additional information about supporting that feature.

Mamaduka · 2024-12-12T09:58:11Z

I take it back, this actually is supported!

@swissspidy, can you clarify? Does that mean that the post type supports property can have multi-dimensional arrays?

That said for the choice of the default rendering mode for pages, I think it's a very hard question to answer, I've seen feedback in both ways: some folks (mostly devs) have a clear separation in their head so they prefer just the abstracted view, some users prefer to see the full page.

@youknowriad, I think we should ship this as an opt-in feature, at least for now.

youknowriad · 2024-12-12T10:06:02Z

I think we should ship this as an opt-in feature, at least for now.

The problem for me is the inconsistency with the site editor, we need to change one behavior, so it's going to change something regardless.

swissspidy · 2024-12-12T10:34:51Z

can you clarify? Does that mean that the post type supports property can have multi-dimensional arrays?

@Mamaduka Yes! Example: array( 'my_feature', array( 'field' => 'value' ) ).

swissspidy · 2024-12-12T10:42:13Z

lib/compat/wordpress-6.8/post.php

+			$rendering_mode = $args['default_rendering_mode'];
+		}
+
+		$args['default_rendering_mode'] = $rendering_mode;


Surprised that we even allow adding custom args... We should have added an allowlist.

Mamaduka · 2024-12-12T10:57:12Z

@youknowriad, how should we handle users who can edit pages but not templates and template parts? Currently, page editing is broken for these users.

fabiankaegy · 2024-12-12T11:01:49Z

@Mamaduka in #60447 we enabled the show template option for any user role.

This was preceded by #60317 which made the templates read only for all users

Mamaduka · 2024-12-12T12:03:25Z

@fabiankaegy, I'll debug it tomorrow. It could be an unrelated issue; I also see the settings endpoints error when testing with the Editor role.

We also need to test various cases to ensure everything works as expected. Here's a bug report for the case we missed, #67875.

Some flows that come to mind:

Block theme with lower cap users.
Block theme, but the page has a PHP template assigned to it.

annezazu · 2024-12-17T20:38:45Z

I think we should consider whether Pages will ship with template-locked as the default rendering mode. IMO, it makes sense for the site editor, but for a post-block editor, it's a big leap. Maybe we should make it opt-in for all post types.

FWIW I agree with @Mamaduka here. This is a big change for folks to see by default and I think it'll create a lot of confusion to suddenly see. WordPress.com does run the Gutenberg plugin so I'll see what I can do to get feedback earlier in the release cycle before 6.8 hits in case it helps.

t-hamano · 2024-12-24T01:14:43Z

I think we should consider whether Pages will ship with template-locked as the default rendering mode. IMO, it makes sense for the site editor, but for a post-block editor, it's a big leap. Maybe we should make it opt-in for all post types.

I agree. The Page is also a post type, so I don't understand why it's treated specially. I was confused when I first opened a page in the post editor.

Previously, users could only see the content area in the post editor for any post type and edit all the blocks. If templates are shown by default, it's confusing what they mean and why you can't remove blocks.

Furthermore, the only way to tell if a template is shown is by an icon in the document bar. Many people may not even know what this icon means in the first place.

Mamaduka · 2024-12-24T07:51:02Z

@jorgefilipecosta and I somewhat branched off the discussion in #68110.

The proposed behavior will be "broken" for non-administrator users who can edit the pages, as the default rendering mode will be switched to "post-only".

youknowriad · 2024-12-24T13:20:09Z

packages/editor/src/components/provider/index.js

+			post,
+			recovery,
+			setupEditor,
+			updatePostLock,


@fabiankaegy Is the addition of the dependencies here in relation to the current PR or was it done just to please the linter?

This is creating a bug when the post object is update, the setup happens again and initial edits are applied again even if they shouldn't be.

TylerB24890 added 6 commits June 4, 2024 13:01

Add Post_Types_Controller compat class. Add rendering_mode parameter …

ab4b075

…to API response.

Add the rendering_mode property to the post type object properties

ca0de5d

Check that the rendering_mode property exists before attempting to ac…

3beef1e

…cess.

Fix PHP filters from overriding one another. Implement the defaultRen…

9b276d2

…deringMode value into the Editor rendering function.

Remove unnecessary optional chain inside conditional

a26a583

Dont override the rendering_mode value if set during post type regist…

b538ae6

…ration.

jeffpaul assigned TylerB24890 Jun 4, 2024

fabiankaegy added [Type] Enhancement A suggestion for improvement. [Feature] Template Editing Mode Related to the template editor available in the Block Editor REST API Interaction Related to REST API labels Jun 5, 2024

fabiankaegy reviewed Jun 5, 2024

View reviewed changes

lib/compat/wordpress-6.6/post.php Outdated Show resolved Hide resolved

lib/compat/wordpress-6.6/class-gutenberg-rest-post-types-controller-6-6.php Outdated Show resolved Hide resolved

fabiankaegy requested review from Mamaduka, youknowriad, getdave, noisysocks, talldan, ramonjd and ntsekouras June 5, 2024 12:19

fabiankaegy linked an issue Jun 5, 2024 that may be closed by this pull request

Add an option to change default renderingMode of Post Editor #58038

Closed

youknowriad reviewed Jun 5, 2024

View reviewed changes

packages/edit-post/src/editor.js Outdated Show resolved Hide resolved

youknowriad reviewed Jun 5, 2024

View reviewed changes

Move all code to a new 6.7 compat directory. Update the post type pro…

e3912d4

…perty to read default_rendering_mode.

TylerB24890 marked this pull request as ready for review June 5, 2024 14:29

TylerB24890 requested a review from spacedmonkey as a code owner June 5, 2024 14:29

ramonjd reviewed Jun 6, 2024

View reviewed changes

lib/compat/wordpress-6.7/post.php Outdated Show resolved Hide resolved

fabiankaegy mentioned this pull request Jun 6, 2024

Move default redering mode setting to block_editor_settings_all hook in PHP to allow customizing it #61844

Closed

This comment was marked as outdated.

Sign in to view

triple0t pushed a commit to mailpoet/mailpoet that referenced this pull request Nov 26, 2024

Add forward compatibility for template-locked mode

5bbdc41

The setting was added in WordPress/gutenberg#62304 and is needed with the newest Gutenberg version. [MAILPOET-6319]

annezazu mentioned this pull request Dec 3, 2024

Template vs Content Editing UX: enable the ability to hit return from post title to begin writing #54984

Open

fushar mentioned this pull request Dec 12, 2024

Starter page templates: correctly insert the pattern to the Content block Automattic/jetpack#40583

Merged

3 tasks

Mamaduka mentioned this pull request Dec 12, 2024

Block options missing in listview and editor screen #67857

Open

6 tasks

Mamaduka mentioned this pull request Dec 12, 2024

REST API: Simplify 'default_rendering_mode' field registration for post types #67867

Open

swissspidy reviewed Dec 12, 2024

View reviewed changes

Mamaduka mentioned this pull request Dec 17, 2024

Editing "Page" is broken for low capability users #68053

Open

jeherve mentioned this pull request Dec 17, 2024

Copy Post: Editor seems to revert title and content changes when saving Automattic/jetpack#40647

Open

annezazu mentioned this pull request Dec 17, 2024

'Show Template' defaulting to on for non-English(US) languages Automattic/wp-calypso#97494

Open

annezazu mentioned this pull request Dec 23, 2024

Make "Show template" option persistent #68250

Open

youknowriad reviewed Dec 24, 2024

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Feature: Set editor rendering mode by post type #62304

Feature: Set editor rendering mode by post type #62304

TylerB24890 commented Jun 4, 2024 •

edited

Loading

fabiankaegy left a comment

youknowriad left a comment

github-actions bot commented Jun 5, 2024 •

edited

Loading

ramonjd left a comment

jasmussen commented Jun 6, 2024

This comment was marked as outdated.

This comment was marked as outdated.

Mamaduka commented Dec 12, 2024 •

edited

Loading

fabiankaegy commented Dec 12, 2024

fabiankaegy commented Dec 12, 2024

swissspidy commented Dec 12, 2024

fabiankaegy commented Dec 12, 2024 •

edited

Loading

Mamaduka commented Dec 12, 2024

swissspidy commented Dec 12, 2024

Mamaduka commented Dec 12, 2024

youknowriad commented Dec 12, 2024

swissspidy commented Dec 12, 2024

Mamaduka commented Dec 12, 2024

youknowriad commented Dec 12, 2024

swissspidy commented Dec 12, 2024

swissspidy Dec 12, 2024

Mamaduka commented Dec 12, 2024

fabiankaegy commented Dec 12, 2024

Mamaduka commented Dec 12, 2024

annezazu commented Dec 17, 2024

t-hamano commented Dec 24, 2024

Mamaduka commented Dec 24, 2024

youknowriad Dec 24, 2024

Feature: Set editor rendering mode by post type #62304

Feature: Set editor rendering mode by post type #62304

Conversation

TylerB24890 commented Jun 4, 2024 • edited Loading

What?

Why?

How?

Testing Instructions

fabiankaegy left a comment

Choose a reason for hiding this comment

youknowriad left a comment

Choose a reason for hiding this comment

github-actions bot commented Jun 5, 2024 • edited Loading

ramonjd left a comment

Choose a reason for hiding this comment

jasmussen commented Jun 6, 2024

This comment was marked as outdated.

This comment was marked as outdated.

Mamaduka commented Dec 12, 2024 • edited Loading

Screenshot (broken page for Editors)

fabiankaegy commented Dec 12, 2024

fabiankaegy commented Dec 12, 2024

swissspidy commented Dec 12, 2024

fabiankaegy commented Dec 12, 2024 • edited Loading

Mamaduka commented Dec 12, 2024

swissspidy commented Dec 12, 2024

Mamaduka commented Dec 12, 2024

youknowriad commented Dec 12, 2024

swissspidy commented Dec 12, 2024

Mamaduka commented Dec 12, 2024

youknowriad commented Dec 12, 2024

swissspidy commented Dec 12, 2024

swissspidy Dec 12, 2024

Choose a reason for hiding this comment

Mamaduka commented Dec 12, 2024

fabiankaegy commented Dec 12, 2024

Mamaduka commented Dec 12, 2024

annezazu commented Dec 17, 2024

t-hamano commented Dec 24, 2024

Mamaduka commented Dec 24, 2024

youknowriad Dec 24, 2024

Choose a reason for hiding this comment

TylerB24890 commented Jun 4, 2024 •

edited

Loading

github-actions bot commented Jun 5, 2024 •

edited

Loading

Mamaduka commented Dec 12, 2024 •

edited

Loading

fabiankaegy commented Dec 12, 2024 •

edited

Loading