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 <[email protected]>
Co-authored-by: aswasif007 <[email protected]>
Co-authored-by: gziolo <[email protected]>

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

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.

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?

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.

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',
        ),
    )
);

@copilot resolve the merge conflicts in this pull request