Guidelines: Make the CPT type-aware

[gziolo]

Summary

First pass at the Phase 1 refactor from #77230: start treating wp_guideline_type as a real discriminator so that content guidelines stay where they are (Settings → Guidelines) and future skill / memory / plan types can live alongside them without interfering.

Three overlapping changes, all aimed at making the taxonomy a first-class type discriminator:

• The singleton stops being post-type-wide and becomes content-type-specific. The REST controller's singleton lookup now filters by the content term, and create_item resolves (or inserts) that term up front and passes its ID through tax_input on wp_insert_post so the assignment is atomic. A non-content wp_guideline post can exist without shadowing the content singleton or blocking its creation — the rule "only one content guideline per site" now lives at the right level of granularity. The taxonomy itself is also flipped to hierarchical, which is what makes the admin show a checkbox-style metabox plus a filter dropdown above the list table; terms stay flat in practice, hierarchy is just available for future grouping.

• The standard CPT screen becomes viable for non-content types. show_ui is flipped on and the edit screen is stripped to a plain <textarea>: block editor disabled for the post type, Add Media button removed, and both TinyMCE and Quicktags turned off via wp_editor_settings. That's enough UI to poke at skill/memory/plan storage (titles, post_content, excerpts, taxonomy terms) without building a bespoke page. Content guidelines continue to go through Settings → Guidelines.

• Manual creation no longer silently claims the content identity. The taxonomy's default_term is a new neutral artifact slug rather than content, so posts created outside the REST singleton flow land in a clearly-separate bucket. content is reserved for the one REST-managed post; a list column (show_admin_column) surfaces each post's term so the distinction is visible at a glance.

Why the standard CPT screen (for now)

The dedicated Settings → Guidelines page is tightly coupled to the content-guidelines REST shape (singleton + guideline_categories object). Teaching the existing controller to also serve skill/memory/plan posts with standard post fields is a non-trivial refactor (explicitly called out as future consideration in #77230).

Reusing the standard CPT edit screen is cheap and unblocks the experimentation phase — it gives us a way to poke at non-content storage without touching the REST controller yet.

Note: no menu link is added. The edit screen is reached via direct URL (wp-admin/edit.php?post_type=wp_guideline, post-new.php?post_type=wp_guideline) — intentional, since we don't want a guidelines menu entry competing with Settings → Guidelines in the UI.

Follow-ups worth discussing

• Enforcing one wp_guideline_type term per post. Nothing in this PR stops a client from assigning multiple terms. wp_template handles the equivalent concern by hiding its taxonomy from REST and always writing a single scalar from the controller — we could follow the same pattern, or add a custom metabox / save-time guard for the admin path.
• Restricting admin access for content-typed posts. Once non-content types settle in, we may want post.php and post-new.php to refuse content-typed URLs (mirroring show_ui => false semantics) so Settings → Guidelines remains the single edit surface for that identity.

Test plan

• composer test passes locally
• Activate the gutenberg-guidelines experiment, visit Settings → Guidelines — editing continues to work as before
• Seed a non-content wp_guideline post and confirm it does not affect the singleton GET/POST behaviour for content Guidelines
• Visit post-new.php?post_type=wp_guideline — confirm the stripped-down classic editor renders without toolbars or Add Media, and the saved post lands with the artifact term
• Visit edit.php?post_type=wp_guideline — confirm the "Guideline Types" column is present, shows each post's term, and the filter-by-type dropdown above the list table works

🤖 Generated with Claude Code

[github-actions]

Flaky tests detected in 8eef495.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/24706273412
📝 Reported issues:

• [Flaky Test] post title and content are editable and blocks can be inserted #76524 in /test/e2e/specs/editor/various/post-content-focus-mode.spec.js

[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: gziolo <gziolo@git.wordpress.org>
Co-authored-by: aagam-shah <aagam94@git.wordpress.org>

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

[aagam-shah]

Thanks for working on this @gziolo, looks good overall.

One thing worth flagging: show_ui => true on wp_guideline_type means admins can reach the Guideline Types screen and delete the content term. If that happens, get_guidelines_post() returns nothing and Settings → Guidelines shows empty state even though the post still exists. Note that wp_template / wp_theme keep their type taxonomy with show_ui => false for this reason. Fine to handle in a follow-up.

[gziolo]

That’s an important consideration @aagam-shah. I didn’t took that into account.

I explained that the UI affordance is rather temporary for the time this feature is an experimental. How could we mitigate the risk of user breaking the saved content guidelines? They definitely can use revision history so maybe we could display a notice when certain operations happen? At the same time, if we continue refactoring and split content type into more documents, the problem would disappear completely.

[luisherranz]

I just cherry-picked this PR to the release/23.0 branch to get it included in the next release: e486a79