Create ablities for CRUD operations that work with all post types

[gziolo]

• Part of WordPress Core Abilities ai#40

What

Define and register Abilities for the basic CRUD operations (Create / Read / Update / Delete) that apply uniformly to all post types (built-in and custom). These abilities will allow tools, plugins, and UIs to check whether a given user/action is allowed to perform those operations on any post type in a consistent way.

Why

In the discussion that happened in WordPress/ai#40, it was explored whether REST API endpoints themselves should be represented as abilities. The main thread was that many of the current checks in WordPress—like creating, reading, updating, or deleting posts—map naturally to abilities, and it would be useful to make those explicit. Several people pointed out that this should apply consistently across all post types, so that developers and clients can rely on a predictable set of CRUD abilities instead of piecemeal capabilities.

A recurring theme was the tension between having generic CRUD abilities (create post, update post, etc.) and the need for post-type-specific granularity (e.g. create book vs create page). The consensus leaned toward defining a base schema that can be parameterized or specialized per post type. This would keep things consistent while still allowing detailed permission checks.

There was also discussion about how these abilities should align with existing WordPress permissions. Any new system must respect the current permission callbacks that REST endpoints already use. The abilities API should not bypass or weaken security. Instead, it should expose a clearer, more discoverable layer for clients and tooling.

How

There is also an interesting aspect of these CRUD abilities, as it would be worth considering having different implementations on the server and the client. On the server, it's quite a straightforward choice as it's possible to use the most fundamental functions like get_post(), get_posts(), wp_update_post(), or wp_delete_post(). On the client, things get more interesting. While it would be possible to hit the server, and execute these abilities in the same way, in certain scenarios it might be problematic. A prime example is the editor, where the user expects to have optimistic updates connected to the save workflow, including undo/redo, etc. In that case, it would be better to override the execute_callback on the client using @wordpress/core-data and the entities system. In effect, these abilities would be capable of using an alternative implementation that uses calls like wp.data.select( 'core' ).getEntityRecords( 'postType', 'page' ); or wp.data.dispatch( 'core' ).editEntityRecord( 'postType', 'page', pageId, { title: 'updated title' } );.