I had a client a few months back with a custom CRM built straight into WordPress. Their team kept complaining about the clunky admin for managing client data: slow, buggy, validation failing on submit. Every field was its own bespoke build, and adding anything new was painful.
It reminded me of the pre-Gutenberg days, when building complex data-entry screens meant wrestling with meta boxes and custom JavaScript. One developer on the team tried to patch it with a pile of jQuery and PHP hooks, dropping in fixes wherever validation broke. It sort of held for a while, but it was duct tape. Every WordPress update was a gamble, and the UI stayed sluggish and inconsistent.
The problem? They were fighting WordPress instead of working with it. Custom data management in Gutenberg used to be a real pain point, but WordPress 6.9 and the ongoing work on the “dataviews space”, specifically the Field API, DataViews, and DataForm, has changed that. These are not minor tweaks. They are foundational changes to how you build dynamic, reliable admin UIs.
Gutenberg DataViews: building better admin UIs
Most of this comes down to the Field API and DataViews. The Field API is where you define how a piece of data behaves: its type, how it is validated, and how it is rendered and edited. WordPress 6.9 grows the field types from 3 to 13, covering things like datetime, integer, email, and url, so basic fields need far less custom code. The Edit property now ships 16 bundled controls, such as checkbox, toggle, and textarea, many with configurable options, so you get consistent UI without building it yourself.
Validation is a good example. You used to roll your own logic, which drifted into inconsistencies. The isValid property has been reworked around a rule-based system: you get built-in required and elements rules, and you can add custom sync or async validation functions. That cuts a lot of error-prone boilerplate. Here is how you would define a required text field with a custom validation rule:
<?php
add_action( 'bbioon_register_custom_fields', 'bbioon_setup_my_fields' );
function bbioon_setup_my_fields() {
bbioon_register_field_type( 'my_custom_text', array(
'label' => esc_html__( 'My Custom Text', 'bbioontheme' ),
'type' => 'text',
'edit' => 'text',
'isValid' => array(
'required' => true,
'custom' => new JS_Callback( 'function( item, field ) {
if ( item[ field.id ].length < 5 ) {
return \'Must be at least 5 characters.\';
}
return null;
}' ),
),
) );
}
?>On top of that, setValue now sits alongside getValue, which makes nested and derived data much easier to work with. You can use dot notation in your field.id (for example user.profile.name) and the API does the parsing and updating for you. You can also define custom setValue logic to update several dependent fields at once, like recalculating a total from price and quantity the moment a related field changes.
DataViews then takes those fields and turns them into tables, grids, and lists. WordPress 6.9 adds groupByField for grouping data, locked filters that users cannot remove, and infinite scroll through paginationInfo. For a heavily customized UI, you can tap into DataViews’ own state management and data handling while using its subcomponents as children. And if you are building a content picker for posts or media, the new DataViewsPicker component is built for exactly that, handling selection and action buttons for you. The official dev notes on the WordPress Core blog go deeper, and this post leans on them for the practical developer angle.
Why this matters for your WordPress projects
The old way of building custom admin UIs was a hack-fest, and most of us have shipped something that works but is miserable to maintain or scale. The 6.9 updates around Gutenberg DataViews are really about developer experience and long-term stability. You get a standard, dependable way to handle complex data and interfaces inside the block editor, which means less time debugging one-off solutions and admin areas that behave the way clients expect.
If you are still rolling your own data management with old-school meta boxes or overgrown custom fields, it is time to stop. These APIs handle the basic form fields and the complex data tables with filtering and pagination alike, and they hold up across core updates instead of breaking on them. The payoff is scalable, maintainable applications, not just an admin that looks tidy.
This stuff gets complicated fast. If you are tired of debugging someone else’s mess and just want your site to work, drop my team a line. We have probably seen it before.
