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.

[ndiego]

I inadvertently created a duplicate of this issue in #53587, but I wanted to reiterate the benefit of adding a "Patterns" menu item for non-block themes.

I attended two meetup events in the last 24 hours where users were excited about the ability to create patterns from within the Editor in 6.3, but they were confused about how to edit/delete patterns once they have been created. They were not using block themes and did not know about the "hidden" ..wp-admin/edit.php?post_type=wp_block page. They also did not know about the link in the Options → Tools menu in the Editor.

[t-hamano]

Update: With #52154 resolved, I believe the issue of unintended commands appearing in the command search results in non-block themes and leading to unintended pages has been resolved. Therefore, I believe we are ready to open the Patterns menu to non-block themes.

[t-hamano]

Update: In #54066, we were looking for a way to allow all classic themes to access the Pattern page of the Site Editor in the future, while maintaining backward compatibility and preventing possible problems caused by the combination of different WordPress versions and whether or not the Gutenberg plugin is activated.

After much discussion, we are considering taking the following approach.

In Core WP 6.4:

1. Add an Appearance -> Patterns link for all classic themes that point to edit.php?post_type=wp_block.
2. Allow site-editor.php?path=/patterns access for classic themes internally.

In Gutenberg after the minimum required version is WP 6.4:

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.

The core patch was also submitted: WordPress/wordpress-develop#5201

[t-hamano]

Update: The ability to publish the Pattern page (edit.php?post_type=wp_block) in the classic theme has been punted to WP6.5 because the core patch commit has passed the deadline to ship to WP6.4 (one reason is that when I submitted the core ticket, I labeled it as bugfix instead of enhancement. Sorry 🙇).

So the expected schedule would be as follows:

In Core WP 6.5:

1. Add an Appearance -> Patterns link for all classic themes that point to edit.php?post_type=wp_block.
2. Allow site-editor.php?path=/patterns access for classic themes internally.

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]

This has been punted to 6.5. Thank you to everyone who worked tirelessly on this.

[aaronrobertshaw]

There's been some recent confusion about why this issue cannot be resolved entirely for WP 6.5 so I'll try to expand on @t-hamano's comment above.

My understanding of the current situation is:

1. A core update is needed to allow direct access for classic themes to the patterns page in the site editor.
2. An Appearance > Patterns link can be added to wp-admin in core for 6.5 and is part of the current plan.
3. All the command palette pattern commands and in-editor links in Gutenberg cannot go to the Site Editor for classic themes until WP 6.5 is the minimum supported version as they'd need the access provided by the core update in #1.

What this means for WP 6.5 is:

• An Appearance > Patterns link will be available in wp-admin
• Classic themes can access the Site Editor's Patterns page
• #5201 needs to be merged

What this means for Gutenberg:

• All the links around managing patterns for classic themes, will remain the same until WP 6.5 is the minimum version.
• This is because Gutenberg could be used with older versions of WordPress which would block access to the Site Editor's Patterns page.

I hope that helps 🤞

[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