ispjstfu

Thanks for replying with an update @tobija . Since I am trying to approach this very “computer-logically” I am thinking that there must be something specific triggering this, and I wasn’t sure it was related to traffic at all but to specific actions that may be happening in the the database, through a cron job or something else, but it is really hard to find a pattern and as you say, reproduce it.

Curious though, does this happen only on live installs or has anyone seen this in a dev or stage env without any visitors, if just left alone but with the exact same setup as a live “broken” build? See, my current theory is that it could be a WordPress hook or some specific thing triggering this that is used by many different plugins, which is why there is no consistency in how this happens for different people and so hard to pin down. Need to start going through WP developer docs.

• This reply was modified 7 months, 1 week ago by ispjstfu.
• This reply was modified 7 months, 1 week ago by ispjstfu.
• This reply was modified 7 months, 1 week ago by ispjstfu.

Sorry, I just wanted an update from the people who have talked about it here since I won’t be able to tag them in a new topic. It is too much work going over it all again so we’ll just leave it and continue on updating the affected products I guess.

Thanks

• This reply was modified 7 months, 1 week ago by ispjstfu.

I’d love some updates on this as I have a client with the same issue, however using Elementor. In our case though the “Add to cart”-button simply and randomly disappears, and there is no “Out of stock message” like there normally is. The variations array is empty though.

The common denominator that lead me here though is that updating the product without any changes fixes the issue. It is not consistent among products and we have not been able to recreate it manually.

Since this is a big shop with hundreds of products and it’s happening on a live site, I wrote a Python script that checks all product pages HTML for the “Add to cart”-button element and reports back the URL:s where it’s missing, so we can find and update the products daily, but of course it’s a hassle. I tried automating it by having the script run every 5 minutes for a day or so, and was able to catch a window of when it happened with a five minute interval twice, but what’s really strange is that these were not products that had been bought recently or within the time frame. The variants are simply not loading.

The reason for the Python script was I wanted to use this time frame to check access logs and possibly database logs, but since this build is on shared hosting our hosting provider is saying we can’t have logging turned on for more than a few minutes because it would take up too much resources. I guess that kind of logging on their end is server-wide so it’s logging for all or no one, in which case it makes sense they can’t have it on by default or for a longer period of time.

The only common thing I have found in this very interesting thread so far is that my client is also using WooCommerce Wholesale Prices. Did you get anywhere with those tests @tobija ?

One thing I am investigating is WP Cron and cron jobs in general because for us the two times I have been able to catch it happening has been on Mondays around lunch, but using WP Crontrol I have not been able to identify anything that seems related to that so it might just be a coincidence so far, and there are no cron jobs set up at the server level either.

Thanks!

• This reply was modified 7 months, 1 week ago by ispjstfu.
• This reply was modified 7 months, 1 week ago by ispjstfu.

A temporary solution for me right now is using an older version of the plugin where this is not an issue. It doesn’t look as good, but with some custom CSS it is manageable.

I am having this exact same issue… Please help!