A client came to me last month with a project that was a nightmare. They had a huge custom inventory system, about 60,000 SKUs sitting in custom database tables, and their admin dashboard was basically unusable. The previous developer had built a custom React application inside the WordPress admin to manage all of it. It looked fine, but it was a silo, and every time a WordPress core update rolled out the whole thing broke.
My first instinct was to scrap it and build a standalone headless app. That looked like the only way to get the performance they needed without fighting the CMS, but it’s a maintenance burden most small teams can’t carry. They wanted to stay in the WordPress environment they already knew. So I went through the developer notes for WordPress 6.9 instead, and that changed the plan: the release moves a lot of the data handling and AI integration into core.
Building custom dashboards with DataViews
The heavy lifter in this release is the expansion of DataViews and DataForm. If you’ve ever built a custom table in the WordPress admin, you know how much work filtering and pagination take before the thing stops feeling like it was built in 2005. WordPress 6.9 brings infinite scroll and locked filters into the framework itself. I used that to replace the client’s broken React dashboard, so instead of hundreds of lines of custom state management I’m leaning on core components that inherit the native UI.
The new Fields API is the other half of it. We went from three field types to thirteen. Dates, emails and passwords are all there now, with rule-based validation. I first saw this written up in the developer breakdown from WordPress.com, and it does save hours of boilerplate.
Standardizing AI with the Abilities API
Everyone is shoving AI into WordPress right now, and most of it is a glorified chat box. The Abilities API in 6.9 makes your site “intelligible” to AI agents through the Model Context Protocol (MCP). Instead of only generating text, an agent can see that your plugin has the “ability” to generate a sales report or audit a specific post’s SEO. Here is how you might register a custom ability for an inventory audit tool:
function bbioon_register_inventory_audit_ability() {
if ( ! function_exists( 'register_block_ability' ) ) {
return;
}
register_block_ability( 'bbioon/inventory-manager', array(
'name' => 'audit_stock_levels',
'description' => __( 'Audits stock levels for specific categories.', 'bbioon' ),
'parameters' => array(
'category' => array(
'type' => 'string',
'required' => true,
),
),
) );
}
add_action( 'init', 'bbioon_register_inventory_audit_ability' );Defining these capabilities is what keeps the work useful later. The plugin stops being one more feature and becomes something an AI assistant can call directly. That’s the part of agentic commerce that actually concerns developers.
Block Bindings and the new data source UI
We finally have a simplified UI for switching data sources in the editor. I used to write a custom block just to display a dynamic caption from a meta field. With the updated Block Bindings API you register your own binding sources and the user picks one from a dropdown in the sidebar. Less code, and it survives the user changing the layout.
Why I stopped fighting the core
The lesson from this rebuild: stop fighting the core. For years we built custom workarounds because the WordPress admin was too rigid, and 6.9 closes much of that gap. The Interactivity API gets faster client-side navigation, theme.json finally supports form element styling, and the admin becomes a sane place to put a complex application again.
This stuff gets complicated fast. If you’re tired of debugging someone else’s mess and you just want your site to work with the new standards, drop my team a line. We’ve probably seen it before.
Are you moving your custom admin tables over to DataViews, or sticking with your own React builds for now? I’m curious which way people are leaning.
