Update cache on stock in

diggle

Hi there,
I keep on finding that users don't see updated pages when the PO is marked as received. I think this issue is that this action is not triggering a cache refresh, as it goes away when I manually refresh.
We use https://wordpress.org/plugins/nginx-helper/ and a forked version of Redis Object cache.

Do you have any ideas of what we can do on this end, or is ther anything you can do?
Thanks

Salva

Hi diggle

I'd suggest you add everything within /wp-admin to the caching exclusion list (if possible), to avoid problems with cache on the backend.

Best Regards,
Salva.

diggle

Hi Salva
It's actually kind of the other way round. Caching is good. But I want it to get cleared when something is updated. Here's my problem scenario: We're out of stock of widgets. We use the YITH Waiting List plugin to let people sign up to be notified when widgets come back into stock (this is brilliant by the way). We mark the PO as Received. YITH Waiting List recognises this and sends emails to the customers.

But the product page cache is still showing out of stock, and the cache has not been cleared. So when the customer comes to the product page, he is presented with an invitation to be notified when we are back in stock! Purely because the cache has not been updated. I have learned to purge the cache manually on receiving stock because quite a few times we see people signing up for a waiting list of things we have in stock. If it wasn't for the waiting List plugin, I wouldn't realise that customers were still seeing the stale cache.

I suspect that at the time of updating stock in the database, ATUM needs to force a save of the product page that would be the trigger for a cache refresh.

Salva

Hi diggle

Are you using any ATUM add-on like Multi-Inventory or Product Levels?
Because with the ATUM's free plugin, we don't change the stock status in the front-end at all. So are you sure this is related to ATUM?

Anyway, we can't give support for caching systems. So you should investigate this issue on your own or try to ask this on Stack Overflow.

Best Regards,
Salva.

diggle

Hi @Salva
No. I did try Multi inventory, for batch/expiry management, but it was too time consuming to book things in. I am using the Free plugin.
I think there must be some misunderstanding because Purchase Orders and Stock Central are part of the Free Plugin, and they both can change stock levels, and consequently stock status, to make a product available for sale.
The reason I think it is an ATUM issue is that cache clearance is correctly triggered by updating stock manually in a product, but if it is done via Stock Central or Purchase orders, that doesn't happen. This suggests some non-standard behaviour.
Thanks.

Salva

Hi diggle

And if you disable ATUM, don't you have this issue anymore?

Anyway, as I've already said, we don't give support for 3rd party caching systems. If you don't use cache and ATUM works fine, perhaps you should contact the caching plugin support or ask on Stack Overflow as I previously suggested. We cannot help you here as this is out of the scope of our free support.

Best Regards,
Salva.

diggle

Hi, I'm still having this issue, and mentioned it in another forum related to the caching, which is redis page caching. One person said: "Your plugin developer is not wp-cache api compliant if this is happening … they are writing directly to the database instead of using the correct table update api".
Could this be the issue? ...is ATUM writing directly to the db when updating stock?
I totally understand that free plugins have very limited support, and that you would not support 3rd party caching systems. But (a) it sounds like this is not due to the caching system being non-standard, and (b) I have just renewed a premium add-on.
Many thanks for your help.

japiera

Hi diggle ,

Thanks for your update

You seem to be mixing several distinct concepts: the WP Object Cache class, the WooCommerce Rest API, and the WooCommerce datastores.

We always use the WP Object Cache class to manage the distinct variables we store in the cache (but that doesn't affect your current problem).
We don't use the WooCommer Rest API in back-end processes. We only extend it for the ATUM Rest API. It doesn't apply either to your problem.
We always use the WooCommerce standard methods to update products. Indeed, we use the wc_update_product_stock() function to update the product stock when completing a Purchase Order (so no, we don't update directly the database here). This seems to be your issue.

It seems related to the fact that the cache plugin isn't detecting the use of the wc_update_product() function so it doesn't reset the product cache. Why they don't detect that? We can't know, but it doesn't seem an issue related to ATUM (especially considering that the YITH plugin does detect the change).

Best Regards,
José Andrés

diggle

japiera Thanks. This should help us solve it.

diggle

Ok I think I am starting to understand better what is going on.
Redis and any other properly-built cache works off native wp-cache, NOT detecting functions such as wc_update_product(). So if a significant event is triggered, such as a product update, and wp-cache does not natively cause the cache to be invalidated (this is what seems to be happening), then the plugin triggering the event should actively invalidate the relevant groups in wp-cache so they can be flushed.
On the other hand, a waitlist plugin with a very narrow function would only watch for the specific wc_update_product() function, and would not follow wp-cache.
Does that make sense?
Best wishes

japiera

Hi diggle ,

Sorry, I doubt that cache plugins store their that using the wp-cache. Even if that were the case, we can't know which cache keys/groups they use to store the data. Each of them would use their own keys, and we can't remove the entire WordPress cache each time a product has its stock updated. Nor can we know which groups/keys use each of the thousands of existing cache plugins.

The waitlist plugin should be accessing the product's values and they're correct. Probably, the cache plugin maintains the entire product's page in a custom cache or archives, and it regenerates them when the product is saved from its edit page. Again, we can't know how each cache plugin works to remove its cache data.

Best Regards,
José Andrés