WooCommerce bulk editor changes not saving: find the cause and fix it

WooCommerce bulk editor changes not saving can mean four different things: a value typed into a cell disappears after a reload, binded editing changes only the row you typed in, a bulk edit finishes with products bulked: 0, or the values were saved and came back to the old ones hours later. Each has its own cause, and the editor shows you which one you are looking at if you know where to read it. Below is that reading first, then the fix for each case.

What the symptom tells you

After a cell edit BEAR shows Saving ... while the request runs and Saved. when the server has answered, and the cell is then redrawn with whatever the server returned. After a bulk edit the History tab gets a record with its state and the number of products changed. Together they point to the cause:

Inline edits are saved with Enter

Text and number cells of the Products Editor (title, SKU, prices, stock quantity, weight, dimensions, meta fields) open an input when clicked. The value is sent to the server only when you press Enter, which saves and opens the same cell in the next row, or Arrow Up / Arrow Down, which save and move up or down. Esc cancels. Tab and a click outside the cell send nothing, and clicking another cell closes the open input without saving it. Arrow Left and Arrow Right only move the cursor inside the text. Once you are used to it, this makes a column fast to fill: type, Enter, type, Enter, down the whole page.

Drop-downs, switches and popup editors such as the description save the moment you choose a value or confirm the popup, so they do not need Enter.

For meta fields, an edit that "does not stick" can also be a key typed differently from the real one: BEAR saves under the key you configured, and the product keeps showing the value stored under the real key. Check the key in the Meta Fields tab against the product's custom fields.

Binded editing changes only one product

Binded editing is a switch on the tools panel. With it on, a value saved in one ticked row is pushed to every other ticked row on the page; the push runs as a small bulk operation, which is why it gets a History record of its own. The usual reasons it changes only the row you typed in:

• The switch turned itself off. It switches off as soon as a push starts, so the next field you edit is saved on one row only. Switch it on again before every binded edit.
• Not enough rows ticked. Tick at least two products, including the one you will type in. Ticking works on the current page; for a larger set use a filter and the Bulk Edit tab, as described in setting the same value for several products.
• The field is not available for binded editing. The tooltip next to the switch lists the fields the free version can push; for others an alert says the field is deactivated for bulk edit.
• The push request did not get its data. It uses the same server-side storage and the same admin-ajax.php requests as the Bulk Edit tab, so everything in the firewall and caching section below applies. A JavaScript error in the browser console (F12) also stops it; test in a private window and in another browser to rule out a stale cached script or a browser extension.

Ticked products stay ticked while you keep working on the page, and the Bulk Edit tab gives them priority over the filter: its line Bulk editing will be applied to then names the selected products and their number. Untick them with the uncheck button on the tools panel before a bulk edit that should cover the whole filter, or it changes only the ticked ones.

Edits refused by roles and capabilities

BEAR opens for users who have the WooCommerce manage_woocommerce capability, and every save checks that the user may edit that particular product. A role without edit_others_products can save only its own products; for the others the request is refused and the cell shows 0.

Roles other than administrator are also limited per field. In the Settings tab an administrator ticks visible for the shop manager under each column a shop manager may see and edit, and saves with Save all settings. Columns without the tick are not shown to that role at all. The trap is a fresh installation: until an administrator has saved the Settings tab once, no field is marked yet, so a shop manager sees every column and every edit answers forbidden. Saving the Settings tab as administrator ends it. The FAQ on limiting the shop manager role shows the setup.

For rules the checkboxes cannot express, two filters decide in code. woobe_user_can_edit decides per field for non-administrator roles: return 1 to allow, 0 to refuse.

// Child theme functions.php or a code snippets plugin.
// BEAR: let non-administrator roles edit prices and stock whatever the Settings checkboxes say.
add_filter( 'woobe_user_can_edit', function ( $can_edit, $field_key, $visibility ) {
    if ( in_array( $field_key, array( 'regular_price', 'sale_price', 'stock_quantity' ), true ) ) {
        return 1;
    }
    return $can_edit;
}, 10, 3 );

woobe_permit_special_roles makes a role count as administrator inside BEAR. Use it sparingly: such a role also sees and saves the shop-wide settings, the MCP server settings among them.

add_filter( 'woobe_permit_special_roles', function ( $roles ) {
    $roles[] = 'shop_manager';
    return $roles;
} );

When one administrator account cannot save and another can, the account itself is the problem. BEAR decides by the first role of the account, so an administrator who also carries a second role from a membership or role editor plugin can be treated as that other role, and a role editor can remove capabilities from one account only. Create a fresh administrator, repeat the edit, and compare the two accounts' roles and capabilities.

Firewalls, caching plugins and "products bulked: 0"

Server firewalls. ModSecurity rules, including the Plesk web application firewall, often answer 403 Forbidden to a request that carries HTML, so descriptions and other text with markup stay on Saving .... The firewall log names the rule; disable that rule for the site rather than the whole firewall. The FAQ Description content is not saved shows such a case.

Caching and optimisation plugins. Every save and every bulk step is a request to /wp-admin/admin-ajax.php. Page caches with admin or AJAX caching switched on, "optimise for logged-in users" features, minify and combine of admin scripts, and hosting caches on autoscaling platforms have all intercepted these requests. WP-Optimize and LiteSpeed Cache are typical examples, and in both the fix is to exclude /wp-admin/ from page caching and optimisation; database cleaning and image compression can stay on. To test, deactivate the cache plugin, purge the server cache, repeat the edit, and turn things back on one at a time.

The bulk data storage. The Bulk Edit tab stores the operation on the server and every batch reads it back. If the storage loses it, each batch finds nothing to write and History shows completed with products bulked: 0. Set Plugin memory storage in Settings to Option (recommended) and remove any old woobe_storage_type snippet; the reasons are explained in bulk editor filter not working, the same storage holds the filter.

If none of this applies, a plugin hooked into product saving can still stop or undo a write. Isolating plugins during bulk edits shows how to find it and how to keep it out of BEAR's requests.

Values that change back later

BEAR writes to products only when someone saves in its editor, reverts a record in History, or works through its MCP server when that is switched on. Each of these leaves a History record, and History shows who made the change and whether it was made by hand or through an AI agent. If prices, stock or attributes change back at a moment that has no History record, BEAR did not do it.

Look for whatever else writes to products on a schedule: product import and sync plugins, POS and inventory connectors, ERP and marketplace integrations, supplier feeds, and multilingual plugins that copy fields from the original language to translations. Their logs, or the time of their scheduled tasks in Tools > Scheduled Actions, usually match the moment the value changed.

How to confirm that a change was saved

1. The cell. After Enter it shows the saved value, not forbidden or 0, and Saved. appears.
2. History. The record exists, its state is completed, and products bulked matches the number you expected.
3. The product itself. Open it in Products in wp-admin. The database is the truth; if the shop page still shows the old value, the page cache or a page builder's own cache is serving an old copy (see the Elementor case).
4. The logs. With WP_DEBUG_LOG on, wp-content/debug.log shows PHP errors thrown during the save, and the browser's Network tab shows the status of the admin-ajax.php request: 403 for a firewall, 500 for a PHP error.

If the value is still not saved, open a topic on the BEAR support forum with the field, what the cell shows after Enter, the History record and the status of the request.