Editor: enable notes on the global styles post type

[adamsilverstein]

Claude did most of the write up here, forwarded along with some edits:

Notes as they shipped in 6.9 anchor twice: to a post, through comment_post_ID, and within that post to a block, through that block's own metadata.noteId attribute. A surface with neither is out of reach today.

The Style Book is exactly that surface. It has no post of its own, and its examples are generated fresh on every render, so there is no persisted block to record a note id on. Feedback on a theme's styles - "these headings feel tight", "this button needs more contrast" - currently has nowhere to live, and reviewing a theme's styles is one of the places a review conversation is most useful.

See ​https://github.com/WordPress/gutenberg/issues/73278 for the feature request and the discussion behind it.

Proposed change

Two small additions, neither of which changes existing behavior:

1. wp_global_styles declares notes support, by way of 'editor' => array( 'notes' => true ) in create_initial_post_types(). The theme's user global styles post is the record the Styles UI already edits, which makes it the natural home for feedback about that theme's styles.

2. A new _wp_note_anchor comment meta, registered in wp_create_initial_comment_meta(). A single string that the anchoring surface defines and resolves, sanitized with sanitize_text_field and capped at 100 characters. Core never interprets it.

For the Style Book the anchor holds the example name - core/button, typography, theme-colors. Those names are deterministic and stable across sessions, users and reloads, which block client ids are not.

Nothing in core reads the anchor. This is the storage half; the UI lives in Gutenberg.

Consequences worth stating

• Notes on global styles inherit that post type's capabilities, so writing one requires edit_theme_options. On most sites that means administrators only.
• Core keeps one global styles post per theme, so the notes are theme-specific. Switching themes shows a different set; switching back brings the original notes with it. That seems right given the styles being reviewed are themselves theme specific, but it is a semantic worth confirming.

Patches

• Core: ​https://github.com/WordPress/wordpress-develop/pull/13030
• Gutenberg (the UI, plus the same two registrations as a wordpress-7.2 compat file): ​https://github.com/WordPress/gutenberg/pull/81554

Questions

1. Should _wp_note_anchor be a flat string, or namespaced from day one - eg. stylebook:core/button - to leave room for other anchor domains such as template areas or theme.json paths? The meta is a string either way, so a namespaced scheme could be layered on later without a migration.
2. Is edit_theme_options the intended audience, or is there appetite for letting lower roles view but not write these notes? That would need a capability mapping change and is not part of this patch.
3. Is theme-specific the right semantic to ship, with the switching behavior documented?

## Trac ticket: https://core.trac.wordpress.org/ticket/65872

---

The core half of Style Book notes. Gutenberg PR: ​https://github.com/WordPress/gutenberg/pull/81554, which fixes ​https://github.com/WordPress/gutenberg/issues/73278.

Notes as they shipped in 6.9 anchor twice: to a post, through comment_post_ID, and within that post to a block, through the block's own metadata.noteId attribute. A surface with neither is out of reach today. The Style Book is exactly that surface - it has no post of its own, and its examples are generated fresh on every render, so there is no persisted block to record a note id on.

Two small additions cover it.

wp_global_styles declares notes support. The theme's user global styles post is the record the Styles UI already edits, so it is the natural home for feedback about that theme's styles. Nothing else about the post type changes.

A _wp_note_anchor comment meta. A single string the anchoring surface defines and resolves, sanitized with sanitize_text_field and capped at 100 characters. Core never interprets it. For the Style Book it holds the example name - core/button, typography, theme-colors - which is deterministic and stable across sessions, users and reloads in a way block client ids are not.

Nothing in core reads the anchor yet. This is the storage half; the UI lives in the Gutenberg PR above.

Two consequences worth stating plainly, since neither is obvious from the diff:

• Notes on global styles inherit that post type's capabilities, so writing one requires edit_theme_options. On most sites that means administrators only.
• Core keeps one global styles post per theme, so these notes are theme-specific. Switching themes shows a different set; switching back brings the original notes with it.

## How has this been tested

tests/phpunit/tests/rest-api/rest-global-styles-notes.php adds 17 tests:

• the support shape WP_REST_Comments_Controller::check_post_type_supports_notes() actually reads, and post_type_supports( 'wp_global_styles', 'editor' ) still returning true
• the anchor meta registration and its REST exposure
• REST create and list against the global styles post, with the anchor round-tripping through the response and into comment meta
• 403 for an author and 401 for anonymous, on both read and write
• anchor sanitization, and the length cap rejecting rather than truncating
• post types without notes support still being refused, so this did not widen the gate

Manual testing needs the Gutenberg PR for the UI. Its description has the steps.

## Types of changes

• Add 'editor' => array( 'notes' => true ) to the wp_global_styles supports in create_initial_post_types().
• Register a _wp_note_anchor comment meta in wp_create_initial_comment_meta().
• Add tests covering both.

## Checklist:

• [x] My code is tested.
• [x] My code follows the WordPress code standards.
• [x] My code follows the accessibility standards.
• [x] My code has proper inline documentation.
• [ ] I've included developer documentation if appropriate.
• [x] I've updated all @since references.

## AI Use

Code and description both written with 🤖 Claude Code. I will review and test.