Fixing the Destination Folder Already Exists Error
The installer refused because a directory with that name is already there, usually left by an install that failed partway. The folder is the evidence, and deleting the wrong one removes a working plugin.
The installer is refusing to overwrite something, and it is right to refuse. "Destination folder already exists" means a directory with the name the package wants is already present. Almost always it is debris from an install that failed partway through — but occasionally it is a working plugin, and the difference decides whether deleting it is a cleanup or an outage.
Read the path in the message
The error names the full path it objected to:
Destination folder already exists. /home/site/public_html/wp-content/plugins/example-plugin/
Two things come from that line. The name after plugins/ or themes/ identifies what is in the way, and the location confirms you are looking at the right install — which matters on a server hosting several sites.
Decide what the folder is before touching it
Open the Plugins screen and look for the plugin by name:
| State on the Plugins screen | What the folder is | Action |
|---|---|---|
| Listed and active | A working install | Do not delete; update instead |
| Listed and inactive | A complete install | Delete through the dashboard |
| Not listed at all | Debris from a failed install | Safe to remove |
A folder that does not appear on the Plugins screen has no readable plugin header, which is what a half-extracted directory looks like. That is the common case and the safe one.
For themes, the equivalent check is the Themes screen, with one extra caution: never delete the directory of the active theme, and never delete a parent theme while a child theme depends on it.
Removing the leftover
Over SFTP or the host's file manager, delete the directory the error named. Then retry the install.
While you are in wp-content, check for two other leftovers from failed installs: an upgrade directory containing partially extracted packages, and an upgrade-temp-backup directory holding copies from an interrupted update. Both are working space rather than site content, and both can be emptied when nothing is installing.
The version without FTP
If the package is the same plugin you are trying to install, download the zip and use the upload route in the dashboard. WordPress recognises that the plugin already exists and offers to replace it, showing both versions before you confirm.
That path resolves the conflict without file access, and it is the practical answer on hosting where SFTP is awkward. It does not help when the leftover is a broken directory with no readable header, because there is nothing for WordPress to compare against.
Fix the reason, not just the folder
The refusal is a consequence. Something stopped the first install from completing, and if it is still true the next one fails the same way:
- Write permissions. If the web server cannot write reliably to
wp-content, installs fail partway. That diagnosis belongs to the FS_METHOD constant, and the repair is file ownership rather than a constant. - A timeout. A large package on a slow connection can exceed the PHP execution limit mid-extraction, leaving exactly this state. The symptom is that big plugins fail and small ones succeed.
- Disk space. A full disk produces a partial extraction and a confusing error afterwards. Worth ruling out in one command before anything else.
- An interrupted update. Closing the tab during an update leaves the same debris and can also leave the site in stuck maintenance mode.
If installs fail repeatedly at the same point, the cause is one of these, and clearing the folder each time is treating the symptom.
Verify the install is complete
After a successful retry, activate the plugin and load a front-end page and an admin page. A directory that extracted incompletely can still activate and then fail when a missing file is finally required, which surfaces as a white screen rather than an install error.
If the site breaks after activation, deactivate by renaming the plugin directory over SFTP — the plugin stops loading immediately and the dashboard comes back — and reinstall from a fresh download. A package that failed once may itself be truncated, and reusing the same file reproduces the fault.
Frequently asked
- Yes, when it is a leftover from a failed install and the plugin is not active. Check the plugins screen first: if the plugin is listed and active, deleting its directory removes a working install rather than debris.
- Usually a write permission problem or a timeout partway through unpacking. The error you are seeing now is the consequence, so fixing only the folder leaves the original cause in place.
- Uploading the same plugin as a zip offers to replace the existing copy, which resolves the conflict from inside the dashboard when the leftover is genuinely the same plugin.