Most WordPress projects do not start with automation. They start with a site that needs to work. Then plugins get added, some custom code sneaks in, and over time the system grows. Only later does automation become a topic, usually when someone wants to reuse logic, connect systems, or avoid doing the same thing manually over and over again.
By then, many setups already expose more than they really should. Not because anyone messed up, but because WordPress never gave us a clean way to describe what a system is actually meant to do and what should stay internal.
For years, this was handled through experience. If you worked on WordPress projects long enough, you had a sense for which parts were safe to touch, which endpoints existed mostly for convenience, and which actions should never be triggered automatically. That kind of knowledge worked fine as long as the same people stayed around.
It becomes fragile once systems start interacting with systems.
How automation usually ended up
being built before WordPress 6.9
Before WordPress 6.9, automation was mostly done in a pragmatic way. You exposed some functionality, wrapped it in a REST endpoint, added permission checks that felt reasonable at the time, and trusted that whoever used it would understand the context.
register_rest_route( 'example/v1', '/update-excerpt', [
'methods' => 'POST',
'callback' => function ( $request ) {
return wp_update_post( [
'ID' => $request['post_id'],
'post_excerpt' => $request['excerpt'],
] );
},
] );
Most WordPress projects end up with code like this at some point. It usually works fine and often stays in production longer than anyone expected.
The issue is not the code itself. The issue is that the boundaries of what should happen are never part of the system. They live in assumptions, documentation, or shared understanding between people.
As long as nothing changes, that is rarely a problem. Once functionality gets reused, extended, or automated further, those invisible boundaries start to matter.
The problem was never automation itself
Automation did not suddenly introduce new risks. It simply made existing ones visible. WordPress has always had a huge amount of functionality spread across core, plugins, and themes, but no standard way to say which actions are intentionally exposed and which ones are just implementation details.
Humans can work with that kind of ambiguity. Systems cannot. If something is reachable, it will eventually be used, sometimes in ways nobody originally planned.
The Abilities API gives WordPress a way to be explicit about intent.
What the Abilities API changes in a very practical sense
Instead of exposing functionality and hoping it is used carefully, you define what the system offers. One specific action. Clear input. Clear output. One place where permissions are checked. Everything else simply stays internal.
This does not suddenly make WordPress more powerful. It makes behavior easier to understand.
The same use case, but without relying on assumptions
If the same excerpt update is implemented using the Abilities API, the difference is not technical complexity. It is clarity about what is allowed to happen.
wp_register_ability(
'content/update-excerpt',
[
'execute_callback' => function ( $input ) {
return wp_update_post( [
'ID' => $input['post_id'],
'post_excerpt' => $input['excerpt'],
], true );
},
'permission_callback' => function () {
return current_user_can( 'edit_posts' );
},
]
);
In this setup, there is no general access to WordPress. There is exactly one action that the system explicitly supports. Everything else is simply not part of the surface and does not need to be protected after the fact.
That difference becomes important once automation is no longer a side experiment, but part of how a project actually runs.
A practical example from real projects
A client site uses a small custom function to generate excerpts when posts are imported from a feed. Later, that same logic is exposed through a REST endpoint so the importer can trigger it on demand.
Months later, the endpoint gets reused in a batch process during a migration. Hundreds of already published posts end up with new excerpts on the live site. Nothing is technically broken. The endpoint did exactly what it was allowed to do.
With the Abilities API, this logic would be exposed as one explicit action for that exact purpose. The migration process would never have access to anything else.
What this changes once projects grow
Once actions are defined this way, automation becomes easier to reason about. The system itself communicates what is possible, instead of relying on conventions that only long-time contributors understand.
In practice, this usually means fewer edge cases, less defensive code, and fewer situations where someone has to trace back why something was triggered in the first place.
It also makes projects easier to maintain over time, especially when teams change or code is reused in contexts that were never originally planned.
Conclusion
The Abilities API does not introduce a new way to automate WordPress. It introduces a clearer way to describe what a WordPress system is actually meant to do.
Once intent is part of the system instead of living in people’s heads, automation stops feeling fragile and starts feeling predictable.
That is the real shift 🙂
