If a WordPress DataViews table becomes empty after selecting numeric IDs, check the installed filtering implementation and the types on both sides of the comparison. The isAny and isNone operators need numeric-field support, and a number such as 12 does not equal the string "12" in an array membership comparison.
This guide is for an extension or custom admin screen using DataViews. It is not evidence that orders or posts were deleted. First compare the underlying response with the filtered display.
Identify where filtering happens
Find out whether the extension calls filterSortAndPaginate on a local dataset or translates the view into a server request. A client-side operator fix does not automatically repair a custom REST query translator.
Record the package or plugin version that actually provides the table. Updating WordPress may not change a separately bundled DataViews package. Conversely, replacing a bundle manually can create dependency conflicts without fixing the integration.
The numeric-filter implementation change adds support for number values to isAny and isNone. Its patch uses array inclusion rather than coercing numeric strings. It does not establish new scalar isAll semantics.
Use a small, explicit dataset
Before testing a full customer list, make a synthetic fixture with predictable IDs:
| Record |
Numeric author value |
| alpha |
0 |
| beta |
12 |
| gamma |
27 |
| delta |
12 |
For a selection of numeric [0,12], isAny should return alpha, beta and delta. isNone should return gamma. Compare record IDs, not only the count, because two different wrong results can have the same length.
Those are expected results for the fixture, not measurements from a customer site. Run the fixture against the actual version your extension ships.
Then deliberately change the filter selection to string values ["0","12"]. If the field remains numeric, do not expect strict membership to match those strings. Fix the data contract at the boundary instead of hiding the discrepancy in a label renderer.
Number: 0 and 12 remain numbers. Membership: Compare returned record IDs. Pagination: Return to a valid page. Null: Define a separate empty case. Proposed verification, not a customer test result.
Check types without losing zero
Inspect the raw response, the field definition, the elements list used by the picker and the view's saved filter value. A label can show "12" while the underlying value has a different type.
Do not use a truthiness check to decide whether an ID exists: zero is a valid numeric fixture value. Likewise, blindly passing every input through Number can turn an empty string into zero. Define how empty, null, missing and invalid inputs should behave before conversion.
Keep null in a separate test case. The numeric support change does not make null a number. Decide how your application represents "unassigned" and whether it needs its own explicit filter option.
Rule out pagination and request translation
Clear the filter and return to page one. If the records reappear, test whether the integration resets or clamps pagination when its filtered result shrinks. A view left on a later page can look empty even with matching data.
For server-backed screens, compare the selected operator with the request sent to the API. Confirm that the response count and returned IDs match the intended inclusion or exclusion rule. Do not change database records to compensate for a display filter.
For local filtering, inspect the exact data passed into the filtering function. A correctly typed API response can be converted to strings later by a storage adapter, form control or URL-state parser.
Make the correction at one boundary
Choose a canonical type for the field, picker element values and saved filter representation. Add explicit validation when deserializing URL or persisted state. Test older saved views so an update does not leave users with permanently empty screens.
The broader WooCommerce DataViews migration checklist covers extension readiness. Use this guide only for the narrower numeric-filter failure. HandL WP can investigate an admin-table regression when the business workflow is blocked.
Evidence that the repair holds
Save the filter, reload, switch inclusion to exclusion and repeat with zero, one selection and multiple selections. Check page one and a previously high page number. Include null and malformed input as separate cases with documented expectations.
Finish by comparing visible record IDs with the source response. A working table should preserve the intended data and filtering contract, not merely stop displaying an empty-state message.
References reviewed October 19, 2026. Diagrams and test fixtures are explanatory, not customer results.