Editor: Set new default rendering mode for Pages

[Mamaduka]

Supersedes: #7129
Gutenberg PR: WordPress/gutenberg#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

---

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.

[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.

Core Committers: Use this line as a base for the props when committing in SVN:

Props mamaduka, peterwilsoncc, wildworks, joemcgill, tyb, swissspidy, audrasjb.

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

[github-actions]

Test using WordPress Playground

The changes in this pull request can previewed and tested using a WordPress Playground instance.

WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser.

Some things to be aware of

• The Plugin and Theme Directories cannot be accessed within Playground.
• All changes will be lost when closing a tab with a Playground instance.
• All changes will be lost when refreshing the page.
• A fresh instance is created each time the link below is clicked.
• Every time this pull request is updated, a new ZIP file containing all changes is created. If changes are not reflected in the Playground instance,
  it's possible that the most recent build failed, or has not completed. Check the list of workflow runs to be sure.

For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation.

Test this pull request with WordPress Playground.

[TylerB24890]

Thanks for the fixes! 😃

[Mamaduka]

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 Wrong template displayed for hybrid themes in the post template editor gutenberg#64341.
• This is also the original direction, which got lost during refactorings. See Feature: Set editor rendering mode by post type gutenberg#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

[swissspidy]

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.

[audrasjb]

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.

[Mamaduka]

Synced the latest changes from WordPress/gutenberg#69160. This is ready for testing and approval.

[Mamaduka]

Suggested change

	if ( wp_is_block_theme() ) {
	if ( wp_is_block_theme() && current_theme_supports( 'block-templates' ) ) {

I think I'll need to harden this condition by adding a current_theme_supports check. While it should be an edge case for a block theme not to support block-templates, it's still technically doable. See: WordPress/gutenberg#67875 (comment).

[joemcgill]

I like this more narrow approach for 6.8-beta1. Ideally, I'd like for us to accompany this change with a way to persistently store the user's preference so folks who do not want this default don't have to change the view each time they open a Page, but we can handle that in a follow-up.

[Mamaduka]

Thanks. Option persistence is being tracked separately: WordPress/gutenberg#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.

[joemcgill]

@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.
);

[Mamaduka]

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

[peterwilsoncc]

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

[peterwilsoncc]

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

[peterwilsoncc]

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.

wordpress-develop/tests/phpunit/includes/abstract-testcase.php

Lines 117 to 134 in 9acdbb9

	$this->clean_up_global_scope();
	/*
	* When running core tests, ensure that post types and taxonomies
	* are reset for each test. We skip this step for non-core tests,
	* given the large number of plugins that register post types and
	* taxonomies at 'init'.
	*/
	if ( defined( 'WP_RUN_CORE_TESTS' ) && WP_RUN_CORE_TESTS ) {
	$this->reset_post_types();
	$this->reset_taxonomies();
	$this->reset_post_statuses();
	$this->reset__SERVER();
	if ( $wp_rewrite->permalink_structure ) {
	$this->set_permalink_structure( '' );
	}
	}

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.

[Mamaduka]

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

[joemcgill]

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.

[Mamaduka]

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]

I've pushed a fix to the tests, modifying them to test the before and after values to ensure the notoption is stored in the correct cache.

[github-actions]

A commit was made that fixes the Trac ticket referenced in the description of this pull request.

SVN changeset: 59885
GitHub commit: 83b9080

This PR will be closed, but please confirm the accuracy of this and reopen if there is more work to be done.