WordPress 6.9 and the ongoing Site Editor push aren’t just for theme developers. The entire admin interface is currently undergoing a massive structural shift. If you’ve been building settings pages the “old way”—with endless stacks of PanelBody and PanelRow components—you’ve likely realized it’s a maintenance nightmare. Every time you want to add a field, you’re diving back into a sea of imperative JSX.
Consequently, Core has introduced a more declarative approach. In this guide, I’ll show you how to use the DataForm component to build modern DataForm plugin settings pages. This is the same tech driving the new Site Editor experience, and honestly, once you switch to a configuration-driven UI, you won’t want to go back to manually wrapping TextareaControl tags ever again.
Why DataForm is the Future of Admin UI
The core problem with traditional WordPress React development is how much “boilerplate” we write just to render a simple form. You have to import every single control, manage their state individually, and handle the layout manually. It’s brittle. If you’re curious about the broader implications of these updates, check out my take on why WordPress 6.9 is a major win for developers.
Specifically, the DataForm component allows you to define your fields as a JSON-like configuration object. The component then handles the rendering, mapping the correct UI controls based on the data type. Furthermore, it supports sophisticated layout types like cards and panels right out of the box.
Step 1: Installing Dependencies
First, you need the @wordpress/dataviews package. If you’re already using wp-scripts, this is a straightforward addition to your project. Run the following in your plugin directory:
npm install @wordpress/dataviews --saveWhen importing the component, there is a technical “gotcha.” You must import from @wordpress/dataviews/wp to ensure dependencies are resolved correctly within the WordPress environment, as noted in the official package documentation.
import { DataForm } from '@wordpress/dataviews/wp';Step 2: Defining Your Fields Configuration
Instead of rendering components, you define a fields array. Each object represents a setting. For DataForm plugin settings pages, you define the id, label, and type. If you want a specific UI component like a toggle or a textarea, you specify the Edit property.
const fields = [
{
id: 'message',
label: __( 'Announcement Message', 'my-plugin' ),
type: 'text',
Edit: 'textarea',
},
{
id: 'display',
label: __( 'Display Bar', 'my-plugin' ),
type: 'boolean',
Edit: 'toggle',
},
{
id: 'size',
label: __( 'Font Size', 'my-plugin' ),
type: 'text',
Edit: 'toggleGroup',
elements: [
{ value: 'small', label: __( 'Small', 'my-plugin' ) },
{ value: 'medium', label: __( 'Medium', 'my-plugin' ) },
{ value: 'large', label: __( 'Large', 'my-plugin' ) },
],
},
];Step 3: Layout and Grouping
One of the best features of DataForm is how easily it handles grouping. You can wrap fields into sections and choose between regular, panel, card, or row layouts. Specifically, the card layout is excellent for mimicking the modern Gutenberg sidebar look.
const form = {
fields: [
{
id: 'general-settings',
label: __( 'General', 'my-plugin' ),
children: [ 'message', 'display' ],
layout: { type: 'card', withHeader: false },
},
{
id: 'appearance-settings',
label: __( 'Appearance', 'my-plugin' ),
children: [ 'size' ],
layout: { type: 'card', isOpened: false },
},
],
};Step 4: Connecting to State
In the past, we’d have three different useState hooks for three different settings. With DataForm, we store everything in a single object. This matches the way WordPress stores settings in the REST API (if you’re using the object type for your setting registration).
const SettingsPage = () => {
const { settings, setSettings, saveSettings } = bbioon_useSettings();
return (
<DataForm
data={ settings }
fields={ fields }
form={ form }
onChange={ ( edits ) =>
setSettings( ( current ) => ( {
...current,
...edits,
} ) )
}
/>
);
};The onChange callback only receives the “edits” (the changed fields). Therefore, we use the spread operator to merge the updates with our current state. This prevents us from accidentally wiping out other settings during an update.
The Takeaway
Refactoring your UI to use DataForm plugin settings pages isn’t just about looking “modern.” It’s about building a maintainable architecture that aligns with where WordPress Core is headed. You stop fighting with CSS and start focusing on the data logic of your plugin.
Look, if this DataForm stuff is eating up your dev hours, let me handle it. I’ve been wrestling with WordPress since the 4.x days.
If you need deeper documentation on validation or asynchronous elements, I highly recommend exploring the WordPress 6.9 DataViews announcement. Now go ship something clean.
