Moves "Patterns" command to site editor main navigation

[bacoords]

What?

As a follow up to this comment, this PR moves the "Patterns" Command from admin-navigation-commands to site-editor-navigation-commands.

Why?

The cleans up the code needed for the admin commands file as well as provides consistency in the navigation experience. Now the initial list of commands exactly matches the global navigation in the site editor.

It's worth noting that this removes the command from non-administrator users, even if they could technically access edit.php?post_type=wp_block and be directed there.

That said there are a number of commands that should be added for non-admin users that could send them to the non-site editor screens and that's really outside the scope of this PR.

How?

Testing Instructions

1. Open the site editor.
2. Click cmd-k to trigger the Command Palette
3. Start searching for Patterns
4. Select Patterns and confirm you're navigated to the correct screen

Testing Instructions for Keyboard

Screenshots or screencast

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

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: bacoords <[email protected]>
Co-authored-by: t-hamano <[email protected]>

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

[t-hamano]

Thanks for the PR!

I think the original Patterns command was available to all themes and to all users. With this PR, if you cannot access the site editor or are not using a block theme, you will not be able to use the Patterns commands.

My understanding is that this PR is a refactoring and I think the previous behavior should be fully preserved.

In my opinion, we need an approach like below.

function useSiteEditorBasicNavigationCommands() {
	const commands = useMemo( () => {
		const result = [];

		if ( isTemplatesAccessible && isBlockBasedTheme ) {
			// Command for when the current theme is a block theme and the user has access to the site editor
			Navigation, Styles, Pages, Templates
		}

		result.push( {
			...
			callback: ( { close } ) => {
				// First, check if the current user has access to the site editor.
				if ( isTemplatesAccessible ) {
					const args = {
						path: '/patterns',
					};
					if ( isSiteEditor ) {
						// If you are already in the site editor
						history.push( args );
					} else {
						// If you are outside the site editor
						document.location = addQueryArgs( 'site-editor.php', args );
					}
					close();
				} else {
					// If a user cannot access the site editor
					document.location.href = 'edit.php?post_type=wp_block';
				}
			},
		} );

		return result;
	}, [] );

	return {
		commands,
		isLoading: false,
	};
}

[t-hamano]

Suggested change

	name: 'core/manage-reusable-blocks',
	name: 'core/edit-site/open-patterns',

There are no hard and fast rules regarding this property, but it is a good idea to make it consistent with other commands.

[bacoords]

Thanks for the feedback @t-hamano ! I've updated the PR but the main issue I've had is that .canUser( 'read', 'templates' ) was returning true for "Editor" level users in the block editor so they were sent to the Site Editor, (perhaps because they're able to "read" and pull in the templates for the template switching and preview functionality)?

I added an additional hook based on .canUser( 'create', 'templates' ) to better determine if the user is able to open the site editor or should be sent to the original admin screen for Patterns, but would love some testing on this.

[t-hamano]

the main issue I've had is that .canUser( 'read', 'templates' ) was returning true for "Editor" level users in the block editor so they were sent to the Site Editor

After researching this issue, I believe that returning true is an unintended regression. See #61419.

I think we need to fix this permission issue before this PR and #61287.

[t-hamano]

An issue with user permissions was fixed in #61444. Could you rebase this branch with the latest trunk?

[t-hamano]

Based on this discussion, it seems better not to create custom hooks. You will only need to check whether it is possible to create a template, as shown below.

const canCreateTemplate = useSelect( ( select ) => {
	return select( coreStore ).canUser( 'create', 'templates' );
}, [] );

[bacoords]

Thanks - this makes sense and uses the same canCreateTemplate value to determine whether the user should be sent to the classic admin screen for patterns or to the site editor's Pattern screen.

[bacoords]

Could you rebase this branch with the latest trunk?

This has been rebased.

[t-hamano]

LGTM! All commands are working as before.

Admin, Block theme

• Navigation, Styles, Pages, Templates: displayed
• Patterns: wp-admin/site-editor.php?path=/patterns

Editor, Block theme

• Navigation, Styles, Pages, Templates: Not displayed
• Pattern: > wp-admin/edit.php?post_type=wp_block

Admin, Classic theme

• Navigation, Styles, Pages, Templates: Not displayed
• Pattern: > wp-admin/site-editor.php?path=/patterns

Editor, Classic theme

• Navigation, Styles, Pages, Templates: Not displayed
• Pattern: > wp-admin/edit.php?post_type=wp_block