#64455: WordPress Core Abilities
------------------------------+---------------------
Reporter: jorgefilipecosta | Owner: (none)
Type: enhancement | Status: new
Priority: normal | Milestone: 7.0
Component: AI | Version:
Severity: normal | Resolution:
Keywords: has-patch | Focuses:
------------------------------+---------------------
Comment (by jorgefilipecosta):
Hi @peterwilsoncc, thank you a lot for having a look into both post
management PRs. The security issues you found in comment #11 were in the
original PR, which was using a different approach. That PR's development
had stopped before we added guardrails about which posts and meta to
expose. It is now closed as you recommended, sorry for not closing it
sooner. The current approach in
https://github.com/WordPress/gutenberg/pull/74234 addresses those specific
issues by only exposing two post types for now and having checks for which
meta keys are exposed.
> Generally items with a large surface area ought to be developed in a
feature plugin to allow developers to review and users to test the new
features, they then need a merge proposal. This feature has a very large
surface area and needs to be brought to people's attention in order that
they know to test it.
My plan is to include the post management abilities in Gutenberg too
(https://github.com/WordPress/gutenberg/pull/74234, older PR), so the
abilities could be tested before they land in core (we could also add on
AI experiments). Gutenberg requires the proposal of a core backport at the
same time.
That said, Gutenberg and AI experiments don't get as much attention from
backend/core developers as core itself. For example, the Abilities API was
in a separate repo for some time, but when it was added to core we needed
to make many changes to address feedback that only appeared when the core
patches were ready. I think going in small chunks in a plugin and core at
the same time is the way to go to get earlier feedback. Off-course not
rushing things in a release, eg: post management abilities will not go on
7.0, and even if it was merged and feedback appeared (e.g: before or
during beta) we could revert.
> The "Try # 2" PR moves the following features from developer only
interfaces to user facing interfaces:
> meta queries
> the full tax_query interface
> the full date_query interface
> comments open/closed status
> ping open/closed status
> post parent ID
> regex queries
Regarding ping open/closed status and post parent ID, they are already
exposed on the REST API too. Regarding regex queries, I have been thinking
and I agree they carry significant performance risk and are rarely needed
in the contexts abilities serve. I'll remove those.
Then we have the meta, tax, and date queries. The difference to consider
here is that abilities run in agentic or workflow contexts, not on every
page load. That's a different performance constraint compared to, for
example, the REST API, where an endpoint might be used on the front end on
every page request, or to plugin code which may also make queries on every
page load (which is probably why we have PHPCS warnings on some of these
interfaces).
I agree these queries have some performance considerations, but when we
need them (e.g., retrieve posts with a given meta value, or post published
in a specific day of month), using them is better than the alternative:
retrieving a full collection and then filtering in code or in the agent,
which is even less performant and efficient (and in the agent case may
cost lots of tokens). Providing these types of queries will make a
difference for agents, as they get a good API to find the information they
need with very specific filters, instead of getting large collections.
Although the query may be complex, querying at the database level is more
efficient than at the agent or code layer. In an agentic context, if a
query takes 1 or 2 seconds to execute, it is not a big deal as the agent
itself may take even longer to respond. This allows us to offer different
functionality on abilities because we operate under different constraints.
Would you prefer if we removed meta, date, and tax queries from the
initial get post ability PR, so we make it smaller and then in a follow-up
PR we propose/discuss the querying part specifically?
Thank you again for all the insights and thoughts shared.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/64455#comment:14>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform