This week’s AI contributor meeting covered five plugin 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/ or can be cost-based plugin from a third-party. releases, a revised implementation strategy for embedding support, and a proposed CRUD-style structure for WordPress abilities. The group also discussed the WordPress 7.1 release taking place later that day at WordCamp WordCamps are casual, locally-organized conferences covering everything related to WordPress. They're one of the places where the WordPress community comes together to teach one another what they’ve learned throughout the year and share the joy. Learn more. US and plans to review Contributor Day Contributor Days are standalone days, frequently held before or after WordCamps but they can also happen at any time. They are events where people get together to work on various areas of https://make.wordpress.org/ There are many teams that people can participate in, each with a different focus. https://make.wordpress.org/support/handbook/getting-started/getting-started-at-a-contributor-day/ and Prompt Bar feedback once more attendees have returned.
Plugin and Release Updates
The team shipped five plugin releases over two days:
The connector releases were tested for compatibility with WordPress 7.1 and included a mixture of minor updates and major version changes. Some embedding support remains unmerged in the connector plugins. The team plans to revisit that work so contributors can test embedding functionality across multiple providers, including locally hosted models.
The AI plugin has also moved from its earlier two-week release cycle to a roughly monthly cadence. Future releases will therefore likely include larger changelogs.
WordPress 7.1 was scheduled to be released later that day at WordCamp US. The group deferred a broader discussion of the event’s Contributor Day work and feedback collected at the AI Team’s Prompt Bar until next week.
Embedding Support Implementation
@dkotter proposed breaking the embedding work into smaller, independently reviewable pull requests rather than combining the underlying architecture and user-facing features into large feature PRs.
The proposed sequence includes separate work for:
- Embedding support from the PHP PHP (recursive acronym for PHP: Hypertext Preprocessor) is a widely-used open source general-purpose scripting language that is especially suited for web development and can be embedded into HTML. https://www.php.net/manual/en/index.php AI Client
- The storage and CRUD layer for embeddings
- Background synchronization and large-scale processing
- Low-level similarity and calculation utilities
- Individual features, such as semantic search, built on top of that foundation
These PRs should generally be able to branch independently from the development branch and be merged separately. Contributors may still stack related PRs when an implementation dependency makes that more practical.
Local models, e.g. Ollama, are particularly useful for testing this work. Embeddings generally only need to be regenerated when the source content changes, and calculations using the resulting data do not require continued requests to an AI provider An AI service offering models for generation, embeddings, or other capabilities (e.g., Anthropic, Google, OpenAI).. This makes much of the workflow testable without ongoing provider 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. costs.
DECISION: Implement the embedding foundation through smaller, independent pull requests before building additional features on top of it.
Proposed Abilities Structure
@jorgefilipecosta shared an updated direction for abilities following feedback on the earlier merge proposal.
Passing requests directly through the 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/ may still be useful as a temporary prototyping approach, but the group does not consider it the appropriate long-term architecture. The team will instead try a CRUD-style structure with separate abilities such as:
core/content-query
core/content-create
core/content-update
core/content-delete
Keeping these operations separate allows each 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. to carry more accurate annotations, including whether it is read-only or performs a destructive action. “Query” is being considered instead of “read” for entities such as content and users that support complex filtering. Simpler retrieval operations, such as getting settings or environment information, could continue to use “get.”
The current goal is for this abilities pattern to become part of WordPress Core Core is the set of software required to run WordPress. The Core Development Team builds WordPress. in 7.2. Before then, the AI plugin may use polyfills to test the structure and prepare for the Core implementation.
The team also agreed that experimental abilities previously shipped in the plugin do not need to retain backward compatibility indefinitely. They can follow a standard deprecation cycle, with notices retained for a limited number of plugin releases before obsolete code is removed.
This direction is not considered set in stone. The proposed structure will be documented publicly so contributors can raise concerns before a larger set of abilities is implemented.
Links related to the conversation:
DECISION: Proceed with implementing and testing the CRUD-style abilities pattern, subject to public review and continued feedback.
Next Steps
- @jeffpaul will open a tracking issue with a checklist covering the separate embedding-support pull requests.
- @jeffpaul will identify related open PRs and flag opportunities for contributors to help divide them into smaller units.
- Follow up with @jason_the_adams on the PHP AI Client embedding work and any additional architectural feedback.
- Complete embedding model declarations or support in connector plugins where it remains missing.
- @jorgefilipecosta will document the proposed abilities structure publicly and invite further feedback.
- Review existing abilities PRs against the new structure and ask their authors to update them where appropriate. PRs that cannot be updated may be closed.
- Revisit the work completed at WordCamp US Contributor Day and feedback collected through the Prompt Bar.
Upcoming Meetings
Props to @ekamran for pre-publish review.
#core-ai, #summary
Related