Support Forum

SupportWordPress&WooCommerce Plugins: BEAR - WooCommerce Bulk Editor and Products Manager Professional (old name is WOOBE)Filter lost on pagination + filte …

You need to log-in to create request (topic) to the support

Filter lost on pagination + filter bulk can hit entire catalog + progress stuck at ~98% (v2.2.1)

The support doesn work on Saturdays and Sundays, so some Friday requests can be answered on Monday. If you have problems with registration ask help on contact us page please
If you not got email within 24~36 business hours, firstly check your spam box, and if no any email from the support there - back to the forum and read answer here. DO NOT ANSWER ON EMAILS [noreply@pluginus.net] FROM THE FORUM!! Emails are just for your info, all answers should be published only here.
The support doesn work on Saturdays and Sundays, so some Friday requests can be answered on Monday.
Support notice: Our support team will be on vacation from August 8 to September 3, so response times may be delayed and replies may be irregular.

webnestors(@webnestors)

10 Posts

Customers

August 3, 2026, 14:11

Hi,

We use BEAR 2.2.1 on a large WooCommerce catalog (~60k products).

1) Filter does not persist across DataTables pagination

Open BEAR Products
Apply a Filter (result set e.g. ~1,600–1,800 products)
Go to page 2 / 3 of the products table

Expected: filtered set stays applied
Actual: filter is lost; table no longer respects the filtered scope

This also makes filter-based bulk unreliable, because bulk depends on filter_current_key / filter storage.

2) “Bulk editing will be applied to: the filtered products” — no product count

In Bulk Edit, the notice only says “the filtered products” with no number.
There is no way to verify how many products will be affected before confirming.

3) Filter-based bulk can run on the entire catalog

When using Bulk Edit without checkboxes (only an active filter):

UI suggests it will edit filtered products
Confirm dialog only lists fields (e.g. “Will be edited next: sale price”) — still no count
In our case, a bulk intended for ~1,780 filtered products started processing tens of thousands (essentially the whole catalog)

So when the filter key/storage is missing or not applied during woobe_bulk_products_count, BEAR appears to fall back to all products, which is dangerous on large shops.

4) Progress UI inconsistency after bulk finishes

After a bulk that actually completed:

Main progress bar shows 100%
Admin bar still shows: “ATTENTION: Bulk operation is going! ~98.57%” and stays stuck until page refresh

Environment

WordPress + WooCommerce (large catalog)
BEAR 2.2.1
PHP 8.1

Please advise if these are known issues and whether a fix is planned. Happy to provide HAR/screenshots if needed.

Thanks

Alex Dev(@alexdev)

1,160 Posts

August 3, 2026, 19:23

Quote from Alex Dev on August 3, 2026, 19:23
Hello
Thank you for the detailed report. Let us start with the part that is under your control right now.
The filter data that must survive between requests is kept in a storage layer. By default BEAR uses transients for it. On many sites this works without any problem, but on a site with a lot of plugins something else can interfere with that storage and destroy the record between two requests. When the record is gone, the filter is no longer known on the server side. That is exactly what you are describing: you apply the filter, you go to page 2, and the scope is no longer there.
BEAR has a switch for this. Add this to the functions.php of your active theme, or to a small mu-plugin:
add_filter('woobe_storage_type', function($type) {
return 'session';
});
Documentation: https://bulk-editor.com/document/more-settings-implicit
Please do not put this straight on the live shop. Make a clone of the site first, on the same hosting, so the environment is identical, and test there: apply a filter, walk through several pages of the products table, and confirm that the filtered scope stays. Only then move it to production.
Now our opinion on why this happens at all.
We see these reports periodically, and they always come from sites with a heavy plugin stack. Transients are stored either in the database or, when a persistent object cache is installed, in Redis or Memcached. In the second case they are not persistent at all in the way one would expect: the cache can evict them at any moment under memory pressure, silently. Something else can flush them wholesale. Sessions have the mirror problem: another plugin can start or close the session, or the server can be configured in a way that breaks it. Which of the two storages survives on a given site is not something we can predict from here, which is why the switch exists in both directions.
The count of filtered products is already shown to you. The products table prints it in the bottom left corner of the pagination, in the form "Showing 1 to 10 of 23 entries". That number is the size of the current filtered set, and you can read it before starting a bulk.
1,3,4 - relatated to the storage issue described above
Place please actual purchase code of the plugin into the private area of this ticket:
https://share.pluginus.net/image/i20230222134241.png
https://share.pluginus.net/image/i20230222134615.png
https://share.pluginus.net/image/i20230222134511.png

Hello

Thank you for the detailed report. Let us start with the part that is under your control right now.

The filter data that must survive between requests is kept in a storage layer. By default BEAR uses transients for it. On many sites this works without any problem, but on a site with a lot of plugins something else can interfere with that storage and destroy the record between two requests. When the record is gone, the filter is no longer known on the server side. That is exactly what you are describing: you apply the filter, you go to page 2, and the scope is no longer there.

BEAR has a switch for this. Add this to the functions.php of your active theme, or to a small mu-plugin:

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

Documentation: https://bulk-editor.com/document/more-settings-implicit

Please do not put this straight on the live shop. Make a clone of the site first, on the same hosting, so the environment is identical, and test there: apply a filter, walk through several pages of the products table, and confirm that the filtered scope stays. Only then move it to production.

Now our opinion on why this happens at all.

We see these reports periodically, and they always come from sites with a heavy plugin stack. Transients are stored either in the database or, when a persistent object cache is installed, in Redis or Memcached. In the second case they are not persistent at all in the way one would expect: the cache can evict them at any moment under memory pressure, silently. Something else can flush them wholesale. Sessions have the mirror problem: another plugin can start or close the session, or the server can be configured in a way that breaks it. Which of the two storages survives on a given site is not something we can predict from here, which is why the switch exists in both directions.

The count of filtered products is already shown to you. The products table prints it in the bottom left corner of the pagination, in the form"Showing 1 to 10 of 23 entries". That number is the size of the current filtered set, and you can read it before starting a bulk.

1,3,4 - relatated to the storage issue described above

Place please actual purchase code of the plugin into the private area of this ticket:
https://share.pluginus.net/image/i20230222134241.png
https://share.pluginus.net/image/i20230222134615.png
https://share.pluginus.net/image/i20230222134511.png