WooCommerce bulk editor not loading: stuck spinner and DataTables errors

A WooCommerce bulk editor not loading shows up in one of three ways: the loading animation never goes away, a DataTables warning pops up and the table stays empty, or the page appears but the table is broken or blank, often right after an update. BEAR itself rarely changes between one day and the next, so the cause is usually something that did: a plugin or theme update, a cached script, a server setting, or a product whose data cannot be sent to the browser. Below is how the editor page loads, how to see in a few minutes which step failed, and the fix for each case.

How the editor page loads

Opening Products > BEAR Bulk Editor runs two steps:

1. The page arrives with the panels (Filters, Bulk Edit, Export, Settings) already built on the server, behind a loading animation. The editor's scripts then start in the browser, set up the panels and the table, and hide the animation. A JavaScript error during that start-up stops the script before it gets there, so the animation stays forever.
2. The table asks the server for the rows of the first page: a POST request to /wp-admin/admin-ajax.php with action=woobe_get_products. The answer is JSON that starts with {"draw":. If it is anything else, the table library stops and shows its warning: Invalid JSON response when the server answered with something that is not JSON, Ajax error when the server answered with an error status.

So you need two tools of the browser, both under F12 (Cmd+Option+I on a Mac): the Console for step 1 and the Network tab for step 2.

First checks after an update

• Update BEAR, WooCommerce and WordPress to current versions. An old BEAR on a new WordPress or WooCommerce is a frequent reason for a broken page.
• Clear the browser cache completely, not only cookies, and reload with Ctrl+F5. The FAQ how to reset page cache in the browser shows how. Then purge every server-side cache: the cache plugin, the hosting cache, the CDN.
• Open the editor in a private window, and in a second browser. If it works there, the problem is in the first browser: its cache, an extension, or a stored redirect.

BEAR's own script files carry the plugin version in their address, so after an update a browser normally fetches the new ones. What keeps old code alive is an optimisation layer that combines or minifies admin scripts into its own files, such as Autoptimize-style plugins, server optimisation modules or Cloudflare features, and keeps serving the combined file built before the update. Exclude /wp-admin/ from those features.

Errors in the browser console

Reload the editor page with the Console open and read the red lines. The file name at the right of each error tells you whose code it is.

• jQuery.growl is not a function, wpColorPicker is not a function and similar. BEAR loads its jQuery add-ons and they are gone by the time its script runs. Typically another plugin or the theme loads a second copy of jQuery on admin pages, which replaces the one the add-ons were attached to, or an optimiser changed the order of the scripts.
• Errors from another plugin's file. One script error can stop every script that runs after it on the page. Fix or remove the plugin that throws it.
• Maximum call stack size exceeded. The browser ran out of stack while building the interface. It happens on shops with a very large number of taxonomies or terms: every product taxonomy with all its terms is drawn into the Filters and Bulk Edit panels. The panels draw taxonomies whatever columns are switched on, so the fix is to keep heavy taxonomies out of them with the code filters explained in bulk edit thousands of WooCommerce products. They go into the theme or a snippets plugin, so they work even while the editor does not open.

To find which plugin is responsible, deactivate everything except WooCommerce and BEAR on a staging copy, confirm the editor loads, and activate the others one by one, checking the console each time. Isolating plugins during bulk edits shows how to keep a plugin you need away from the editor's requests without deactivating it for the whole site.

DataTables warning: Invalid JSON response or Ajax error

In the Network tab, type admin-ajax into the filter field, reload, and click the request whose payload contains woobe_get_products. Read its status and its Response tab.

Output before the JSON and PHP errors

Notices printed into the answer come from WP_DEBUG being on with display on, or from a plugin that echoes text in admin requests. Log errors to a file instead of printing them, in wp-config.php above the line that says to stop editing:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Reload the editor, then open wp-content/debug.log. The last PHP Fatal error or warning names the file, and its path names the plugin or theme. A log viewer plugin such as Error Log Monitor or Query Monitor shows the same inside wp-admin. The WordPress debugging guide explains the options.

Two causes come up again and again. Allowed memory size exhausted means the request needs more PHP memory than the server gives it; lower Default products count per page in the Settings tab and see the memory section of the large catalogue article linked above. And a broken translation file: switch your profile language to English in Users > Profile and reload. If the editor opens, look in wp-content/languages/plugins/ for files named woo-bulk-editor- plus your locale. A file there takes priority over the translation bundled with BEAR; delete it, and BEAR falls back to its own.

An empty response: one product breaks the page

If the editor loads with some filters and fails with others, or fails on one page of the table, one product carries text that cannot be encoded: a title, attribute or category name with broken characters after an import or a failed migration, or attribute names that still contain HTML tags and links from the old shop. Set 10 rows per page and move through the pages; the page that fails contains it. Correct the text on the product's own edit screen, or in Products > Attributes and Categories, and the table loads again.

403: admin-ajax.php is blocked

The whole editor works through admin-ajax.php. Rules in .htaccess, a security plugin's firewall, a hosting firewall or a CDN rule that block or challenge it break the table and every save. Find the rule in the log of whatever blocked it and allow the request.

When the page itself does not open

• 404 in one browser, works in a private window. The browser has stored an old redirect for the editor's address. Clearing cookies does not remove it; clear cached images and files as well. If it fails in every browser, open Settings > Permalinks and press Save Changes to rebuild the rewrite rules, and check redirect plugins and .htaccess rules for the /wp-admin/ addresses.
• No BEAR Bulk Editor item in the Products menu. The editor is shown to users with the WooCommerce manage_woocommerce capability; administrators and shop managers have it by default, other roles only if it was given to them.
• The page loads, but variable products are missing or counts look wrong. Some themes and plugins change product queries everywhere, admin requests included. Theme options that show variations as separate products, such as the one in Woodmart, are an example. Switch the option off while you edit, or ask the theme authors to keep it out of admin AJAX requests.

It loaded, but something is missing

Some things look broken and are not:

• The Do Bulk Edit button appears only after you tick at least one field in the Bulk Edit tab.
• The New Product button on the tools panel is hidden while a filter is active; reset the filter to see it.
• The Filters, Bulk Edit and Export panels open with the Show: Filters/Bulk Edit/Export button above the table.
• Columns you switched off in the Settings tab are neither shown nor exported. The Products Editor documentation describes the table and its tools panel.

Checklist

• BEAR, WooCommerce and WordPress are up to date; browser and server caches are cleared.
• The console shows no red errors on the editor page, or the plugin that throws them is found.
• The woobe_get_products request returns 200 and a response that starts with {"draw":.
• WP_DEBUG_DISPLAY is off and debug.log has no fatal error from the last reload.
• /wp-admin/ and admin-ajax.php are excluded from caching, script optimisation and firewall challenges.

If all five are true and the editor still does not load, open a topic on the BEAR support forum with the BEAR version, the console errors, and the status and first lines of the woobe_get_products response.