WooCommerce bulk editor filter not working or lost on page 2

30 January 2027

When the WooCommerce bulk editor filter is not working, the symptom is nearly always the same: the first page of the table shows the right products, and page 2, a change of rows per page, a click on sorting or the variations switch brings back the whole catalogue. In most cases the filter itself is fine. What breaks is the place on the server where BEAR keeps the filter between requests, and that is also why a bulk edit meant for 200 filtered products can end up writing to every product in the shop. Below is how that storage works, the setting that fixes it since version 2.2.2, the old code snippet that can silently undo that setting, and the cases where the filter works exactly as designed but still returns something you did not expect.

How the bulk editor keeps a filter between pages

When you press Filter, the browser sends the conditions once. BEAR saves them on the server under a random key and the page remembers only that key. Every request after that, page 2, a new page length, sorting, the variations switch, the bulk edit, the export, sends just the key, and the server reads the conditions back from storage. If the storage returns nothing, there is nothing to filter by, and the query runs on all products.

That makes the counter under the table the most important number on the screen. Showing 1 to 50 of 226 entries right after filtering, then of 5720 entries on page 2, means the filter was lost between the two requests. The Bulk Edit tab does not show a count; it says Bulk editing will be applied to: the filtered products, and it reads the filter from the same storage. So when the counter jumps, a filter-based bulk edit or export at that moment covers the whole catalogue.

Before every Do Bulk Edit on a filter, look at the counter. If a run has already gone to the wrong products, open the History tab: each bulk operation is recorded with the previous values and can be reverted as one record.

Two things clear a filter by design. Reloading the editor page starts a new page with no key, so the filter is gone; save it as a filter profile if you need it again. And a stored filter expires one day after it was applied, so a tab left open overnight needs the filter applied again before the next bulk run.

The fix: Plugin memory storage set to Option

Open the Settings tab of BEAR and find Plugin memory storage in the General settings column. It has two values: Option (recommended) and Transient. Choose Option (recommended) and press Save all settings. The setting is shop-wide and only an administrator can change it. It exists since version 2.2.2, so update BEAR first if you do not see it.

Why it matters:

Option keeps the filter, the bulk data and the bulk progress counter in one row of the wp_options table per user, named woobe_memory_ plus the user ID, with autoload off so it is never loaded on the shop pages. A database row cannot be evicted. Caches can drop their copy of it, and the next request simply reads it again from the database.
Transient is how BEAR used to work. On a site without a persistent object cache a transient is also a database row, and it works. With Redis or Memcached, WordPress keeps transients only in the cache and never writes them to the database (see the Transients API), so anything that clears the cache destroys the filter. The transient key was also built from the visitor's IP address, which changes between requests behind some proxies and CDNs and is shared by colleagues in one office.

Option is the default for new installations and for updated ones that never saved another value. If the counter still jumps with Option selected, the next section is the most likely reason.

Old woobe_storage_type snippets override the setting

For years the answer to a lost filter was a line in the theme's functions.php that switched the storage to 'session' or 'transient' through the woobe_storage_type filter. That filter still exists, and it runs after the setting is read: whatever the snippet returns wins, whatever is selected in Settings. A site that added the snippet years ago keeps running on sessions or transients after the update, while the Settings tab says Option.

Search the active theme, the child theme, mu-plugins and code snippets plugins for woobe_storage_type. A typical leftover looks like this:

add_filter('woobe_storage_type', function($type) {
    return 'session'; // or 'transient'
});

Delete it, then choose the storage in Settings. Session is no longer offered there: it depends on the PHP and WooCommerce session handling of the server and was the least reliable of the three for a series of AJAX requests. Keep a snippet only if a test on your site shows that the setting alone does not work, and in that case make it return 'option' so it at least forces the storage that survives a cache flush.

Redis, Memcached and other caches

The object cache flush and woobe_use_cache_flush

Before the table rows are built, BEAR calls wp_cache_flush() so that the table shows current values and not what was cached before your last edit. Without a persistent object cache this only clears memory of the current request and costs nothing. With Redis, Memcached or Object Cache Pro it empties the whole cache of the site on every table load, which is what used to wipe the transient with the filter.

With the storage on Option, the flush no longer touches the filter. It still costs the rest of the site a cache rebuild every time the table loads. On a shop with a persistent object cache you can switch the flush off:

// Child theme functions.php or a code snippets plugin.
// BEAR: do not flush the persistent object cache before drawing the products table.
add_filter( 'woobe_use_cache_flush', '__return_false' );

The trade-off: a value changed a moment ago can occasionally show its old version in the table until you reload. The shop front is not affected either way. The hook is listed with the other code-level options on More settings (implicit).

A persistent object cache is often active without anyone installing it: managed hosts and hosting panels enable Redis or Memcached for you. If Plugins in wp-admin shows a Drop-ins list with object-cache.php, you have one.

Page, admin and optimisation caches

Page caches such as WP Rocket, LiteSpeed Cache or WP-Optimize, CDN rules such as a Cloudflare cache-everything rule, and hosting-level caches must never cache /wp-admin/ or /wp-admin/admin-ajax.php. The editor page and every table request go through these addresses, and an administrator needs to see the result of the change just made, not a stored copy. Defaults of the well-known plugins already exclude them; custom rules, server caches on managed hosting and "optimise admin" features are where to look. If the filter works with all caching off and fails with it on, add the exclusions and clear every cache.

When the filter returns nothing or the wrong products

Some results that look like a broken filter are the filter doing exactly what it was asked to do.

A parent category does not include its subcategories

Filtering by a category finds the products assigned to that term. A product assigned only to Shoes > Sneakers is not found by Shoes. Select the subcategories as well, or let the filter include children for the taxonomies you choose:

// Child theme functions.php or a code snippets plugin.
// BEAR: filtering by a parent term also finds products of its child terms.
add_filter( 'woobe_filter_include_children', function ( $include, $taxonomy ) {
    if ( in_array( $taxonomy, array( 'product_cat' ), true ) ) {
        return true;
    }
    return $include;
}, 10, 2 );

EXACT search needs the whole title

The text search behaviours are LIKE, EXACT, NOT, BEGIN and END. EXACT compares with the complete title, ignoring letter case: one word out of a five-word title finds nothing. Use LIKE for part of a title. To search for several texts at once, see multiple titles in the search box.

An exact regular price finds nothing

In the regular price range the lower value is included and the upper value is excluded, so 46.90 to 46.90 is an empty range. Enter 46.90 to 46.91. Prices of variations are searched too: a variable product appears when one of its variations is in the range.

Featured is a field, not a meta key

WooCommerce does not keep Featured in post meta, so a custom meta field added in the Meta Fields tab under a name like featured finds nothing and can break the filter it is used in. Delete such a field and enable the built-in Featured column in Settings instead.

Themes and plugins that change product queries

BEAR selects products with a normal WordPress query, so any code that changes product queries in the admin or in AJAX requests changes the editor's results too. Themes that force their own default product sorting, search plugins that rewrite product search, and transliteration plugins that alter text in queries have all made the filter return the whole catalogue or random products. Open the browser console (F12) on the editor page and check for red errors first. Then switch WooCommerce's default product sorting back to a standard one and test, or find the plugin with the method in isolating plugins during bulk edits, which can also keep such a plugin away from BEAR's requests permanently.

Checklist: confirm the filter holds

BEAR is updated to the current version, and Plugin memory storage is Option (recommended).
No woobe_storage_type snippet is left in the theme, child theme, mu-plugins or a snippets plugin, unless it returns 'option'.
Reload the editor page, apply a filter and write down the count under the table.
Go to page 2, change rows per page, click a column to sort and switch variations on and off. The count must stay the same.
Tick two products, run a small bulk edit on them, and check the record in History. Then run the real operation on the filter.

If the count still changes with Option selected and no snippet in place, open a topic on the BEAR support forum with the BEAR version, the caching and object cache plugins you use, and the two counts you see.