{"id":123989,"date":"2026-06-22T07:46:17","date_gmt":"2026-06-22T07:46:17","guid":{"rendered":"https:\/\/make.wordpress.org\/core\/?p=123989"},"modified":"2026-06-29T09:07:06","modified_gmt":"2026-06-29T09:07:06","slug":"merge-proposal-guidelines-built-on-knowledge","status":"publish","type":"post","link":"https:\/\/make.wordpress.org\/core\/2026\/06\/22\/merge-proposal-guidelines-built-on-knowledge\/","title":{"rendered":"Merge Proposal: Guidelines built on Knowledge"},"content":{"rendered":"

We propose merging Knowledge, a new wp_knowledge<\/code> custom post typeCustom Post Type<\/span> WordPress can hold and display many different types of content. A single item of such a content is generally called a post, although post is also a specific post type. Custom Post Types gives your site the ability to have templated posts, to simplify the concept.<\/span><\/span><\/span>, into WordPress coreCore<\/span> Core is the set of software required to run WordPress. The Core Development Team builds WordPress.<\/span><\/span><\/span> for the 7.1 release, with Guidelines as the first feature built on it.<\/p>\n\n\n\n

Knowledge is a general primitive for storing author-facing and agent-facing site knowledge as standard WordPress content: a post type with a type taxonomyTaxonomy<\/span> A taxonomy is a way to group things together. In WordPress, some common taxonomies are category, link, tag, or post format. https:\/\/codex.wordpress.org\/Taxonomies#Default_Taxonomies<\/a>.<\/span><\/span><\/span>, the existing roles and capabilitiescapability<\/span> A\u00a0capability<\/strong>\u00a0is permission to perform one or more types of task. Checking if a user has a capability is performed by the current_user_can<\/code> function. Each user of a WordPress site might have some permissions but not others, depending on their\u00a0role. For example, users who have the Author role usually have permission to edit their own posts (the \u201cedit_posts\u201d capability), but not permission to edit other users\u2019 posts (the \u201cedit_others_posts\u201d capability).<\/span><\/span><\/span>, native revisionsRevisions<\/span> The WordPress revisions system stores a record of each saved draft or published update. The revision system allows you to see what changes were made in each revision by dragging a slider (or using the Next\/Previous buttons). The display indicates what has changed in each revision.<\/span><\/span><\/span>, and REST access. Guidelines uses it to give site owners a first-class place to capture the standards that shape how content is written and edited, such as voice, tone, image preferences, and per-blockBlock<\/span> Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience.<\/span><\/span><\/span> rules.<\/p>\n\n\n\n

The implementation is operational in the GutenbergGutenberg<\/span> The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses \u2018blocks\u2019 to add richness rather than shortcodes, custom HTML etc.\rhttps:\/\/wordpress.org\/gutenberg\/<\/a><\/span><\/span><\/span> pluginPlugin<\/span> A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https:\/\/wordpress.org\/plugins\/<\/a> or can be cost-based plugin from a third-party.<\/span><\/span><\/span> and has been exercised by production integrations. It builds on the Guidelines experiment, proposed<\/a> in February and landed in Gutenberg 22.7<\/a> in March, then shaped through community feedback into a consolidated design<\/a> and stabilized for core.<\/p>\n\n\n\n

Purpose & goals<\/h2>\n\n\n\n

Most sites already have content standards, but they live outside WordPress in documents, wikis, and institutional knowledge. Guidelines gives them a canonical home inside WordPress, available where they matter: during writing and editing.<\/p>\n\n\n\n

A single store of standards serves everyone who works on a site: writers and editors applying them by hand, plugins reading them, and AI assistants drawing on them too. Each of these needs the same thing, persistent and structured knowledge about the site, and today there is no shared place to keep it. Without a common primitive, every plugin ships its own storage, its own permissions model, and its own REST surface. That is exactly the kind of fragmentation WordPress core has historically prevented, the same way wp_template<\/code>, wp_block<\/code>, and nav_menu_item<\/code> prevented parallel solutions in their domains. Core owns the primitive. The community decides what to build on it.<\/p>\n\n\n\n

The name follows that intent. \u201cGuideline\u201d describes prescriptive records well but fits memories and working notes much less naturally, while \u201cKnowledge\u201d covers both procedural content (how work should be done) and declarative content (what is known). Knowledge names the namespace. Individual records are referred to by their concrete type, a guideline, a memory, a note. The user-facing feature in WP Adminadmin<\/span> (and super admin)<\/span><\/span><\/span> remains Guidelines, the same way the attachment<\/code> post type surfaces as Media at \/wp\/v2\/media<\/code>.<\/p>\n\n\n\n

The goals, concretely:<\/p>\n\n\n\n