When I try and update plugins locally through the admin panel I get the following error for each plugin:
An error occured while updating [plugin name]: Could not remove the old plugin.
Then if I refresh or leave this page, I get alerts saying:
The plugin [plugin-name] has been deactivated due to an error: Plugin file does not exist.
This is leading me to believe that when I attempt to update a plugin, it removes the plugin files but doesn’t replace them with the new ones. This is causing a lot of problems.
This only appears to happen if I use Local by Flywheel - I haven’t seen this issue before I started using it.
I’ve looked around Community and noticed this is a common issue. So please let me know if there is an answer out there that I haven’t found. I keep spotting disabling “Faster Docker Volumes” however because sites tend to run slow on my machine I would prefer to keep this checked!
WP Version: 4.8
PHP Version: 5.6.20
Web Server: nginx
MySQL Version: 5.6.36
Thanks in advance!
This is unfortunately a bug with NFS on macOS Sierra.
We have a workaround in place that’s ran whenever you [re]start the site but it’s not a permanent fix.
In the meantime, you can disable macOS Sierra’s gatekeeper functionality but this can pose a potential security risk. If you’re willing, here’s how:
- Open Terminal
sudo spctl --master-disable
To re-enable it, simply run
sudo spctl --master-enable
Even with gatekeeper disabled, deleting or installing a plugin makes my CPU fans spin like crazy and installing a plugin fails… The previous version was not like this at all.
This did appear to work for me at first - or so I thought. But after some days, the error is still happening for me.
I have to keep re-downloading the plugins manually and adding them into the folder. And I can’t run updates through Local by Flywheel without this occurring.
Please fix It seems to be a common problem with many users
Disabling macOS gatekeeper seems to work temporarily but not even until the next restart. I’m having to redo this command every day or so or even multiple times a day.
For whatever reason, disabling gatekeeper in relation to this issue with LOCAL doesn’t stick.
What’s more if gatekeeper is not disabled, when updating/removing plugins WP sometimes doesn’t complete the process and only removes/updates a portion of the plugin files. If the main plugin file has been removed then you get a ‘plugin does not exist’ message and you have to replace the plugin manually.
Hopefully this will be fixed soon.
Is there any update on this getting fixed soon? It’s pretty annoying to manually update plugins, especially premium ones that require me to login to the vendor site instead of simply downloading it from WP.org. Working on 2-4 sites at a time, it’s not uncommon for me to update multiple plugins every day.
Is there some sort of diagnostics data you need from us to find a solution?
Experiencing this error with 2.06 “failed to update plugin”. Disabling fast docker seems to work but sacrificed speed. Would appreciate a real fix.
Bumping this. This needs to be fixed asap - maintaining LOCAL sites is becoming untenable. The ‘workaround’ no longer works reliably.
Can we please get an update?
Turning off Faster Docker Volumes worked for me. Thanks Clay!
Same problem here. Getting the “Update Failed: Could not remove the old plugin” error all the time. When I recover the corrupted files and try to update again, it just works. I’m getting pretty tired of this to be honest, since this problem is so random.
The “Update failed” problem is slowly becoming really, really annoying and frustrating.
Having to turn off faster docker volumes each and every time I want to upgrade anything in a Local site, which unsurprisingly is rather often, or forget about it and then having to go get the Plugin (and/or Theme) files manually, unzipping and copying them into the sub-sub-sub-sub-sub-directory Sites > mysite > app > public > wp-content > plugins, is making me feel using Local is not much of a timesaver anymore.
Still borked in Local 2.0.10, BTW.
Oh, and: if one remembers turning Faster docker off, also remember to wait at least ~30 seconds before attempting anyting, unless one really likes to look at
I’m having an issue too Local 2.0.8 mac. Should I update to 2.1?
Tried updating, but it stilld didn’t work. I turned faster docker off. All the plugins that I tried to update have disappeared and when I try to reupload i get a message that it already exists.
Hey guys, I’m also still having this plugin update issues. Any update on when it will be fixed???
I’m running the latest ver 2.1.1 for Mac OSX.
I’ve tried all the permissions & ownerships suggestion, to no avail.
Have had to turn off Fast docker volumes, to update the plugins. Then turn it back on afterwards, to actually do any work!
Look forward to an update
I have Local by Flywheel v2.1.1 installed on Mac OS High Sierra v10.13.1. Created a new site and tried to install my first plug-in Akismet.
The spinner on Installing button spins for a long time and after a while I get a message that “Install failed”. I went in to Prefferences/Advanced and turned Faster Docker Volumes off. Stopped the site, quit Flywheel, started it again and then started the site. Same thing. Still can’t install any plug-ins.
It seems that people have been reporting this issue since June. Makes me wonder if Local by Flywheel is a viable option given how long it has been taking to address an issue that appears to be affecting so many people. maybe it is just me being on all the latest things that is causing the problem?
I’m confident this particular bug will finally be squashed in the not-too-distant future.
Just installed a fresh copy of Flywheel 2.1.1 on Windows 7 - I can install fresh plugins okay, but updates fail with “Update Failed: Could not create directory.” Bummed - this is my third time trying to get Flywheel to work (earlier attempts had this issue + speed, 2.0.x and a beta version of 2.1x). I was so hoping that 2.1.1 would work straight out of the box! Back to Xampp…
Is there any update regarding this? I’m unable to update any plugins (i’ve never even turned on faster docker volumes).