# WordPress DataViews for WooCommerce admin lists in 2026

Build merchant-facing product tables with DataViews, DataForm, and REST. Fields, filters, and wp-components styling that match core admin.

- Date: 2026-10-26
- Category: WordPress

## Table of contents

- Why WordPress DataViews matter for WooCommerce admin
- How WordPress DataViews works in a WooCommerce plugin
- Production checklist for WordPress DataViews on store admin
- What breaks when WordPress DataViews meets live catalogues
- How to measure WordPress DataViews admin quality
- Related work on this site
- FAQ
  - When should I choose WordPress DataViews instead of WP_List_Table?
  - Do WordPress DataViews require the block editor on the storefront?
  - Can WordPress DataViews edit WooCommerce products directly?
  - How do WordPress DataViews interact with the Abilities API?

WordPress DataViews is the React toolkit I use in 2026 when a WooCommerce merchant needs a custom admin screen that still feels like core WordPress, not a bolted-on spreadsheet. I am Alan Vo, a Gold Coast web developer with 18 years on business sites and catalogues. Core admin and WooCommerce both lean on the same `@wordpress/dataviews` package for tables, filters, grid layouts, and bulk actions. If you ship a plugin that manages SKUs, bundles, or channel-specific price rows, rebuilding that UI from scratch is wasted effort and it will look wrong within a year.

This note is for developers who already maintain a WordPress store and want a production-grade list screen without forking WooCommerce list tables. It assumes you are comfortable with the block editor script stack (`@wordpress/scripts`, `wp_enqueue_script`, REST nonces). It pairs with the [Abilities API for catalogues](https://alanvo.com/blog/wordpress-abilities-api/) when you expose the same data to automation, and with [block bindings on product pages](https://alanvo.com/blog/wordpress-block-bindings-api/) on the storefront side where the admin data eventually surfaces.

## Why WordPress DataViews matter for WooCommerce admin

WordPress DataViews matter for WooCommerce admin because list screens are where catalogue work actually happens. Merchants filter by stock status, sort by margin, bulk-edit categories, and export subsets for a marketplace feed. WooCommerce’s own React admin surfaces already import DataViews styles and patterns. When you add a custom “channel pricing” or “damaged stock” screen, matching that behaviour means using the same field definitions, filter chips, and table layouts core documents in the [@wordpress/dataviews reference](https://developer.wordpress.org/block-editor/reference-guides/packages/packages-dataviews/).

Before DataViews landed in the Gutenberg package ecosystem, every agency plugin invented its own table: jQuery DataTables, hand-rolled `<table>` markup, or a React grid with mismatched focus rings and no keyboard story. That drift shows up in accessibility audits and in training time for store staff. DataViews gives you `DataViews` for the main list, `DataViewsPicker` when the task is “pick three products”, and `DataForm` when a row opens an edit panel. WordPress 6.9 expanded filters, validation, and infinite scroll; the [6.9 DataViews dev note](https://make.wordpress.org/core/2025/11/11/dataviews-dataform-et-al-in-wordpress-6-9/) is the changelog I read before upgrading a client plugin.

The payoff is not only visual consistency. Fields declare types (`text`, `integer`, `datetime`, `media`, and more in 6.9), so search and filter operators stay aligned with the data. Actions attach to rows or bulk selections with eligibility callbacks, which is how you hide “Push to ERP” when a SKU lacks a mapping. For multi-user stores, that declarative model beats scattering `current_user_can()` checks across template strings.

![WordPress DataViews in the block editor on a laptop](../../images/blog/wordpress-dataviews-woocommerce-admin-1.jpg)

## How WordPress DataViews works in a WooCommerce plugin

WordPress DataViews works in a WooCommerce plugin as a controlled React tree fed by REST (or a localized initial payload) and driven by a `view` state object you own. The component does not fetch WooCommerce products by itself. You query `/wp-json/wc/v3/products` or a custom namespace, map records into plain objects with stable `id` keys, pass `fields` and `actions`, and update `view` when `onChangeView` fires.

Inside WordPress, enqueue scripts built with `@wordpress/scripts` and import from `@wordpress/dataviews/wp` rather than the standalone package entry. The official docs call that out so WordPress supplies shared `@wordpress/components` and does not bundle duplicate React. Your admin page callback prints a mount node; your script calls `createRoot` and renders `<DataViews />`.

A minimal field set for catalogue rows might look like this:

```jsx
const fields = [
	{
		id: 'name',
		label: 'Product',
		enableGlobalSearch: true,
		render: ( { item } ) => (
			<a href={ item.editLink }>{ item.name }</a>
		),
	},
	{
		id: 'sku',
		type: 'text',
		label: 'SKU',
		filterBy: { operators: [ 'contains', 'startsWith' ] },
	},
	{
		id: 'stock_status',
		type: 'text',
		label: 'Stock',
		elements: [
			{ value: 'instock', label: 'In stock' },
			{ value: 'outofstock', label: 'Out of stock' },
		],
	},
];
```

The `view` object carries layout (`table`, `grid`, or `list`), sort column, sort direction, page number, perPage, and active filters. When the merchant changes any of those, `onChangeView` runs. That is your signal to refetch or to slice client-side data. For stores with tens of thousands of SKUs, server-side pagination is mandatory. Pass `paginationInfo` with `totalItems` and `totalPages` so the footer matches WooCommerce’s own product list behaviour.

Styles depend on `wp-components`. Register your plugin stylesheet with `wp-components` as a dependency, as described in the DataViews setup section. Missing that dependency is the most common reason a custom screen looks unstyled while WooCommerce settings look fine. RTL sites need the `-rtl` stylesheets from the same packages if you ever load DataViews outside admin’s bundled assets.

WordPress 7.0 keeps investing in DataViews and DataForms in the modernized dashboard, per the [WordPress 7.0 Field Guide](https://make.wordpress.org/core/2026/05/14/wordpress-7-0-field-guide/). Planning a plugin today means pinning `@wordpress/dataviews` to the same major line your client’s core version ships, not the latest npm tag on a laptop.

## Production checklist for WordPress DataViews on store admin

A WordPress DataViews admin screen is ready for merchants when data, permissions, and performance match what WooCommerce core already teaches them to expect.

![Developer desk with two monitors during WordPress DataViews work](../../images/blog/wordpress-dataviews-woocommerce-admin-2.jpg)

1. Register a top-level or WooCommerce submenu page with `manage_woocommerce` or a tighter custom capability. Do not hang sensitive pricing tools on `edit_posts`.
2. Enqueue the script only on that screen hook (`load-{page}`) so DataViews CSS never hits the storefront.
3. Localize `wpApiSettings` or use `@wordpress/api-fetch` with the REST nonce middleware so `/wp-json/` calls authenticate. Follow [REST API authentication](https://developer.wordpress.org/rest-api/using-the-rest-api/authentication/) for application passwords on staging bots, not in the browser bundle.
4. Map WooCommerce product IDs to DataViews `id`. If you merge variations as rows, use a composite key and implement `getItemId` so selection state survives sorts.
5. Define `fields` with explicit `type` values so 6.9 filter operators stay valid. Use `readOnly` on calculated columns like margin percent.
6. Wire `actions` for row edit (deep link to native product editor), bulk CSV export, and any ERP push. Use `isEligible` so out-of-stock rules do not appear on digital SKUs.
7. Implement server-side search for catalogs above a few hundred rows. Debounce `onChangeView` and cancel in-flight fetches when filters change quickly.
8. Add empty states via the `empty` view prop when a filter returns zero rows, with copy that tells staff how to reset filters.
9. Test with Shop Manager and Customer roles to confirm actions hide correctly. Test keyboard navigation through filters and the primary action button.
10. Run the screen on staging with HPOS enabled if the store uses custom order tables, so your REST queries still match production meta keys.

When the same dataset powers an internal tool and a future AI workflow, register read-only abilities separately rather than giving an agent write access to the DataViews action callbacks.

## What breaks when WordPress DataViews meets live catalogues

WordPress DataViews breaks in production when developers treat it like a static table component instead of a view state machine tied to WooCommerce data quirks.

Duplicate React versions are the first failure mode. Loading DataViews from a CDN bundle alongside `wp-element` causes blank screens or hook errors. Always build with `@wordpress/scripts` defaults and mark React as external through the WordPress enqueue path.

Client-side-only filtering collapses on large catalogues. Loading five thousand products into `data` on first paint will timeout PHP localization and freeze the browser. Symptoms look like “admin is slow” but the culprit is architecture, not DataViews itself.

Variation products expose messy rows if you flatten incorrectly. A parent SKU and its variations may share titles; without a `render` column that shows attributes, merchants pick the wrong row for bulk edits. Align row identity with how [Their Nibs](https://alanvo.com/work/their-nibs/) style catalogue teams think about sellable units, not only post IDs.

![Website wireframes on paper next to a keyboard](../../images/blog/wordpress-dataviews-woocommerce-admin-3.jpg)

Filter operators that do not match field types silently drop constraints in 6.9. If you declare an integer field but pass formatted price strings from WooCommerce, range filters misbehave. Normalize numbers before they enter `data`.

Bulk actions that call slow ERP endpoints without feedback leave users clicking twice. Use action `callback` promises and disable the modal primary button while the request runs. Log failures with SKU in the message.

Missing `wp-components` dependency strips layout on mobile, which is where some store owners check stock. Verify narrow viewports, not only a wide monitor.

Prerender and speculative loading do not apply inside wp-admin, but admin scripts that leak to the front end will. Guard enqueue callbacks with the screen ID check every time.

## How to measure WordPress DataViews admin quality

WordPress DataViews admin quality shows up in task time, error rate, and support tickets, not in Lighthouse scores.

Track how long a benchmark user takes to find ten SKUs by partial SKU, change stock status via bulk action, and confirm in the native product editor. Compare against the old custom table on staging if you are replacing one.

Count failed REST requests from the screen in server logs (`/wp-json/` 4xx and 5xx tagged by your plugin namespace). Spikes after deploy usually mean nonce or capability regression.

Watch MySQL slow query log when filters change. If product meta joins appear, move filtering into a dedicated REST endpoint with prepared queries instead of loading fat objects.

Ask support whether merchants confuse your screen with WooCommerce’s product list. Confusion means field labels or actions diverged from core patterns; align copy and iconography.

After major WordPress upgrades, smoke-test filter chips, infinite scroll if enabled, and DataForm validation messages. The 6.9 note documents async `isValid` rules; broken validation blocks saves with little visible error if you skip testing.

## Related work on this site

On [Skanvi](https://alanvo.com/work/skanvi/) and other WooCommerce builds I maintain, internal catalogue tools sit next to the same REST and caching patterns as the public shop. Admin list performance ties directly to [hosting, cache, and CDN choices for WordPress stores](https://alanvo.com/blog/hosting-cache-cdn-wordpress/) because a heavy meta query on every filter change will hurt even if the UI component is perfect. When checkout and catalogues share staff attention, keeping admin familiar reduces mistakes that show up as oversells or wrong channel prices.

![Content editor reviewing a page on a tablet](../../images/blog/wordpress-dataviews-woocommerce-admin-4.jpg)

## FAQ

### When should I choose WordPress DataViews instead of WP_List_Table?

Choose WordPress DataViews when the screen needs modern filters, layouts, and bulk actions that match WooCommerce and core admin in 2026. WP_List_Table still works for simple read-only logs, but new merchant-facing tools should use DataViews so you inherit accessibility and filter UX core maintains.

### Do WordPress DataViews require the block editor on the storefront?

WordPress DataViews require React admin scripts, not the storefront block editor. You enqueue them on an admin menu page only. The storefront can remain classic PHP templates or block themes without loading `@wordpress/dataviews` for shoppers.

### Can WordPress DataViews edit WooCommerce products directly?

WordPress DataViews can trigger edits through actions and DataForm, but WooCommerce product writes should go through WooCommerce REST API or guarded PHP callbacks, not ad hoc AJAX. Use row actions to deep-link into the native product editor for complex fields, and reserve inline DataForm fields for the small subset merchants change daily.

### How do WordPress DataViews interact with the Abilities API?

WordPress DataViews handle human UI; the Abilities API exposes the same operations to agents and automation with explicit permissions. Keep write paths in one PHP service both the DataViews action callback and an ability handler call, so you do not duplicate business rules in JavaScript alone.


![Laptop and coffee while shipping WordPress DataViews](../../images/blog/wordpress-dataviews-woocommerce-admin-5.jpg)


HTML version: https://alanvo.com/blog/wordpress-dataviews-woocommerce-admin/