Matt Lowe

@pierrelannoy Yeah I’d come to the same conclusion. I did use the Redis cache for a little while but after a catastrophic data corruption incident on a customer database I switched away from it again. We’ve never seen any issues like that with the APCu Manager plugin, so it’s our preferred object cache plugin. But when we were using the Redis Cache plugin I don’t remember WooCommerce database upgrades being any smoother, and as you say WooCommerce really should really be flushing the cache after upgrading the database. That’s clearly solely their responsibility.

The problem is trying to get WooCommerce to listen to anyone other than their core developers!

Thanks for the reply, I’m marking this as resolved.

The point is that WooCommerce needs to clear the object cache as part of its DB update process.

To everyone having this issue, if you have an object cache plugin installed (as per WordPress guidelines) such as “APCu Manager” or “Redis”, try disabling the plugin for the object cache to see if that fixes your issue.

Hey, I’m reopening this thread because I had the exact same issue again today. However I now know the cause: APCu Manager. It looks like WooCommerce isn’t clearing the object cache as part of its upgrade. When I disable APCu Manager everything works as expected, I can then re-enable the plugin and everything is fine.

More information here

It’s a security plugin. Its job is to enhance a site’s overall security. If it’s not doing that correctly then it’s not doing its one and only job. If it’s not getting this right then what else is it not getting right?

Same issue here.

“An important update is required for WooCommerce

“An important security update for WooCommerce has been released. It is recommended that you update as quickly as possible.”

Except I HAVE updated to the latest version.

Another day, another bug in WooCommerce. I note there are 3,100+ open issues against the GitHub repo. I’m at the point where I can no longer in good conscience recommend WooCommerce to my customers: It’s too slow, too resource hungry, and too buggy.

Also, mysteriously, I’ve just visited the customer’s website to see if I could maybe anonymise the SSR as an alternative and, would you believe it, while I was away:

“WooCommerce database update complete. Thank you for updating to the latest version!”

I have to wonder whether a cron event executed in the meantime that fixed whatever was preventing it from completing.

There’s probably little mileage in keeping this ticket open at this point as we can only speculate, so I’ve marked it as resolved. I’ll wait to see if the PR mentioned earlier resolves this issue (assuming it’s going into the next release?) when I next update this particular site.

Thanks for your help @anastas10s and @doublezed2.

Hi @doublezed2,

Thanks for getting back to me. I can’t share the SSR in any kind of a public forum as this is a customer website. If you can provide an email address I can forward it to I can share the system status report that way, but not within any kind of a public setting. ‘Quick Forget’ isn’t a good solution as it can still be accessed publicly, even if not for long or only for a specific number of requests —?I cannot guarantee the data only goes to the person it should go to and so I cannot trust such a solution. I hope you can understand that my customers’ security and privacy always has to come above all other considerations.

Having said all that I’ve just found that the update nag doesn’t seem to be appearing outside of the WordPress dashboard and the WooCommerce settings pages, so maybe it is part of the GitHub issue you linked to…

Hey @anastas10s,

Thanks for the reply but I don’t think the two things are linked. I have also seen that issue where the update buttons don’t work (which is a secondary source of frustration that I decided not to pollute my question with).

Here, when I click the button, it does initialize the database update with the 3 actions I mentioned appearing in the action scheduler. But despite those actions being executed over and over and over WooCommerce still nags for a database update. I’ve run the update easily 50 times and it’s still prompting to update. I ended up leaving this running on the command line:

while [ 1 ] ; do wp action-scheduler run ; wp wc update ; sleep 1 ; done

and it produces this output over and over and over:

Found 7 scheduled tasks
Started processing action 149724
Completed processing action 149724 with hook: woocommerce_run_update_callback
Running 7 actions  14 % [==========================>                                                                                                                                                                ] 0:00 / 0:00Started processing action 149728
Completed processing action 149728 with hook: woocommerce_run_update_callback
Started processing action 149725
Completed processing action 149725 with hook: woocommerce_run_update_callback
Started processing action 149729
Completed processing action 149729 with hook: woocommerce_run_update_callback
Started processing action 149726
Completed processing action 149726 with hook: woocommerce_run_update_callback
Started processing action 149730
Completed processing action 149730 with hook: woocommerce_run_update_callback
Started processing action 149727
Completed processing action 149727 with hook: woocommerce_update_db_to_current_version
Running 7 actions  100% [===========================================================================================================================================================================================] 0:00 / 0:00
1 batch executed.
Success: 7 scheduled tasks completed.
Success: No updates required. Database version is 8.9.1

When I visit the Scheduled Actions tab in WooCommerce I see those same 3 tasks that I previously mentioned being generated over and over. These two screenshots were taken roughly 30 seconds apart and look almost identical:

Screenshot 1

Screenshot 2

Notice how the scheduled times have moved on but they are the exact same set of neverending tasks. The script I mentioned before has been running for an hour with no change in this behaviour.

Conflicting with WooCommerce PayPal Payments plugin. APCu Manager isn’t critical to the running of the website in question, but PayPal Payments is, so I’ll leave it as an exercise to the reader to determine which plugin has been removed.

Additional to the above, the author of the APCu Manager plugin has some more details here:

https://www.ads-software.com/support/topic/whats-the-hell-happening-with-the-3-8-x-update/

I followed his instructions and fully removed the plugin then reinstalled it from the directory and, sure enough, the issue seems to be resolved.

Edit: sorry, no. Reinstalling it resets its settings, which means it’s installed but inactive until you flip a setting. Flipping that setting causes the issue to reappear. My advice is to remove APCu Manager and seek an alternative.

• This reply was modified 6 months, 2 weeks ago by Matt Lowe.

Really not helpful to announce you fixed the problem yourself without saying what the root cause was!

I’ve just tracked this down on one of the sites I manage to a conflict with the APCu Manager plugin: with it activated I cannot run WooCommerce PayPal Payments without it triggering a fatal error. With APCu Manager plugin deactivated I can enable it just fine.

I have to say I’m confused too, as aPCU isn’t supported in PHP8 (although I believe you can still build it if you’re prepared to go to the source and compile from there).

Thanks @fresco, we strive to help! And thanks again for reporting the issue.