Registers wp_guideline_type taxonomy

[iamchughmayank]

What?

Follow-up to #77147

Registers a wp_guideline_type taxonomy on the guidelines CPT, following the wp_template + wp_theme pattern from core. Uses default_term to seed content as the default type.

Why?

As discussed in the Guidelines announcement comments, the CPT is evolving to support different document types beyond site-wide editorial guidelines. A taxonomy cleanly separates these types within the same CPT, enabling REST-based discovery and filtering — the same approach core uses with wp_template and wp_theme.

How?

• Adds a TAXONOMY constant to Gutenberg_Content_Guidelines_Post_Type
• Calls register_taxonomy() inside the existing register() method, right after register_post_type()
• Uses default_term to auto-create and assign the content term (handled by core, no per-request queries)
• Taxonomy is non-public, show_in_rest = true, registration trimmed to match core peers (wp_theme, wp_pattern_category)

No changes to the REST controller, singleton behavior, or client-side code.

Testing Instructions

Setup

1. npm run wp-env start
2. Enable the Content Guidelines experiment in Settings > Experiments

Taxonomy verification

3. Visit http://localhost:8888/wp-json/wp/v2/wp_guideline_type — should return one term: content
4. Visit http://localhost:8888/wp-json/wp/v2/taxonomies/wp_guideline_type — should return the taxonomy definition attached to the guidelines CPT

Regression

5. Navigate to Settings > Content Guidelines
6. Add text in the Copy and Images fields, click Save
7. Refresh the page — verify saved guidelines load correctly
8. Export guidelines as JSON — verify the file downloads
9. Import the JSON back — verify it applies
10. Check revision history — verify revisions are listed

Testing Instructions for Keyboard

No special case for keyboard required.

Screenshots or screencast

No visual changes expected.

Use of AI Tools

Claude Code used for planning, review feedback implementation, and PR description updates.

[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: iamchughmayank <iamchughmayank@git.wordpress.org>
Co-authored-by: aswasif007 <aswasif007@git.wordpress.org>
Co-authored-by: gziolo <gziolo@git.wordpress.org>

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

[gziolo]

Before landing this, I'd like to align on direction. I don't think the taxonomy is quite ready to wire in yet.

As things stand, wp_guideline is a strict singleton. create_item() errors on a second post, the route is a singleton GET + create, post_content is never touched, and all payload lives in post meta keyed by category. Given those constraints, the post-meta choice made sense. @swissspidy's question in the Guidelines announcement thread and @aagam-shah's revision-atomicity answer describe exactly the tradeoff that shaped this.

But that tradeoff was built around "one document per site." Introducing content / skill / memory / plan either:

1. Classifies the singleton. In this case only content really applies today, and seeding the other three creates terms no post can ever attach to.
2. Breaks the singleton. In this case get_guidelines_post(), create_item(), the schema, and the category model all need to become type-aware, and this PR is step 1 of a larger refactor that isn't scoped here.

The current PR doesn't commit to either, and nothing in the REST controller actually reads from the taxonomy.

Two questions for the Guidelines team:

1. Is this CPT still a singleton after this change?
2. If not, is there a tracked plan for the follow-up work (type-scoped fetch/create, per-type category schema)?

I think @swissspidy's angle is worth revisiting here. The community instinct that classification belongs in taxonomies is pointing at a real architectural limit, and this PR is the moment it starts to show. Happy to help sketch a direction or open a design issue once we agree.

[iamchughmayank]

Before landing this, I'd like to align on direction. I don't think the taxonomy is quite ready to wire in yet.

As things stand, wp_guideline is a strict singleton. create_item() errors on a second post, the route is a singleton GET + create, post_content is never touched, and all payload lives in post meta keyed by category. Given those constraints, the post-meta choice made sense. @swissspidy's question in the Guidelines announcement thread and @aagam-shah's revision-atomicity answer describe exactly the tradeoff that shaped this.

But that tradeoff was built around "one document per site." Introducing content / skill / memory / plan either:

1. Classifies the singleton. In this case only content really applies today, and seeding the other three creates terms no post can ever attach to.
2. Breaks the singleton. In this case get_guidelines_post(), create_item(), the schema, and the category model all need to become type-aware, and this PR is step 1 of a larger refactor that isn't scoped here.

The current PR doesn't commit to either, and nothing in the REST controller actually reads from the taxonomy.

Two questions for the Guidelines team:

1. Is this CPT still a singleton after this change?
2. If not, is there a tracked plan for the follow-up work (type-scoped fetch/create, per-type category schema)?

I think @swissspidy's angle is worth revisiting here. The community instinct that classification belongs in taxonomies is pointing at a real architectural limit, and this PR is the moment it starts to show. Happy to help sketch a direction or open a design issue once we agree.

Thanks for flagging this @gziolo

1. Is this CPT still a singleton after this change?
   This PR registers the taxonomy but doesn't touch the REST controller, so the singleton enforcement in create_item and get_guidelines_post() should remain unchanged.

2. If not, is there a tracked plan for the follow-up work (type-scoped fetch/create, per-type category schema)?

We do have planned task is to relax the singleton constraint for non-content guideline types. The scope is:

• Keep singleton behavior for content type — the existing UI, meta structure stay the same.
• Allow multiple posts for skill, memory, and plan types
• Each post has independent revision history via native WordPress revisions

I believe that either we can:

1. Land this PR which will not have any behavioural change.
2. I can create the PR for the relaxation of singleton constraint and bundle this taxonomy PR along with it for completeness.

Do you have recommendations on this?

[gziolo]

Adding a couple more core examples where taxonomies enable classification or coexistence of multiple posts inside a single CPT:

• wp_pattern_category on wp_block. Hierarchical, show_in_rest => true, classifies reusable patterns within one CPT.
• nav_menu on nav_menu_item. Each term is a menu, and menu items are grouped under a specific term. A single CPT supports many coexisting documents via taxonomy.

With a hierarchical taxonomy, the organization could fall out naturally:

guideline
├── content
│   ├── copy
│   ├── images
│   ├── site
│   └── additional
├── skill
└── plan

One post per leaf term, with the parent chain encoding both the document kind and its internal category. The categories currently stored as post meta become child terms of content, and kinds like skill or plan live as siblings of content. A single taxonomy handles both axes, no singleton constraint, room to grow.

Keep singleton behavior for content type — the existing UI, meta structure stay the same.

Yes, we could embed that for the content group.

[aswasif007]

term_exists() issues a SELECT per term on every init call. With four terms this adds four queries per page load site-wide when the experiment is enabled. This compounds on high-traffic sites.

Is there a way to make it a one-time seeding operation, instead of per-request?

[iamchughmayank]

Thanks for flagging this, Wasif. I have tried to do one-time operation of seeding in 7abff2c. Happy to seek advice on having a better way.

[gziolo]

Two suggestions to simplify and sidestep the seeding question:

1. Use default_term instead of manual seeding. register_taxonomy() accepts a default_term arg (since WP 5.5) — core handles term_exists() + wp_insert_term() internally and stores the result in default_term_{taxonomy}. Seed only content, so the existing singleton post implicitly classifies as content with zero controller changes. The other three (skill, memory, plan) shouldn't exist until something actually creates a post of that type. We can add lazy creation in the follow-up when needed. This lets us delete the seeding block, the wp_guideline_type_terms_seeded option, and VALID_TYPES as a seed source.

2. Trim the registration to match core peers (wp_theme, wp_template_part_area, wp_pattern_category):

• Drop rest_base — core peers accept the default (/wp/v2/wp_pattern_category, not kebab).
• Drop the capabilities block — the post type already gates edits on manage_options, so terms can't be assigned to posts the user can't edit.
• Drop show_in_menu — redundant with show_ui => false.
• Add show_in_nav_menus => false to match the core idiom.

register_taxonomy(
    self::TAXONOMY,
    self::POST_TYPE,
    array(
        'public'             => false,
        'publicly_queryable' => false,
        'hierarchical'       => false,
        'labels'             => array(
            'name'          => __( 'Guideline Types', 'gutenberg' ),
            'singular_name' => __( 'Guideline Type', 'gutenberg' ),
        ),
        'query_var'          => false,
        'rewrite'            => false,
        'show_ui'            => false,
        'show_in_nav_menus'  => false,
        'show_in_rest'       => true,
        'default_term'       => array(
            'name' => 'content',
            'slug' => 'content',
        ),
    )
);

[gziolo]

@copilot resolve the merge conflicts in this pull request