I had a client last year running a big editorial site, over fifty authors and a dozen editors. Their feedback loop was a mess. Editors left comments in Google Docs, authors replied in Slack, and the developers sat in the middle trying to work out which version of the copy was final. It was the sort of mess that makes rewriting the whole CMS start to sound reasonable. The recent WordPress 6.9 update finally handles that particular headache in core.
Notes is the standout in 6.9 for anyone running high-volume content: block-level commenting inside the editor. You no longer dig through an email thread to find out why an image was swapped, because the comment sits on the canvas next to the block. It is about time. The official release post at https://wordpress.org/news/2025/12/gene/ has the high-level overview.
What the Abilities API is actually for
The Abilities API is the part that matters most for us. When I first read the requirements for a recent AI-automation project, my plan was to sprinkle current_user_can() checks everywhere. Wrong instinct. Permissions for AI agents and automated workflows are a different problem: you need a machine-readable registry of what the site can do, not just what a user is allowed to click.
WordPress 6.9 standardizes how those actions get registered and validated. Instead of a spiderweb of custom capability checks, there is one system that PHP, REST and AI agents all read from. Registering a custom ability looks like this, with prefixing so it stays out of anyone else’s namespace:
/**
* Registering a custom ability for a specialized commerce action.
* Standardizing this ensures AI agents can interact with the site safely.
*/
function bbioon_register_custom_site_abilities() {
if ( ! function_exists( 'register_block_ability' ) ) {
return;
}
register_block_ability( 'bbioon/process-custom-refund', array(
'description' => __( 'Allows the agent to process specific order refunds.', 'bbioon-textdomain' ),
'permission' => 'manage_woocommerce',
'executable' => true,
) );
}
add_action( 'init', 'bbioon_register_custom_site_abilities' );
Moving capability checks onto this API is not only about closing a permission hole. The hours you put into the refactor now come back, dozens of them, on the day six months from now when a client asks you to “plug in an AI assistant.”
Performance and the rendering path
Classic themes got some attention too. 6.9 loads block styles on demand for classic setups, which helps LCP (Largest Contentful Paint). If you have been fighting a bloated CSS file on a legacy project, that alone justifies the upgrade. Block theme styles are minified and the inline style limit goes up, so less of it blocks the rendering path. Clients never see this work, but they see it in the conversion numbers.
This gets complicated fast. If you are tired of debugging someone else’s mess and want your site running against the current standards, drop my team a line. We have probably seen it before.
What to do about 6.9
WordPress 6.9 “Gene” is more than a handful of UI tweaks. Notes changes how editorial teams work, and the Abilities API changes how automation gets permission to act. If you have not tested your custom plugins against either API yet, that is the next job on the list. The native tools exist now, so the duct-taped permission logic can go.
Are you refactoring your permission logic onto the Abilities API, or staying with capability checks for now?
