WooCommerce price not updating on frontend after a bulk edit

The bulk editor says Saved., the product edit screen shows the new value, and the shop still shows the old price, the old description or variations that cannot be selected. A WooCommerce price not updating on the frontend after a bulk edit almost never means that the edit was lost. It means that something between the database and the page the visitor sees is showing an older copy, or a different value altogether. Confirm where the new value really is, then go through the layers below in order.

First check that the change reached the database

Open one affected product in Products in wp-admin, the normal WooCommerce product editor, not BEAR. What it shows is what is stored in the database.

• The product editor shows the old value too. The change was not saved, and caches are not the problem. Follow bulk editor changes not saving instead.
• The product editor shows the new value. The data is right. Everything below is about display.

The History tab tells you what a bulk operation actually touched. Every bulk run is stored with the list of fields that took part in it, so you can also read it straight from the database (replace wp_ with your table prefix):

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

If set_of_keys of your run lists only ["sale_price"], BEAR wrote the sale price and nothing else. Keep this in mind for the variations section further down.

Finally, look at the shop in a private browser window where you are not logged in. Page caches usually skip logged-in administrators, so the shop can look right to you and wrong to every visitor, or the other way round.

Caches between the database and the shop page

When BEAR saves a product, it clears the same caches WooCommerce clears when you press Update in the product editor: the product transients and the object cache entries of the product, and of its parent product when the edited row is a variation. Prices, stock and the other WooCommerce properties are saved through the WooCommerce product object itself, so the stored _price and the price range of a variable product are recalculated the usual way.

What BEAR does not clear are caches that sit outside WooCommerce:

• Page caches. Caching plugins, server caches such as Varnish or Nginx FastCGI cache, and CDNs such as Cloudflare store the finished HTML of product and category pages. Many of them purge one page when a post is saved in the editor; a bulk edit changes hundreds of products in one go, and not every cache reacts to that. Purge the whole page cache, and the CDN cache, after a large bulk edit.
• Persistent object caches. Redis or Memcached keep data of other plugins and of the theme as well. If the shop still shows old values after the page cache is purged, flush the object cache from the hosting panel or the caching plugin.
• WooCommerce tools. In WooCommerce > Status > Tools, run Clear transients, then Regenerate next to Product lookup tables and next to Regenerate the product attributes lookup table. The lookup tables hold copies of prices, stock and attributes that WooCommerce uses for sorting by price, the price filter and attribute filtering, so a stale table shows up as wrong sorting or filtering even when the product page is right.
• Your own browser. A hard reload rules it out; resetting the page cache in the browser lists the keys.

The price is saved but the shop shows another one

If no cache explains it, the shop is showing a price that is calculated from the stored one, or taken from somewhere else. BEAR writes the stored WooCommerce prices; it does not decide what the storefront displays.

Discount and dynamic pricing plugins belong in the same group: they change the displayed price on the fly. Switch them off for a moment on a staging copy to see the stored price.

Description not updating: page builders and theme templates

BEAR writes the product description to the standard WordPress content field and the short description to the excerpt, the same fields the WooCommerce product editor uses. A page that prints something else will not change.

Elementor

An Elementor-built product page does not read the content field. Elementor stores the whole layout, including the text you typed into a Text Editor widget, in its own _elementor_data meta field. If the description on the page is static text inside a widget, no change made outside Elementor will ever show there. The lasting fix is to make the widget read the product: in the Elementor editor, click the description widget, open the dynamic tags icon of its text field and choose Product Content (Product Short Description for the short text), then publish. Dynamic tags are part of Elementor Pro. The styling of the widget stays, and from then on every BEAR edit appears on the page.

When the widget already reads the product but the page still looks old, Elementor's own generated files are the cause: use Elementor > Tools > Regenerate Files & Data (Regenerate CSS & Data in older versions), which is separate from any caching plugin. Description not updating with Elementor has code that clears that cache automatically whenever a product is updated.

Divi and other builders

When Use the Divi Builder is switched on for a product, Divi keeps the product's layout in the description field. BEAR then shows Divi layout code in the Description column, and replacing it replaces the layout. For products whose description you manage in bulk, keep the builder off on the product itself and design the product page with a template that prints the WooCommerce description. Other builders keep the text in their own meta field; the Avion builder is one, and the Avion FAQ shows how to attach that field in BEAR.

Themes and other plugins

Some themes print a subtitle or a second description from their own meta field, and plugins for related products, badges or custom tabs keep their data in meta fields and often cache their output. If an element on the page ignores your change, find out which field it really reads, as described in finding a product meta key, and edit that field. If the field is right and the output is still old, that plugin keeps its own cache.

Variations not selectable or gone after a bulk edit

Two symptoms come up after price edits on variable products: the product page shows only the price range and Please select some product options before adding this product to your cart. after a size is chosen, or the variations and attributes disappear from the product altogether.

Start in the product editor. On the Attributes tab, each attribute the variations use must be there with Used for variations ticked. On the Variations tab, each variation must be enabled, have a price and have a value for every attribute. A variation without a price cannot be bought, and a parent without its attributes shows no choices at all, which is also the usual reason why variations created in bulk do not appear on the shop.

If the admin side is complete, the storefront is reading outdated data: clear transients and regenerate both lookup tables as described above, flush the object cache, purge the page cache, and test with a default theme such as Storefront.

If the attributes are really gone, compare with History. A bulk change of a sale price writes the sale price only; it does not touch the attributes, the variation attribute values or the product's terms. But every save of a product fires the usual WordPress and WooCommerce save hooks, and a plugin that listens to them can react to a save that did not come from the product edit screen by clearing data it expected to find in that form. Swatch plugins, variation tools, import and sync plugins and feed generators are the usual suspects. Roll the operation back in History, then repeat it on a staging copy with only WooCommerce and BEAR active and enable the other plugins one by one. Isolating plugins during bulk edits shows how to keep such a plugin out of BEAR's requests for good.

If the shop still shows the old value

1. The product editor in wp-admin shows the new value; otherwise it is a saving problem.
2. History lists the operation with the fields you expected and nothing more.
3. Page cache, CDN cache and object cache are purged, and the shop is checked in a private window.
4. Clear transients and both lookup table tools in WooCommerce > Status > Tools have been run.
5. Scheduled sales, tax display, currency, role pricing and translations are ruled out for prices.
6. The element that shows the description reads the WooCommerce field, not a builder's or theme's copy.
7. With only WooCommerce, BEAR and a default theme on a staging copy, the change shows.

If all of that holds and the shop still shows the old data, open a topic on the BEAR support forum with the product ID, the field, what the product editor shows and what the shop shows.