Site Editor: Consider compatibility regarding non-block themes and the Library menu

[t-hamano]

What problem does this address?

For non-blocking themes, Template Parts Editor can be enabled with the following code:

add_theme_support( 'block-template-parts' );

I believe that the addition of the Library (aka Patterns) menu to the Site Editor has caused this opt-in support to behave differently than originally expected, resulting in the following problems.

• When the Appearance > Template Parts menu is accessed, a list of all template parts is displayed, but the upper Library menu can be accessed. This means that new template part will be allowed to be added. As I mentioned in this comment, this should not be the expected behavior in a non-block theme.
• I'm expecting to opt in to the template parts editor only, but it also provides pattern (synced/non-synced) management functionality. While this may be gratifying, I don't think it is the expected behavior of this theme support.

What is your proposed solution?

In order to maintain the functionality originally intended by this theme support, I suggest not allowing access to the Library menu. This means that when you press the Back button in the All Template Part menu, you will return to the Admin page, not the Library.

However, in this case, the non-block theme will not be able to take advantage of the convenient pattern management features and new features that may be implemented in the Libary menu in the future.

Alternatively, new opt-in support for accessing the Library menu could be introduced.

add_theme_support( 'library' );
// or
add_theme_support( 'patterns' );

If you have any good suggestions, please comment.

975467f9cbed70f1ec92c3069bdd2e07.mp4

[annezazu]

cc @WordPress/gutenberg-design

[jameskoster]

The proposal sounds reasonable for add_theme_support( 'template-parts' );.

add_theme_support( 'patterns' ); might enable access to edit.php?post_type=wp_block via Appearance > Patterns.

If a theme adds support for both patterns and template-parts then the full Library experience could be enabled.

What do you think?

[annezazu]

I like that approach and it seems sound to me. I'm curious to hear from @WordPress/block-themers to see what we might be missing and to hear from broader themers who both know the experience of classic themes and have made the switch to block themes in various ways.

[carolinan]

I think the naming of add_theme_support( 'patterns' ); would need to be more specific, it sounds like it would enable all pattern features, and that remove_theme_support('patterns') would disable all pattern features.

[carolinan]

Or, maybe it should be the other way around: that the pattern screen is always available for all themes unless disabled.

[carolinan]

The "current pattern library", the Inserter > Patterns > Explore all patterns, is not limited depending on the theme type, so why should the new screen be? 😄

[jameskoster]

That's a good point. But how would you get to the pattern library when a classic theme is active, Appearance > Patterns?

Naturally it would only be possible to create / edit template parts when support is declared.

[fabiankaegy]

I've long wished to have the Appearance > Patterns menu item (when it was still reusable blocks). That would be a great addition 👍

Additionally I'd love for the Style Book to get exposed the same way #41119 (comment) :)

[t-hamano]

Thank you all for your input! Based on your input, I have the following ideas:

For the classic theme, "Patterns" menu is displayed under "Appearance" menu, regardless of whether it supports block-template-parts or not. This menu is tied to the classic pattern admin page (/wp-admin/edit.php?post_type=wp_block).

If the classic theme supports block-template-parts, it will display "Template Parts" menu under "Apperance" menu as before. However, when the back button is pressed, it returns to the admin page, not to the upper Patterns (Library) menu.

By adding such as add_theme_support( 'patterns' ), the "Patterns" menu is displayed below the "Appearance" menu. However, this is not the classic pattern admin page, but is tied to the Patterns (Library) menu in the Site Editor. In this case, the Classic theme should be able to update only the pre-bundled template parts, so we do not allow the creation of template parts.

---

ccing @aaronrobertshaw Because in #51957, you are trying to control where the "Manage all patterns" links to, depending on whether it is a block-based theme or not, and I think this is relevant to this issue 🙏

[jameskoster]

@t-hamano I don't know that we need to present patterns and template parts separately for classic themes. It probably makes sense to reuse as much of the general pattern management experience as possible.

So without add_theme_support( 'template-parts' ), Appearance > Patterns would link to something like:

The back button would return you to wp-admin.

Note the exclusion of:

1. The "Create template part" action.
2. The "Template parts" section.
3. The "Manage template parts" button in the sidebar footer.

If the theme adds support for template parts, those three exclusions are revoked and become available.

What do you think?

[t-hamano]

@jameskoster

So without add_theme_support( 'template-parts' ), Appearance > Patterns would link to something like:

Oh, I think that is a very good approach!

However, we might need to decide how far to go with these changes in WP6.3.

Personally, I think at least the following changes are acceptable:

If the classic theme supports block-template-parts, it will display "Template Parts" menu under "Apperance" menu as before. However, when the back button is pressed, it returns to the admin page, not to the upper Patterns (Library) menu.

[jameskoster]

I guess it depends on whether classic themes will be granted access to pattern management in general. If not, your suggestion makes sense.

[t-hamano]

I believe that in the future all themes should have access to the Patterns management features of the Site Editor. Therefore, I would like to address the following steps. If you have other suggestions, please let me know.

Backport to WordPress 6.3 (RC1)

Themes that support block-template-parts can use the template parts management screen in the Site Editor. However, users can create template parts unintentionally because they can return to the parent Patterns page. So, on the Patterns page, check if it is possible to create template parts, and make unnecessary menus unavailable.

Future implementations

For non-block themes, add a Patterns menu under the Appearance menu, with or without block-template-parts support. If block-template-parts is supported, the Template Parts Management menu is accessible.

Access rights management

As I reported in #49713, if you reload a page in non-block themes, access is denied. More fine-grained access control based on paths and available features may be needed.

[t-hamano]

Update: With #52656, the issue where non-block themes could unintentionally create template parts has been fixed. It would be difficult to backport to WordPress 6.3 due to time constraints to allow all themes to have access to the Patterns menu. Therefore, I will move this issue to "porting to 6.4" and continue work after the 6.3 release.

[t-hamano]

Core Ticket: https://core.trac.wordpress.org/ticket/58827

[aaronrobertshaw]

Thanks for all the effort in wrangling this one and exploring options @t-hamano 👍

This issue is currently under the "Future Follow-ups" section of the Patterns tracking issue which I believe aligns with the plan outlined above.

[t-hamano]

Update: In core, added a "Pattern" menu item under Classic Theme Appearance:

https://core.trac.wordpress.org/changeset/57543

This completes the task for WordPress 6.5, but since the following needs to be addressed in the future, I would like to leave this issue open and punt it to WP6.6.

In Gutenberg after the minimum required version is WP 6.5:

3. Change all "Manage patterns" links to point to site-editor.php?path=/patterns.
4. Change the Appearance -> Patterns links for classic themes to point to site-editor.php?path=/patterns.

[annezazu]

Sounds great. Thank you, @t-hamano, for seeing this through at each step.

[t-hamano]

Update:

In Gutenberg after the minimum required version is WP 6.5:

3. Change all "Manage patterns" links to point to site-editor.php?path=/patterns.
4. Change the Appearance -> Patterns links for classic themes to point to site-editor.php?path=/patterns.

This roadmap is based on the fact that Gutenberg plugin needs to support WP6.4 and below. This means that under WP6.4, classic themes still cannot access the Site Editor's pattern page (wp_die() will kill the process).

However, as mentioned in this comment, I learned that it is possible to filter wp_die() function itself. If we could incorporate this approach into the Gutenberg plugin, we might be able to publish new Patterns page (site-editor.php?path=/patterns) to the classic theme without having to wait until the Gutenberg plugin supports core versions 6.5 or higher.

I would like to try this approach.

[t-hamano]

Update: I would like to work on the necessary tasks to officially publish the Site Editor Patterns page for all classic themes in WP6.6.

My understanding is that the current specs for WP6.5 and expected specs for WP6.6 should be as follows:

WP6.5

• Appearance > Patterns submenu is linked to wp-admin/edit.php?post_type=wp_block.
• Access to the Site Editor Patterns page (wp-admin/site-editor.php?path=/patterns) is allowed internally.
• Appearance > Template Parts submenu is linked to the Site Editor Template Parts List page (wp-admin/site-editor.php?path=/wp_template_part/all)

WP6.6

• Appearance > Patterns submenu is linked to the Site Editor Patterns page (wp-admin/site-editor.php?path=/patterns)
• The Template Parts submenu will be removed
• The Template Parts List can still be accessed within the Site Editor Patterns page
• The Site Editor Patterns page will be displayed even when the conventional Template Parts List URL (wp-admin/site-editor.php?path=/wp_template_part/all) is accessed.
• Change all links to the Patterns page such as "Manage Patterns" to the Site Editor Patterns page.

[annezazu]

Thanks for diving in -- excited to see this slated finally for 6.6. Let me know what support you might need here too <3

[t-hamano]

Update: I'm working on this problem continuously, but most of the preparations are done. Once all the related tasks below are completed, this issue should be closed.

Gutenberg PRs

• Back Compat: Add Patterns submenu for WordPress 6.4 #60804
• Classic Theme: Expose new Patterns page and remove Template Parts submenu #61080
• Site Editor: Redirect /wp_template_part/all to /patterns #61446

Core ticket and PR

• Ticket, PR

[annezazu]

Because this often comes up with many new features where we change the experience for classic themes, is there a filter in place where folks can roll back to the original experience @t-hamano ?

[t-hamano]

If we want to change the Pattern submenu link to the previous one, we can use the following hook:

function change_patterns_submenu_link() {
	if ( ! wp_is_block_theme() ) {
		global $submenu;
		foreach ( $submenu['themes.php'] as $key => $item ) {
			if ( 'site-editor.php?path=/patterns' === $item[2] ) {
				$submenu['themes.php'][ $key ][2] = 'edit.php?post_type=wp_block';
			}
		}
	}
}
add_action( 'admin_init', 'change_patterns_submenu_link' );

However, the "Manage patterns" menu on the block editor or via the command palette always links to the Patterns page in the site editor.

[t-hamano]

All tasks on this issue have been completed and I would like to close it.

The next step will be to expose the Patterns page to all "users" as well as all "themes" (See #61637).

Thank you to everyone who was involved!