#61109 closed enhancement (fixed)
Officially expose the Site Editor Patterns page for all classic themes
Reported by: |
|
Owned by: |
|
---|---|---|---|
Milestone: | 6.6 | Priority: | normal |
Severity: | normal | Version: | |
Component: | Editor | Keywords: | has-patch has-screenshots has-testing-info gutenberg-merge commit needs-dev-note add-to-field-guide |
Focuses: | Cc: |
Description
- 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
Change History (22)
#1
@
9 months ago
- Summary changed from Officially explore the Site Editor Patterns page for all classic themes to Officially expose the Site Editor Patterns page for all classic themes
#3
@
9 months ago
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?
This ticket was mentioned in PR #6480 on WordPress/wordpress-develop by @wildworks.
9 months ago
#4
- Keywords has-patch added
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.
#5
@
9 months ago
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.
This ticket was mentioned in Slack in #core by nhrrob. View the logs.
9 months ago
#7
@
9 months ago
- Keywords has-screenshots has-testing-info added
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.)
9 months ago
#8
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?
@wildworks commented on PR #6480:
9 months ago
#9
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.
9 months ago
#10
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:
@wildworks commented on PR #6480:
9 months ago
#11
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
9 months ago
#12
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?
@youknowriad commented on PR #6480:
9 months ago
#13
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.
@wildworks commented on PR #6480:
9 months ago
#14
With changeset 58187, The JS side redirect is now reflected in the core. Do we also need a PHP redirect just in case?
@youknowriad commented on PR #6480:
8 months ago
#16
I don't think it's needed personally. This PR seems ready to ship for me.
@ironprogrammer commented on PR #6480:
8 months ago
#17
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.
#18
@
8 months ago
- Keywords commit added
Thanks everyone for your input! Tagging for commit
consideration ahead of next week's beta.
#19
@
8 months ago
- Keywords needs-dev-note add-to-field-guide added
- Owner set to audrasjb
- Status changed from new to accepted
@audrasjb commented on PR #6480:
8 months ago
#21
Committed in https://core.trac.wordpress.org/changeset/58278
Given this task is milestoned to WordPress 6.6 on Gutenberg side, let's move this ticket to milestone 6.6 as well.