Attendees:
- Jason Adams
- Jeff Paul
- Grzegorz Ziรณลkowski
- Ovidiu Galatan
Summary
Topics Covered & Recommendations
The discussion focused on defining the structure and scope of the WordPress Core Core is the set of software required to run WordPress. The Core Development Team builds WordPress. Abilities API A core WordPress API (introduced in 6.9) that creates a central registry of capabilities, making WordPress functions discoverable and accessible to AI agents, automation tools, and developers. Transforms WordPress from isolated functions into a unified system., particularly in preparation for the WordPress 6.9 release.
CRUD Operations for Abilities: The group discussed how to handle Create, Read, Update, and Delete (CRUD) operations for post types. It was recommended to move away from a single โCRUDโ ability A registered, self-documenting unit of WordPress functionality that can be discovered and invoked through multiple contexts (REST API, Command Palette, MCP). Includes authorization and input/output specifications. for a given post type. Instead, the recommendation is to break operations into separate abilities to allow for clearer annotations (e.g., marking โdeleteโ as destructive) and to improve how AI models interact with them. Jason noted that โCreateโ and โUpdateโ could be reliably combined into a single ability, where the presence of an ID parameter would indicate an update. It was recommended that โReadโ and โDeleteโ remain separate abilities.
Handling Different Post Types: A key topic was whether to create a single set of abilities that can operate on any post type via a parameter, or to create discrete abilities for each post type. The group leaned toward recommending the creation of discrete abilities for each post type (e.g., posts, pages). This approach would avoid confusing AI models with WordPress-specific data concepts and the terminology that can arise (e.g., a โpostโ of type โpostโ).
Permissions and Security: Grzegorz highlighted the need to account for WordPressโs granular, context-aware permission levels. The current system uses a permissions callback that receives request parameters to make contextual decisions. The group also discussed the idea of an โability vetting checkโ to pre-filter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. abilities based on a userโs role to avoid exposing tools they cannot use.
Ability Organization: Namespaces and Categories: The conversation covered methods for organizing a large number of abilities, especially for AI consumption via a layered tool approach.
Namespaces: It was discussed that namespaces should be used to indicate ownership and prevent naming conflicts.
Categories: It was proposed that categories would group abilities by function. For AI, this allows a model to first request a list of categories and then request the specific abilities within a chosen category The 'category' taxonomy lets you group posts / content together that share a common bond. Categories are pre-defined and broad ranging., which prevents performance degradation as the number of abilities grows. It was recommended that categories be registered with their own descriptions so the AI can understand their purpose.
Nuances of WordPress Actions: The group noted that standard terms like โdeleteโ have special meaning in WordPress, where an item is typically moved to the trash Trash in WordPress is like the Recycle Bin on your PC or Trash in your Macintosh computer. Users with the proper permission level (administrators and editors) have the ability to delete a post, page, and/or comments. When you delete the item, it is moved to the trash folder where it will remain for 30 days. rather than being permanently deleted. The phrasing and description of abilities must be clear to explain these nuances to an AI.
Next Steps
The primary goal is to finalize the scope of the Abilities API for WordPress 6.9.
Finalize 6.9 Scope: The team needs to decide what a user should be able to accomplish with the API An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. in the 6.9 release to create a cohesive and valuable system from the start. The main tangible use case driving development is the MCP (Multi-Content Platform) adapter.
Implement Core Features for 6.9: Based on the discussion, Grzegorz recommended prioritizing two key features for the next two weeks:
- Ability Filtering: Add the functionality to query for abilities based on criteria like namespace or category.
- REST API The REST API is an acronym for the RESTful Application Program Interface (API) that uses HTTP requests to GET, PUT, POST and DELETE data. It is how the front end of an application (think โphone appโ or โwebsiteโ) can communicate with the data store (think โdatabaseโ or โfile systemโ) https://developer.wordpress.org/rest-api/. Exposure Control: Implement a flag or property that allows developers to prevent an ability from being exposed via the REST API, for abilities intended for server-side use only.
Decide on Required Categories: A decision needs to be made on whether to require a category for every ability registration in version 6.9. Jason advocated for this to ensure the system scales well with a growing number of abilities , while Grzegorz raised the concern that users might just default to an โuncategorizedโ option.
#check-in, #core-ai, #meeting
