We are having the same problem. A very slow response by the author to this difficulty which should be an easy fix. I wonder if we have to search for another plug-in solution.
As I think it through Frank, WP likes updates to happen quickly and invisibly as a background task. For WC this isn’t the right approach as it is big with many inter-dependencies. In addition, when you have a beefy VPS with lots of resources that have spawned many workers, it is likely very important for a WC update to initially quiet the system. That may very be what happens when we disable the other plug-ins as part of our methodology.
We could do a better job of making our staging site a more complete mimic to the live sites. But obviously it doesn’t have the asynchronous elements that a live site has through noisy plug-ins like payment, shipping, CDNs, etc.
I will stop now as I think we have a methodology which we can use for WC updates.
we were successful in doing the update on our staging site but the update failed on the live site when doing the WC delete (through FTP ) and re-install. There are however several plug-ins on the live site that aren’t active on the staging site – i.e. those that require subscriptions or keys. So my thinking now is that we ran into these problems as certain plug-ins were active doing the WC update. By disabling them and going into maintenance mode the site is as quiet as possible so the update can proceed to plan. That is speculation but there is a lot going on in WC sites. Perhaps the WordPress update process needs some improvements but I don’t know all of the intricacies of this process. Clearly WC is a big plug-in at this point and when you add in the others needed to develop a viable shopping site, there is a lot going on.
Hello – an update. We were finally able to get our 2 live sites (one English, one French) up to WC 10.5.2 from 10.4.3. It would appear that you have to be very careful when doing these updates and the only way we could get this to work was:
Do a full back-up just in case.
Set site in maintenance mode.
Disable all plug-ins except WC.
Update WC.
Restore plug-ins.
Carefully review error log just to be 100% sure things went to plan.
Go live and test.
This has been rather difficult. This methodology worked even when the more painful method of deleting WC and doing a fresh install failed. I am very puzzled by this observation but we are live now on 10.5.2 so we are happy to reach that milestone.
This has become a very difficult situation for many WooCommerce sites. I could not get the 10.4.3 to 10.5.0 to succeed and hoped that 10.4.3 to 10.5.1 would resolve the problem. Not really. I did finally get an update to succeed on our staging site but it was torture. Took about 30 minutes. Had to ensure the staging site was in maintenance mode (through a plug-in), did a complete back-up, disabled all plug-ins except for WooCommerce. Then took a deep breath and disabled WooCommerce. It finally disabled properly (before I had the white screen of death for some reason). I then deleted the WooCommerce folder, and manually ftp’d the new version into place. I could then re-enable WooCommerce and then the rest of the plug-ins and finally go back live (as a test) without encountering the error message. I am pretty nervous about doing this on the 2 live sites but will do so early morning. Going to take back-ups for sure as it can go terribly wrong! A real shame as WooCommerce is amazing but these upgrade problems are debilitating.
[Wed Feb 11 08:06:38.667144 2026] [proxy_fcgi:error] [pid 2384124:tid 2384291] [remote 104.159.87.202:0] AH01071: Got error ‘PHP message: PHP Warning: require_once(/home/basicsby/domains/basicsbymail.com/public_html/testsite/wp-content/plugins/woocommerce/vendor/wordpress/abilities-api/includes/rest-api/endpoints/class-wp-rest-abilities-run-controller.php): Failed to open stream: No such file or directory in /home/basicsby/domains/basicsbymail.com/public_html/testsite/wp-content/plugins/woocommerce/vendor/wordpress/abilities-api/includes/rest-api/class-wp-rest-abilities-init.php on line 25; PHP message: PHP Fatal error: Uncaught Error: Failed opening required ‘/home/basicsby/domains/basicsbymail.com/public_html/testsite/wp-content/plugins/woocommerce/vendor/wordpress/abilities-api/includes/rest-api/endpoints/class-wp-rest-abilities-run-controller.php’ (include_path=’.:/usr/local/php84/lib/php’) in /home/basicsby/domains/basicsbymail.com/public_html/testsite/wp-content/plugins/woocommerce/vendor/wordpress/abilities-api/includes/rest-api/class-wp-rest-abilities-init.php:25\nStack trace:\n#0 /home/basicsby/domains/basicsbymail.com/public_html/testsite/wp-includes/class-wp-hook.php(341): WP_REST_Abilities_Init::register_routes()\n#1 /home/basicsby/domains/basicsbymail.com/public_html/testsite/wp-includes/class-wp-hook.php(365): WP_Hook->apply_filters()\n#2 /home/basicsby/domains/basicsbymail.com/public_html/testsite/wp-includes/plugin.php(522): WP_Hook->do_action()\n#3 /home/basicsby/domains/basicsbymail.com/public_html/testsite/wp-includes/rest-api.php(636): do_action()\n#4 /home/basicsby/do…’, referer: https://testsite.basicsbymail.com/wp-admin/update-core.php?action=do-plugin-upgrade
Carefully checked Cloudflare and we didn’t see an attack at this time. But the VPS stopped dead on the WooCommerce live sites but not the non-WooCommerce/Wordpress sites which were fine. Cloudflare analytics – live sites – the staging site isn’t on Cloudflare:
It is a bit hard to say what actions generated a recovery. I think perhaps the restart on Apache and PHP as there were a ton of workers busy at that time. I will take a look at the memory use at the time to see if there are any clues.
Next, I will do an update manually on the test site, i.e. by disabling WooCommerce, removing the folder and then adding in the new folder as you suggest. I will have to do it during a quiet moment as it would be painful to drive another mishap like the one that happened this morning.
I think the team hasn’t quite internalize this difficulty yet. The staging site is totally isolated with no traffic (it has a maintenance mode plug-in installed). The update failed this time (as before) with a white screen and no access to either the site or the control panel. And the VPS wilted under the load. When I have a moment, I will dig deeper into the logs to see what was going on. Something is seriously wrong with this update. I will try to help!
Right after doing the update, the server was overwhelmed and the live sites (on the same VPS) became unresponsive. Had to take dramatic countermeasures – nuking plugin WooCommerce from the site (through ftp) and phpMyAdmin. Then restarted Apache and PHP. Finally recovered the sites and did the roll-back. Now I can’t really say that the issues with the live sites was caused by the upgrade. There could have been something else a play. I checked Cloudflare and the other WordPress (non-Woocommerce) on the VPS and they were all fine. Something went very wrong!
I did the 10.5 update and it immediately spawned a fatal error. I had to revert to 10.4.3 and that was very difficult as the site went into a fully dysfunctional mode – no admin dashboard. Had to do a complete restore of the last image. Here is the error message from the log:
Hey – sorry. I posted the error on github so that this would be tracked there. I found that the only way I could avoid a fatal error on upgrade from 10.1.0 to 10.2.0 was to:
Set the site offline;
Disable the Stripe Gateway Plug-in;
Do the upgrade;
Re-activate the Stripe Gateway Plug-in; and
Go live again.
Does not take too much site but all 3 sites (2 live, 1 staging) were upgraded without encountering the fatal error.
I have checked this and can confirm that the file class-wc-stripe-connect-rest-oauth-init-controller.php does not exist in the official WooCommerce Stripe Gateway plugin repository.
Hence the include or require in wp-content/plugins/woocommerce-gateway-stripe/includes/class-wc-stripe.php:774 will spawn a fatal error. The fix is rather straightforward in that the repo image must contain this file. This is a tricky error as the update process will obviously stop but problem may not be immediately evident as the upgrade may not have completed properly. And the site will continue to work but may generate faults. I was notified by email that the fatal error occurred otherwise there is no other immediate symptom.
Hello Bryle. Thanks so much for responding. After my last post, I finally discovered the expert settings and selected delete local back up as you suggested. Oddly, this is the first time I have used expert settings so I’m unsure how the 2 sites (our of 5) were changed to not delete the backups. But all working perfectly now. And thanks again for this amazing plug-in.
I should add that I have left a cron job in place to execute wp-cron.php once a night on the 3 sites with modest traffic. Just to be on the safe side. Not hard to do and a good insurance policy.
The cron ran last night as expected but didn’t help. I then realized that the scheduled task was running properly as the back-up was created as planned. So I had a read of your log and the difficulty is now clear:
0000.999 (0) Prune old backups from local store: nothing to do, since the user disabled local deletion and we are using local backups
This would of course explain why these 2 sites don’t clear old back-up while the other do. So I searched all the tabs trying to find this setting but couldn’t. Any suggestions?
Thanks so much. This is a great plug-in. One of the best.
Interesting – the backups are still stacking up in the 2 problematic sites as if cron didn’t run. So I have installed a cron job to execute wp-cron.php at 2:30 am every day. Hopefully that will trigger the scheduled task to remove the old backups.
