SELECT COUNT(DISTINCT taxonomy) AS total_attributes
FROM wp_term_taxonomy
WHERE taxonomy LIKE ‘pa_%’;

SELECT COUNT(*) AS total_attribute_terms
FROM wp_terms
WHERE term_id IN (
SELECT term_id
FROM wp_term_taxonomy
WHERE taxonomy LIKE ‘pa_%’
);

The problem we are facing is that at times our product filters in the category pages were failing. This is because the product filters in order to determine which products to show on each category were utilising the wp_wc_product_attribute_look up table.

Following extensive debugging, we realised that when the lookup table we set to be updated dynamically, when the stock was changing for product with over 200 attribute terms, it was failing. It was corrupted. Here you can see such one such product with 268 variations: Aloha Ημιμ?νιμο Βερν?κι Eight Color Coat 8ml – Femme Fatale (femme-fatale.gr)

I wonder what we can do in order to sort out the update and make sure that the dynamic update code is not failing.

Note that we are using a 96GB server that has less than 30% CPU utilization whereas our database has a max memory limit of 60GB and usually 45GB is available.

The site (on the front end is one of the fastest woocommerce stores ever developed – i.e. this product with the 268 variation, loads at 0.8s (Latest Performance Report for: https://femme-fatale.gr/product/nychia/imimonima-vernikia/xromata/aloha-imimonimo-verniki-eight-colo… | GTmetrix). So, I am inclined not to buy even a hint that our server could be better tuned and that responsible for the failing is our infrastructure.

Are there any plans to make the dynamic population of the wp_wc_product_attributes_lookup more robust, as nowadays, Woocommerce is becoming the platform of choice for more demanding eshops?

Also note that in our case, for 8958 products – the manual regeneration of the wp_wc_product_attributes_lookup via the tools sections takes about 2 hours.


Thank you.

Please also refer to these (partly additional) issues:
Major bug in product inventory status | www.ads-software.com
Hide out of stock items from the catalog – the case where it doesn’t work | www.ads-software.com

Suffices to say that all along we were taking for granted that the wp_wc_product_attributes_lookup is always correct – was our datum. We invested 100s of man hours on this effort that led to this rather unfortunate finding/conclusion.

We are using the default order status from WooCommerce.

“Aguarda pagamento” is our translation to on-hold

“Paga. A entregar no dia escolhido” is our translation to processing

Behavior As-is

Stock is decreased once the order is paid: https://imgur.com/a/YDKduXp

Behavior Only critical plugins and storefront theme installed

Same behavior: stock is decreased only when the order status changes to processing: https://imgur.com/a/EDKAVu0

Plugins installed: https://imgur.com/a/H3Akuy8

After pausing EuPago plugin, the stock decreases as soon as an order is made (even with the on-hold status), which is the standard behavior from WooCommerce: https://imgur.com/a/LoOzkiM

Therefore, EuPago plugin is not handling the stock changes in the proper manner. Could you please solve this issue?

Best regards,

Ricardo Franco

Please can you assist.

Thank you
David

Thanks

Georgie

The only fix for now is to manualy change the amount of product available, after cancelling the order.

Would it be possible to fix so that it’ll automaticaly update the stock with the right amount of available products, once I or the customer cancel the order?

I′m having an issue with stock updating (I use WC built-in .csv importer) – when I update the stock of each location, it all works fine, but the WooCommerce default stock does not update (remains the same) as shown here: LINK
In the screenshot, you can see that the locations stock add up to 24 (9+2+3+6+4), but WC default stock remains at 22 where it was before.

The default WC stock updates and comes to sync with locations stock only when I open each product edit page and update each product one by one. That is not sustainable as I have 470+ products and growing every day.

So the issue is, that the default stock does not represent the sum of the locations stock.

i updated the plugin yesterday from 4.6.1-beta-1.9 to 4.6.3
im using crom jobs to automatically update my stock, regular price and sale price from a URL file (which update itself every 5 minutes)
the cron job runs every 15 minutes (trigger) and processing every 3 minutes.

well, since the update, it doesnt update automatically and my question is:
it doesnt update bc the file hasnt change? (it actually didnt change any value yet) or is there any problem?
it worked fine before the update

From my supplier i have a csv file to download from there system that i can import to WP-All import using upload file option.

But since its not a url i am wondering if its possible to auto update the stock quantity ?

i really need that function using import file option because whenever i download the file from the supplier webpage the stock in that file remain update but some how i can not use the url directly to Wp ALL import.
Is there a way around to solve this issue?
Thanks