![(please configure the [header_logo] section in trac.ini)](/chrome/site/your_project_logo.png){kind=logo}
Opened 4 weeks ago
Last modified 2 days ago
#65476 assigned feature request
Introduce Knowledge custom post type
| Reported by: | gziolo | Owned by: | gziolo |
|---|---|---|---|
| Priority: | normal | Milestone: | 7.2 |
| Component: | Posts, Post Types | Version: | trunk |
| Severity: | normal | Keywords: | has-patch has-unit-tests gutenberg-merge |
| Cc: | Focuses: |
Description (last modified by )
Summary
Introduce the Knowledge concept: a wp_knowledge custom post type with a type taxonomy, a capability namespace, and a REST surface, providing a canonical store for author-facing and agent-facing site knowledge. Guidelines is the first feature built on it, giving site owners a place to capture content standards such as voice, tone, image guidance, and per-block rules.
This has been developed as an experiment in the Gutenberg plugin and was proposed for merge in WordPress 7.1, but postponed to 7.2 or later.
Motivation
Sites accumulate standards and context that today live outside WordPress in documents, wikis, and institutional knowledge. As plugins and integrations need persistent, structured knowledge about a site, each one tends to ship its own storage, permissions model, and REST surface. A shared core primitive prevents that fragmentation, the same way wp_template, wp_block, and nav_menu_item did in their domains.
The feature ships storage and access only. It includes no AI provider, model, retrieval algorithm, or memory architecture.
Scope
Proposed for this ticket:
wp_knowledgepost type, registered as internal (public => false,publicly_queryable => false), with revision supportwp_knowledge_typetaxonomy and awp_knowledge_typesregistration filter- Built-in types:
guideline– a standard such as voice, tone, or per-block rules, applied directly or loaded in the matching contextnote– private freeform working text such as drafts and synced notes
*_knowledgecapability namespace and access policy (private, author-owned by default; administrators manage site-wide records)/wp/v2/knowledgeREST routes
Out of scope for this ticket:
- Further built-in types, deferred and registerable by plugins in the meantime:
memory– durable context a user explicitly saved, such as preferences or stable factsskill– a procedure that can load and apply a guideline, planned for 7.2 pending settled loading and discovery semanticsplan– task-scoped working state, pending a side-effect and lifecycle modelartifact– a reference to a versioned work product distinct from the freeform text covered bynote, explored separately
- The knowledge management ability (Abilities API), proposed for a later release
- Decay, consolidation, retrieval, and encryption at rest
Access model
Records are not exposed as a public index. Collection reads require authentication, per-item reads are capability-checked through read_post, and non-publishers may only create private records.
| Role | Site-wide guideline records | Own private records | Others' private records | Manage global records |
|---|---|---|---|---|
| Subscriber | No | No | No | No |
| Contributor | Read where caps allow | CRUD | No | No |
| Author / Editor | Read where caps allow | CRUD | No | No |
| Administrator | Manage | Yes | Yes | Yes |
Type and scope registration are code-level extension points. User roles control access to records, not the registration of types or scopes.
Related
- Gutenberg tracking issue: https://github.com/WordPress/gutenberg/issues/75171
- Type model discussion: https://github.com/WordPress/gutenberg/issues/77230
- Rename PR (Gutenberg): https://github.com/WordPress/gutenberg/pull/79149
- Merge proposal: https://make.wordpress.org/core/2026/06/22/merge-proposal-guidelines-built-on-knowledge/
Change History (16)
This ticket was mentioned in PR #12201 on WordPress/wordpress-develop by @gziolo.
4 weeks ago
#4
- Keywords has-patch has-unit-tests added
@jorgefilipecosta commented on PR #12201:
4 weeks ago
#5
Knowledge, is something done mostly though for LLMS, similar to abilities, I wonder if for knowledge we avoid a specific REST endpoint and we just use abilities as the interface to manage the knowledge everywhere? Instead of calling REST we would always call the abilities.
@jorgefilipecosta commented on PR #12201:
4 weeks ago
#6
Great work here, things look, just left some comments for considering but it seems to be on a good shape.
@gziolo commented on PR #12201:
4 weeks ago
#7
Thanks for the thorough review @jorgefilipecosta and @peterwilsoncc 🙏 I've pushed updates addressing the inline feedback — capability naming (plural/singular bases), the trash → permanent-delete gap for contributors, the rest_cannot_read alignment, dropping the no-op show_admin_column, and additional permission test coverage. Replies are on the individual threads.
On the abilities vs. dedicated REST endpoint question:
I wonder if for knowledge we avoid a specific REST endpoint and we just use abilities as the interface to manage the knowledge everywhere?
I'd like to defer this. Whether a feature is exposed through a REST endpoint or through abilities feels like a higher-level call that should be made as a general policy — *when* do we add a REST endpoint vs. an ability — rather than settled per-PR here. For this PR I followed the existing convention of registering a REST controller for the new post type, as we do for other post types. An abilities-based interface would in practice replicate similar logic (capability checks, validation, sanitization), so it's a parallel direction we can evaluate later rather than a blocker for landing this foundation.
This ticket was mentioned in Slack in #core-ai by gziolo. View the logs.
4 weeks ago
#10
@
3 weeks ago
Merge proposal is now published at https://make.wordpress.org/core/2026/06/22/merge-proposal-guidelines-built-on-knowledge/.
#13
@
5 days ago
Due to an issue with Trac, we are unable to change the milestone. However, I would like to note that it has been decided not to include this feature in version 7.1.
@gziolo commented on PR #12201:
3 days ago
#15
Status update
Following the feedback on the merge proposal (Guidelines built on Knowledge), this work is postponed to WordPress 7.2 or later. The @since tags in this PR now point to 7.2.0.
The memory type has also been removed from the default wp_knowledge_types() list until it has a matching implementation. The built-in types are now guideline and note. Plugins can still add their own types through the wp_knowledge_types filter.
## Summary
Introduces
wp_knowledge, a private-by-default custom post type that acts as a storage primitive for structured site knowledge (guidelines, memories, notes), along with itswp_knowledge_typetaxonomy and a dedicated REST controller.This is the WordPress core counterpart to the Knowledge storage primitive being explored in Gutenberg (WordPress/gutenberg#79149). It deliberately lands the storage primitive only — the Guidelines admin UI and the
content-guidelinessingleton remain consumer-side concerns and are out of scope here.## Details
wp_knowledgeandwp_knowledge_typeare registered as built-ins increate_initial_post_types()/create_initial_taxonomies(). Both are non-public and headless (show_ui => false); rows are managed via the REST API rather than a wp-admin screen.WP_REST_Knowledge_Controllerserves/wp/v2/knowledge. Reads require an authenticated user with the read capability, collection queries are scoped to rows the current user can read (so totals/pagination respect per-user visibility), callers without the publish capability are limited to theprivatestatus, and new rows default toprivate. Revision history uses the default revisions controller; autosave endpoints are disabled (following thewp_global_stylesprecedent), since knowledge has no editor session.user_has_capfilter (wp_maybe_grant_knowledge_caps()), matching the existingwp_maybe_grant_*pattern. Administrators manage all knowledge; contributors and above may create and fully manage their own private rows. Subscribers and anonymous users are blocked at the post-type door.wp_knowledge_types()exposes a filterable set of types (guideline,memory,note); rows saved without a type fall back to thenoteterm.## Testing
New unit tests cover registration, the capability matrix across all roles, the REST controller (CRUD, permission gating, private-by-default), and the type registry. The REST route snapshot in
tests/phpunit/tests/rest-api/rest-schema-setup.phpis updated accordingly.🤖 Generated with Claude Code