On a customer’s website I have upgraded to WooCommerce 8.9.1. It showed the usual database update nag so I clicked through and it created 3 Action Scheduler tasks:
I tried manually running these which led to more and more tasks being created so I started running the updates from WP-CLI instead with
wp action-scheduler run
It did its updates and finished without incident. I return to the admin screen and the database upgrade nag is back, so I click through and it creates the exact same three actions as above. Again I run them from WP-CLI and return to the admin, the nag’s back, over and over and over. And yet,
wp-cli wc update
Success: No updates required. Database version is 8.9.1
Despite the neverending DB update nags. So…
What do I have to do to get WooCommerce to shut up about the database updates it claims it both does and doesn’t need to perform? And,
Why do we even have to click these nags in the first place? WooCommerce’s database management should be WooCommerce’s problem, not mine nor my customers’ concern.
I can share the system status report if required, but not in a public setting.
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.
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…
Could you share your site’s System Status Report? I understand this is a public platform and you are not comfortable with sharing SSR here. Therefore, I suggest using https://quickforget.com to share the SSR.
The issue you are facing likely is the same as previously suggested. I can review the SSR and investigate this further.
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.
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.
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.
Thank you so much for adding your input! Some of our customers might indeed find this guide helpful!
We appreciate you being an active part of the community 🙂
As I understand, the culprit is with a 3rd party plugin and a thread is already open at its support forum. Therefore, I’ll go ahead with marking this as resolved now.