WooCommerce is using DataViews, DataForms, and Fields to build more declarative administration interfaces. The direction is useful for extensions, but the APIs are still maturing and WooCommerce is not requiring an immediate rewrite of every classic screen.
Use this for WooCommerce extension teams deciding whether to migrate product, order, analytics, settings, or custom entity screens to DataViews.
Quick answer
Score one bounded screen against field coverage, bulk actions, filters, permissions, extensibility, accessibility, performance, testability, and rollback. Start with an opt-in internal or beta screen when the required APIs are stable enough. Keep the classic implementation available until users can complete the same critical jobs and saved data remains compatible.
Test scenarios to run
Run the same controlled fixture across these branches. Write down the expected result before testing so a surprising response is easy to identify.
| Scenario | Fixture | Expected result |
|---|
| Read-heavy list | Custom entity list with filters, sorting, and row actions | Pilot when fields and actions map without private internals |
| Complex editor | Conditional fields, validation, media, and custom save lifecycle | Wait or pilot only when parity and rollback are explicit |
| Bulk workflow | Select thousands of records and run an asynchronous action | Progress, permissions, errors, and recovery remain visible |
| Extension surface | Third parties add fields or actions | Public extension points replace DOM injection before migration |
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Inventory operator jobs | Inventory each screen's entities, fields, filters, search, sorting, bulk actions, permissions, notices, and extension points. | Every must-have job maps to a supported API and tested interaction. |
| Map public APIs | Map required behavior to DataViews, DataForms, Fields, and existing WooCommerce or WordPress PHP APIs. | Saved data remains compatible between classic and DataViews screens. |
| Choose a bounded pilot | Mark missing or changing APIs and assign an owner rather than filling gaps with brittle DOM selectors. | Keyboard, responsive, error, permission, and large-dataset fixtures pass. |
| Prove parity and rollback | Build a small opt-in pilot with the same saved data and a clear route back to the classic screen. | The pilot has an opt-in audience, owner, telemetry, and rollback route. |
What to check first
- Inventory each screen's entities, fields, filters, search, sorting, bulk actions, permissions, notices, and extension points.
- Map required behavior to DataViews, DataForms, Fields, and existing WooCommerce or WordPress PHP APIs.
- Mark missing or changing APIs and assign an owner rather than filling gaps with brittle DOM selectors.
- Build a small opt-in pilot with the same saved data and a clear route back to the classic screen.
- Test keyboard use, responsive layout, large datasets, localization, permissions, error recovery, and extension coexistence.
Field notes
- Separate must-have operator jobs from cosmetic parity.
- Record the public package and API versions used by the pilot.
- Test with realistic row counts and slow or failed server responses.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
migration_score:
screen: vendor-rules
required_fields: 14
public_api_coverage: 12
bulk_actions: yes
extension_points: needs_review
keyboard_fixture: pass
large_dataset: pending
rollout: internal_opt_in
Why this usually happens
- Declarative configuration can reduce duplicated table and form plumbing while changing familiar extension boundaries.
- A visually complete screen can still lack permissions, error recovery, bulk semantics, or third-party hooks.
- Private package APIs and DOM structure can move while the public integration surface matures.
Decision rule
Keep the classic screen when a critical job depends on a private API, third-party extensions lose a supported hook, large datasets fail the threshold, permissions differ, or users cannot return safely after opting in.
Production verification checklist
- Every must-have job maps to a supported API and tested interaction.
- Saved data remains compatible between classic and DataViews screens.
- Keyboard, responsive, error, permission, and large-dataset fixtures pass.
- The pilot has an opt-in audience, owner, telemetry, and rollback route.
Safe fix order
Use a sequence that makes each result easy to prove. Stop when new evidence changes the scope or owner of the problem.
- Inventory operator jobs
- Map public APIs
- Choose a bounded pilot
- Prove parity and rollback
- Expand only with evidence
Mistakes to avoid
- Do not rewrite every screen because the component library is available.
- Do not depend on private package internals without a replacement plan.
- Do not call visual parity feature parity.
- Do not remove the classic route before real operators complete the pilot.
Questions teams ask during testing
Is WooCommerce forcing extensions to rewrite now?
The August 5 developer article describes an opt-in path and says there is no forced rewrite.
Where should a team start?
Choose a bounded read-heavy screen with clear fields, actions, and rollback.
Can PHP extensions still participate?
WooCommerce describes a path for PHP-based extension while the newer interface APIs continue to mature.
What to tell the client or owner
Provide the screen, operator jobs, entities, fields, filters, actions, permissions, public APIs, missing hooks, data volume, fixture results, opt-in group, and rollback route.
When HandL WP should help
HandL WP can inventory extension screens, score API readiness, build an opt-in pilot, test parity and accessibility, and plan a staged DataViews migration without interrupting operators.
If this is active on a production site, plan a WooCommerce admin migration.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references