Adam Lykkegaard

Thanks for adding the detail about the Facebook widget. That is a useful clue: a JavaScript error from one widget can affect other features on the same page, so the mini-cart could be affected even though the main Cart page still works. Removing the widget and seeing the cart work again makes a script conflict worth investigating, but does not yet prove the exact cause.

For now, I would leave that widget disabled and keep your direct Cart link. In a fresh private window, add a product, visit another page, remove the product, and check that the mini-cart also shows its empty-cart message. Keep the other settings unchanged while checking whether the fix holds.

If it returns, the first browser-console error and the name of the Facebook widget/plugin would help narrow it down. Any test with the widget enabled again should be on a staging copy.

For more detail on separating mini-cart display problems from cart-data problems and checking JavaScript/theme conflicts, see this guide from Hostious, where I work (in Danish): https://hostious.io/woocommerce-kurv-opdaterer-ikke/#loesning-i-sikker-raekkefoelge

That is a useful detail. The action name “wpml_action” points us towards a WPML-related request, but it does not yet show that this is the request responsible for adding the attribute. A background request can fail at the same time.

Are WPML and WooCommerce Multilingual active, and which versions are installed?

For the next test, clear the Network list, click Add for one existing global attribute once, then check all requests created by that click. Does only “wpml_action” fail, or is there another failed request with a different action value? Also check whether the same “wpml_action” 404 appears on a fresh product-editor page before you touch the attributes.

If it fails even without an attribute action, that helps separate the two problems. “File not found” alone is not enough to say whether WordPress, the web server or a proxy generated the 404. Please keep the translation plugins and live settings unchanged while we establish that.

[signature removed by moderators]

Thanks, that gives us something concrete to investigate. The important part is POST /wp-admin/admin-ajax.php returning 404. ‘load-scripts.php:8’ identifies the browser script reporting the failure; it does not establish what caused it.

In Network, select that failed POST and check:

• Does Request URL use the correct domain and WordPress installation path?
• In Response/Preview, is it a normal WordPress 404 page, a hosting/CDN error page, or a short error message?
• What is the ‘action’ value under Payload/Form Data? Share only that value and the short error text, not cookies, nonces or a full request export.

Reload the product editor before repeating the same test on your draft/staging product. If it happens again, note the exact time and ask your host to compare the failing POST with a successful one in their access/error logs. That should help identify which layer returns the 404 before changing hosting, permalinks or plugins on guesswork.

Does the failure happen when adding an existing global attribute to the product, or when creating a new attribute value?

[signature removed by moderators]

Hi @charmedchicken. The useful clue is the caller in the exception: ‘from scope WC_NYP_Store_API’, not just the file where WooCommerce catches it. That points towards a Store API integration trying to call a method it cannot access.

Are you using the Name Your Price extension? If so, please check its version separately from WooCommerce’s version. Updating WooCommerce alone does not update that extension.

On a staging copy, temporarily deactivate only Name Your Price and repeat the exact action that produces the error. If the error disappears, that isolates the integration; it does not mean you should leave it disabled on the live store, where products may depend on it. Please don’t edit ExtendSchema.php or change the protected method to public.

Which exact WooCommerce, Name Your Price and PHP versions are installed, and does this happen when loading a product, cart or checkout? If the staging test points to Name Your Price, its developer’s support is linked here: https://woocommerce.com/document/name-your-price/

Adam

Thanks, that helps: the main Cart page being correct narrows the problem to how the mini-cart is displayed or refreshed.

The code you posted reloads the whole page when either of those events fires; it does not refresh only the mini-cart. It is worth testing without it, but the snippet alone is not evidence that it causes the empty mini-cart.

On a staging copy, save the original snippet, temporarily disable just that snippet, clear the plugin and hosting caches, and repeat the same add/remove-product test. Keep the other settings unchanged for this comparison. If nothing changes, the snippet is less likely to be the cause. Please avoid editing the live theme files just to test this.

One useful detail: when the mini-cart is empty, does a normal browser refresh on that same page make the products appear? Also, let us know the result of the page-cache-off test before changing any more cache plugins.

Adam

Yes — that split state is consistent with execution stopping after the item-level stock updates but before WooCommerce persists the order-level flag. In core, wc_maybe_reduce_stock_levels() first calls wc_reduce_stock_levels(). That function reduces each line item and saves its _reduced_stock value. Only after it returns does WooCommerce call set_stock_reduced( $order_id, true ). So an uncaught Throwable, PHP-FPM worker termination, timeout/OOM, or a failure in a callback fired during stock notifications can leave the line items reduced while _order_stock_reduced remains false.

I would add temporary before/after logging around wc_maybe_reduce_stock_levels and the hooks woocommerce_reduce_order_item_stock and woocommerce_reduce_order_stock, plus a shutdown handler that records error_get_last(). Also check the PHP-FPM and web-server logs, not only WordPress error_log, because a killed worker may never reach the WordPress logger. The missing stock note and emails make the notification/callback part of the sequence especially worth instrumenting.

For the affected order, reconcile the physical product quantities against each line item’s _reduced_stock before changing any order-level flag manually; flipping the flag without that reconciliation can create a second inventory error.