Officially expose the Site Editor Patterns page for all classic themes

[wildworks]

• Related ticket: #58827
• Related Gutenberg issue: ​https://github.com/WordPress/gutenberg/issues/52150

The Site Editor Patterns page was exposed internally for the Classic theme as of WP6.5.

As stated in ​the comments of this Gutenberg issue, we aim to officially expose the new Patterns page as of WP6.6.

On the Gutenberg project side, the tasks for backward compatibility with the WordPress versions that need to be supported, as well as the Block Editor and Site Editor, are almost complete.

I believe that the following measures need to be taken at the core.

• Link Appearance > Patterns submenu to the Site Editor Patterns page (wp-admin/site-editor.php?path=/patterns)
• Remove Template Parts submenu

[audrasjb]

Given this task is milestoned to WordPress 6.6 on Gutenberg side, let's move this ticket to milestone 6.6 as well.

[audrasjb]

On the Gutenberg project side, the tasks for backward compatibility with the WordPress versions that need to be supported, as well as the Block Editor and Site Editor, are almost complete.

On which branch do you suggest to potentially backport this? 6.4?

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

### Summary

This PR makes the following changes in the classic theme.

• Link Appearance > Patterns submenu to the Site Editor Patterns page (wp-admin/site-editor.php?path=/patterns)
• Remove Template Parts submenu

### About Menu Structure

It's a little confusing what the index of the submenu that $submenu['themes.php'] has, but for the submenu that this PR relates to, it should be as follows.

#### Block Theme

[5] => Themes
[6] => Editor
[7] => (Customize)

#### Classic Theme

[5] => Themes
[6] => Patterns
[7] => Customize
[8] => (Widgets)

### Screenshots

### Block Theme (Twenty Twenty-Four)

It's no different than before.

### Classic Theme (Twenty Twenty-One)

The menu structure remains the same, but the Patterns submenu now links to the Site Editor's Patterns page.

### Classic theme with block-template-parts support

The Template Part submenu has been removed and the Patterns submenu now links to the Site Editor's Patterns page.

[wildworks]

On which branch do you suggest to potentially backport this? 6.4?

Backporting to a specific branch should not be necessary on the Gutenberg repository. Backwards compatibility has been added so that the Gutenberg plugin works with all WordPress versions supported. Please refer to the following code.

​https://github.com/WordPress/gutenberg/blob/6769a2ff93aec9feaf3d9bcada94cce9e1adef07/lib/compat/wordpress-6.5/compat.php#L55-L92

​https://github.com/WordPress/gutenberg/blob/6769a2ff93aec9feaf3d9bcada94cce9e1adef07/lib/compat/wordpress-6.6/compat.php#L8-L32

[ironprogrammer]

This PR functions as advertised, unifying patterns and template parts access in the site editor. Thanks, @wildworks!

Test Report

Patch tested: ​https://github.com/WordPress/wordpress-develop/pull/6480

Environment

• Hardware: MacBook Pro Apple M1 Pro
• OS: macOS 14.5
• Browser: Safari 17.5
• Server: nginx/1.25.5
• PHP: 8.2.19
• MySQL: 8.0.27
• WordPress: 6.6-alpha-57778-src
• Themes tested:
  • twentytwentyfour v1.1
  • twentytwentyone v2.2
  • twentytwenty v2.6
  • twentynineteen v2.8
  • twentyseventeen v3.6
  • twentysixteen v3.2
  • twentyfifteen v3.7
  • twentyfourteen v3.9
  • twentythirteen v4.1
  • twentytwelve v4.2
  • twentyeleven v4.6
  • twentyten v4.1
  • custom theme with add_theme_support( 'block-template-parts' )

Actual Results

• ✅ For non-block themes, Appearance > Patterns links to /wp-admin/site-editor.php?path=/patterns (Figure 1).
• ✅ For non-block theme with block-template-parts support, Appearance > Template Parts menu item is removed (but remains accessible via editor Patterns > Template Parts menu.
• ✅ Menu items order (Patterns, Customize, Widgets) displays as expected.
• ✅ For block theme, menu is unaffected.

Supplemental Artifacts

Figure 1: New link path for Patterns menu item.

(Disregard "in a new tab", which is an artifact of pressing Cmd while capturing this image.)

Agree with @ironprogrammer, code looks good. the only thing I'm a bit unsure about is the part of site-editor.php that deals with template parts and non-block themes: ​https://github.com/WordPress/wordpress-develop/blob/trunk/src/wp-admin/site-editor.php#L22-L35.

If the template parts menu item is removed, does that that code need updating too?

Thanks for the review!

The only thing I'm a bit unsure about is the part of site-editor.php that deals with template parts and non-block themes: ​https://github.com/WordPress/wordpress-develop/blob/trunk/src/wp-admin/site-editor.php#L22-L35.

If the template parts menu item is removed, does that code need updating too?

The code here, i.e. $is_template_part_editor, should be maintained for backward compatibility. This is because the path (wp-admin/site-editor.php?path=/wp_template_part/all ) may have been hard-coded by the developer or added to the browser's bookmarks by the user.
On the site editor side, when this old path is accessed, it redirects to the pattern page. See ​https://github.com/WordPress/gutenberg/pull/61446 for details.

should be maintained for backward compatibility.
...may have been hard-coded by the developer or added to the browser's bookmarks by the user.

Right, that's why I asked :)

On the site editor side, when this old path is accessed, it redirects to the pattern page.

Yep, this is how it should be. However it doesn't seem to redirect in WP core when testing this PR (unless I'm not testing it right?). It goes to a "Manage template parts" screen which of course doesn't work right. Thinking it would be good to have that redirect in PHP too.

Here's a screenshot with this PR applied and testing the old URL:

However it doesn't seem to redirect in WP core when testing this PR

I think it's because the latest Gutenberg hasn't been merged into core yet, although JS redirection is implemented ​here.

I feel that if we implement PHP redirection in the core, JS redirection in Gutenberg might be unnecessary.

cc @youknowriad @jsnajdr

I feel that if we implement PHP redirection in the core, JS redirection in Gutenberg might be unnecessary.

Yes, thinking so too. Generally PHP redirects are preferable as they run faster (the browser stops loading the current page and redirects as soon as it receives the header of the response). Also seems the JS redirection won't happen if the user has bookmarked the old screen and is loading that bookmark?

I think JS redirection is probably necessary here because the site editor is an SPA and folks (third-parties) can navigate to URLs without actually reaching the server.

With changeset 58187, The JS side redirect is now reflected in the core. Do we also need a PHP redirect just in case?

I don't think it's needed personally. This PR seems ready to ship for me.

​Checking WP Directory for use of \/wp_template_part\/all, of the [only] two hard-coded links in those results, they redirect to site-editor.php?path=/patterns as expected. I agree this is good to go.

[ironprogrammer]

Thanks everyone for your input! Tagging for commit consideration ahead of next week's beta.

[audrasjb]

In 58278:

Editor: Expose the Site Editor Patterns page for classic themes.

The Site Editor Patterns page was exposed internally for the Classic theme as of WP6.5. As we aim to officially expose the new Patterns page as of WP6.6, this changeset makes the following changes available when a classic themes is activated:

• Link Appearance > Patterns submenu to the Site Editor Patterns page located at `wp-admin/site-editor.php?path=/patterns
• Remove Template Parts submenu

Props wildworks, audrasjb, ironprogrammer, azaozz, youknowriad.
Fixes #61109.

Committed in https://core.trac.wordpress.org/changeset/58278