Make style book available to classic themes

[isabel_brison]

Currently the style book is attached to global styles in the site editor, which is only available to block themes. There's a discussion in ​https://github.com/WordPress/gutenberg/issues/41119 about making it available to classic themes, and ongoing work in Gutenberg.

This ticket tracks the core changes needed for this work to proceed.

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

Syncs changes from ​https://github.com/WordPress/gutenberg/pull/66851 to core.

[joemcgill]

Adding this to the 6.8 milestone, since it's being tracking in this Gutenberg issue: ​https://github.com/WordPress/gutenberg/issues/68712

[desrosj]

This should be noted in at least the miscellaneous developer note.

This has got conflicts following the change to path based site editor URLs.

As the query string parameter wasn't used and the wp_die() call removed, I am not sure this is needed anymore. But I am also not not sure.

As the query string parameter wasn't used and the wp_die() call removed, I am not sure this is needed anymore. But I am also not not sure.

This PR was never updated with the latest changes from the two Gutenberg PRs linked above. The intention is to replace the current "Patterns" submenu item under "Appearance" in classic themes with a "Design" item that leads to the site editor, where there are links to both Patterns and Style book.

Unfortunately I'm not able to update the PR with those changes at this point so would really appreciate if anyone could take this over!

The submenu item is added ​via a filter in Gutenberg, but I think in core we should be able to add it directly.

This PR is the PHP backport of ​https://github.com/WordPress/gutenberg/pull/69043.
It is not fully functional without the JavaScript changes.

In this alternative for the stylebook in classic themes, all classic themes have a menu under Appearance called Design.
Design opens the preview of the homepage, and the sidebar has two menu items: Patterns and Styles.
Styles opens the Stylebook. This stylebook is not interactive: not yet. It is a preview of the color palette, blocks etc.
In other words, there is no opt-in for the stylebook, it is available by default.

The PR enables access to the stylebook by:

• Registering a new theme support called stylebook. To enable checking for the new theme support in the Site Editor, I needed to make it available in the themes REST API endpoint, which is why I am using ​https://developer.wordpress.org/reference/functions/register_theme_feature/ with show_in_rest set to true.
• Enabling the theme support by default
• Updating the menu item under Appearance from Patterns to Design, if the theme support is enabled.

In addition, the PR updates the path to the patterns page, following the recent change to the site editor URLs.

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

### Testing Instructions
Activate any classic theme.
Go to Appearance > Design > Styles.
The Stylebook should display correctly.

Add remove_theme_support( 'stylebook' ); to the theme, for example in the themes functions.php file, in the theme setup.
Check that the Appearance menu now has Patterns instead of Design.

(This is the part that needs the JavaScript changes: When you activate the Patterns link, and go back one step, you will see that the style book is still available even though the theme support has been removed.)

There is a separate open Gutenberg Github issue and PR about users of classic themes being able to access the Site Editor if they enter the path to the screen manually:

​https://github.com/WordPress/gutenberg/issues/68950
​https://github.com/WordPress/gutenberg/pull/69005

Thanks for the additional context, @carolinan! We've already done an initial sync of editor packages to trunk, but any additional changes that have been made in the last few weeks will likely come over in the next sync. We can double check the remaining UI issues at that point.

Personally, I love this feature for classic themes, and would love to see it included in we can iron out the details so folks can hide it in contexts where it's not desired.

It hasn't been committed to Gutenberg yet.
Two people have suggested so far, that the theme support should also remove the block theme stylebook.
A final decision is needed. Or at least a decision about what to test during the beta.

What we need to decide are these two things? I might have missed something.

• Whether to enable stylebook theme support by default
• Whether to disable block theme stylebook when the stylebook theme support is disabled

For an initial commit of the underlying theme_support changes that are required (i.e., this PR), I'm happy for this to be enabled by default during the beta period. I would defer to @carolinan and the other editor leads about whether being able to opt-out by removing theme support should also remove theme support for block themes, but my gut says that the API should work consistently regardless of theme type.

This is an alternate PR to #8320, which is based on the logic currently implemented in the Gutenberg plugin from ​this PR. Specifically, the gutenberg_add_styles_submenu_item() function.

This will keep the current "Patterns" menu item when the stylebook is not supported, which deep links to the Patterns sub-menu of the site editor, but will rename the menu to "Design" and link to the site-editor index when the Stylebook is supported.

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

[joemcgill]

I've opened ​an alternate PR for this issue that syncs the logic that is currently in the GB plugin while discussion continues about the best way to handle opt-out support for this feature.

Noting for other reviewers, given that the UI changes in the site editor have already been included in the @wordpress/edit-site package that is being used in trunk, even if we decide to punt this feature, we'll need to make sure the related changes are reverted from that package to avoid shipping a broken experience.

[joemcgill]

In 59905:

Editor: Support Stylebook in the Site Editor for classic themes.

This modifies the submenu for the Site Editor which previously linked directly to the Patterns page after [58278] to support accessing the Stylebook in classic themes via a new "Design" link. Currently, any classic themes that have either added support for editor-styles or have a theme.json file will automatically see this new link in the admin menu.

Props isabel_brison, poena, wildworks, mamaduka, karmatosed, joemcgill.
Fixes #62509.

[joemcgill]

Reopening this and changing the type to continue using this to address follow-up work related to polishing the UI in the site-editor package (which will happen in a future GB sync) and possibly adjust the way "support" for this feature is being handled.

Ongoing conversation is happening in ​this Gutenberg issue

[joemcgill]

Following the updates that were synced in the latest package syncs, detailed in ​this GH comment, the current behavior whenever a theme doesn't support editor styles is that when the link in the Appearance menu says "Patterns" and links directly to the patterns screen in the site editor. When navigating back from the site editor sidebar, you are returned to the WP admin dashboard, rather than seeing the site editor root.

This can be tested by adding the following code to an mu-plugin with a classic theme activated:

<?php
add_action( 'init', function() {
    remove_theme_support( 'editor-styles' );
} );

[wildworks]

Are there any other tasks that need to be addressed on this ticket?

I think we can clothe this ticket and keep a discussion on the Gutenberg issue: ​https://github.com/WordPress/gutenberg/issues/68036

[joemcgill]

@wildworks the only reason I am keeping this open is to keep visibility on the continued conversation about adding an opt-out. I currently don't see a huge need for providing an opt-out for this part of the UI, given that we aren't allowing similar opt-outs for other parts of the site editor, although I do understand the desire to provide this kind of control.

Let's keep this open until RC1 and see if we can resolve the conversation in the meantime.

[joemcgill]

Following up here given no additional changes being suggested in the ​GB upstream issue, I'm going to close this as fixed for WP 6.8.

[JeffPaul]

Note that the dev note for this is ​drafted and part of the Miscellaneous Dev Note.

[JeffPaul]

This has now been published as a section in the ​Miscellaneous developer changes in WordPress 6.8 dev note post.