Quote from Alex Dev on July 31, 2026, 11:46

Hello Kevin

Thank you for the detailed report, and especially for listing the oddities you noticed. That saved us time.

Before answering I reproduced your exact scenario on a clean development server. Here is everything I did and everything I checked, so you can see this is not a brush off.

WHAT THE TEST ENVIRONMENT WAS

Fresh WordPress install, WooCommerce and BEAR only, no other plugins, default WooCommerce theme.

WHAT I BUILT

1. Created two global attributes through WooCommerce, Products then Attributes: Color and Size, with terms blue, green, small, medium.
2. Created a variable product, product ID 3649. On the Attributes tab I added both Color and Size and ticked Used for variations.
3. Generated four variations, IDs 3650, 3651, 3652 and 3653, covering blue/medium, blue/small, green/medium and green/small.
4. Gave every variation a regular price and a sale price, so there was an actual sale price to remove.
5. Confirmed on the storefront that the product page showed both dropdowns and all four variations worked.

WHAT I RECORDED BEFORE THE OPERATION

Three queries against the database.

SELECT meta_value FROM wp_postmeta WHERE post_id = 3649 AND meta_key = '_product_attributes';

SELECT post_id, meta_key, meta_value FROM wp_postmeta WHERE post_id IN (3650,3651,3652,3653) AND meta_key LIKE 'attribute_%';

SELECT object_id, term_taxonomy_id FROM wp_term_relationships WHERE object_id = 3649;

Result of the first query before the operation:

a:2:{s:8:"pa_color";a:6:{s:4:"name";s:8:"pa_color";s:5:"value";s:0:"";s:8:"position";i:0;s:10:"is_visible";i:1;s:12:"is_variation";i:1;s:11:"is_taxonomy";i:1;}s:7:"pa_size";a:6:{s:4:"name";s:7:"pa_size";s:5:"value";s:0:"";s:8:"position";i:1;s:10:"is_visible";i:1;s:12:"is_variation";i:1;s:11:"is_taxonomy";i:1;}}

The second query returned eight rows, attribute_pa_size and attribute_pa_color for each of the four variations. The third query returned seven term relationships for the parent product.

THE OPERATION ITSELF

I selected all four variations in BEAR, opened the Bulk panel, ticked Sale price only, chose set new, entered 0.00 and ran it. Exactly what you described.

WHAT I RECORDED AFTER THE OPERATION

Sale prices were removed on all four variations, as expected.

The first query returned byte for byte the same value as before:

a:2:{s:8:"pa_color";a:6:{s:4:"name";s:8:"pa_color";s:5:"value";s:0:"";s:8:"position";i:0;s:10:"is_visible";i:1;s:12:"is_variation";i:1;s:11:"is_taxonomy";i:1;}s:7:"pa_size";a:6:{s:4:"name";s:7:"pa_size";s:5:"value";s:0:"";s:8:"position";i:1;s:10:"is_visible";i:1;s:12:"is_variation";i:1;s:11:"is_taxonomy";i:1;}}

The second query returned the same eight rows with the same values. The third query returned the same seven term relationships. Nothing was removed anywhere.

I also checked what the plugin itself logged. BEAR writes every bulk run into its own history table, including the exact list of fields that took part in the run:

SELECT bulk_key, set_of_keys, products_count, started FROM wp_woobe_history_bulk ORDER BY id DESC LIMIT 10;

For my run the set_of_keys column contained only ["sale_price"], with products_count 4. In other words the plugin touched one field and one field only.

You can run that same query on your own site. If your row for that operation also lists only sale_price, that is direct evidence from the plugin's own log that it never wrote to your attributes.

WHAT THIS MEANS

The bulk sale price removal on variations does not touch product attributes, variation attribute assignments or term relationships. On a clean installation the operation is safe. So something else on your site is reacting to the product being saved and modifying the attributes.

This is a common pattern. When a variation is saved, WooCommerce regenerates its title and updates the post, which fires the standard WordPress save hooks. A third party plugin listening on those hooks may look for product edit screen data, not find it because the save came from a bulk tool rather than the product edit page, and conclude that the attributes were cleared. Plugins that commonly behave this way are attribute swatch plugins, variation generators, product import and synchronisation tools, feed generators and anything that advertises extra control over variations.

WHAT I SUGGEST YOU DO

1. Make a copy of your site on a staging or local environment, alongside the live one. Do not test on production.
2. On that copy, deactivate every plugin except WooCommerce and BEAR.
3. Switch the theme to a basic one. Storefront is the safest choice, but any default theme will do.
4. Pick a test variable product with variations that have sale prices, and repeat exactly what you did before: select the variations, tick Sale price, set new, 0.00, run.
5. Check the product afterwards. If the attributes and variations survive, we have confirmed the same result you can see in my test above, and the cause is one of the deactivated plugins or the theme.
6. Now reactivate plugins one at a time, and after each one repeat the test on a fresh product. Start with the ones most likely to be involved: anything dealing with attributes, swatches, variations, imports or synchronisation.
7. The plugin that is active when the attributes disappear again is your culprit.

This takes a while but it is the only reliable way to find which code is interfering, and it usually surfaces the answer within the first few plugins if you start with the likely suspects.

One more thing worth knowing. BEAR's History panel records the previous values for every change, which is why your rollback worked. Keep History enabled while you test, so you can undo anything quickly.

Once you identify the plugin, let me know which one it is. If it turns out there is a compatibility issue we can address on our side, we will look at it

p.s. your support is expired, please buy new lisense here: https://bulk-editor.com/downloads . We moved from CodeCanyon and its not possible to renew the support there. In the private area of this ticket please place new purchase key.