WordPress dashboards with DataViews: less interface to reinvent
DataViews, DataForm and the new Design System: how I would build a modern WordPress admin interface, and where the boundaries still matter.
For me, a good admin interface is one I can understand quickly. Find a record, check its details, change something and move on. If I first need to learn the interaction model of an individual plugin, something has already been lost.
That is why I find the current development of WordPress components interesting. Tools associated with the editor are becoming a broader foundation for administrative interfaces. Today, I would take a closer look before building another custom table, filter panel and form layout for a plugin.
Different packages, different responsibilities
@wordpress/components provides familiar React controls. The package is explicitly intended for interfaces beyond the block editor as well. It remains a useful starting point for buttons, notices and other conventional controls. Package documentation
@wordpress/dataviews adds tables, lists and grids through DataViews, plus editing forms through DataForm. Fields describe records; connecting the data remains the application’s responsibility. DataViews handbook
For a project management screen, I would first write down the questions people need to answer. Which projects need attention? Who is responsible? What changed? Only then would I choose columns and actions. A component can display many things. That is no reason to display all of them at once.
What is actually new
WordPress 7.1 introduced foundations for theming admin interfaces. The wp-theme stylesheet supplies semantic design tokens, and a ThemeProvider allows scoped adjustments. This concerns administration, rather than the visitor-facing design of a block theme. Design System dev note
Meanwhile, @wordpress/ui is developing alongside it. The distinction matters: its documentation still identifies the package as experimental. It is distributed through npm, rather than simply appearing as a new window.wp.ui in every WordPress installation. I would avoid a blanket migration of existing components. @wordpress/ui documentation
My choice would be pragmatic: use established components, evaluate new building blocks individually and explicitly define the supported WordPress version. A plugin for one controlled installation has different constraints from an extension expected to work across many older sites.
Begin with one small overview
My first step would be a single working list with a few fields: a title, a status and a modification date. One clear primary action. I would leave out a card view unless imagery or spatial orientation provides a genuine benefit.
Setup deserves attention. For plugins or themes built with @wordpress/scripts, the handbook specifies @wordpress/dataviews/wp. Outside WordPress, use @wordpress/dataviews. Styles matter too: plugin CSS needs a wp-components dependency; standalone applications need the documented Theme, Components and DataViews styles. Handbook setup
I would establish that foundation once, then focus on the actual workflow. More business logic cannot repair a dropdown hidden behind the wrong layer or an interface missing its spacing.
A small configuration excerpt for records with name and status could start here:
Pass these fields to DataViews; data, view state and pagination are deliberately omitted here. The official plugin tutorial provides a fuller foundation.
Connect the view to the data deliberately
The view is state: search, sorting, filters and the current page. For larger datasets, I would translate those choices into bounded server queries instead of loading every record into the browser. Changing filters returns the list to page one. Slow responses must not overwrite newer search results.
Those are decisions for my application architecture. I would also distinguish loading failures, empty search results and a collection that has never contained any records. “No results” is unhelpful when the connection actually failed.
For forms, I want a visible distinction between changed and saved. A successful click does not necessarily mean a successful save. Errors belong beside the relevant field, and the overview should reflect the actual stored state after saving.
Extend an existing screen when it fits
Not every requirement needs another admin page. WordPress 7.1 provides view configuration filters for Pages, Templates, Template Parts and Patterns in the Site Editor. These can configure default views and Quick Edit forms, among other things. This is a specific extension point for those screens, rather than a universal API for every older admin table. Filtering screens dev note
If the task belongs there, I would investigate that route first. A second interface for the same content costs users attention and creates ongoing maintenance work for me.
Components do not replace permissions
Hiding a delete button does not protect a REST endpoint. Custom routes need appropriate permission_callback checks for the action and, where relevant, the individual record. Input must also be validated on the server. WordPress custom endpoint handbook
My conclusion is straightforward: I want to use these building blocks so I have less standard interface code to maintain. The time saved belongs to workflows, understandable states and reliable data. Those are the things that determine whether a dashboard actually works well in everyday use.
Research current as of September 29, 2026. Check package documentation against the supported WordPress version before implementation.