What matters first: The installer refuses to overwrite an existing plugin or theme folder during a fresh install. The folder may contain a partial failed upload, a manually copied version or an active component with missing database state.
What this symptom actually tells you
Blindly deleting the directory can remove a live plugin and its only rollback copy. Compare the folder, installed component list and package slug first.
Capture evidence before changing anything
- Record the target directory named by the installer.
- Check whether WordPress lists the plugin or theme as installed or active.
- Compare the existing files and version header with the intended package.
- Review the previous failed install or deployment timestamp.
Most common causes
- Interrupted installation: A partial folder remains after timeout, disk or extraction failure.
- Manual file deployment: The code exists but WordPress did not complete the normal install flow.
- Slug collision: A different package uses the same directory name.
- Incomplete removal: The plugin was deleted in the dashboard but files or permissions prevented cleanup.
Safe diagnostic and repair sequence
- Back up the existing directory and database before replacement.
- If it is a known partial copy, remove or rename only that folder and install the trusted package.
- If it is active, use a controlled update or file replacement rather than a fresh install.
- Verify ownership so future dashboard updates can replace the folder normally.
How to choose between the likely causes
Do not treat Interrupted installation and Manual file deployment as interchangeable. A partial folder remains after timeout, disk or extraction failure. By contrast, the code exists but WordPress did not complete the normal install flow. Use two checks to separate them: Record the target directory named by the installer; and check whether WordPress lists the plugin or theme as installed or active. Those observations usually show whether the next safe move is to back up the existing directory and database before replacement or to preserve the current state and widen the investigation.
On a production WordPress site, repeat the failing request while checking a known-good page and the admin area. A fault isolated to one route calls for a narrower rollback than a failure affecting PHP, the database or every request. Record the exact timestamp, affected URL or transaction, last known good state and every change made during diagnosis. That handover is often what separates a repeatable repair from a temporary disappearance of the symptom.
What not to do
Do not delete a plugin folder when you do not know whether it contains custom changes or the only copy of paid software.
How to verify the repair
- The intended package installs with the correct version and files.
- Required settings and data remain intact.
- A future controlled update completes without leaving another partial folder.
A visible symptom disappearing is not enough. Close the incident only when the original failing action, the surrounding business journey and the relevant logs all agree that the fault is gone.
WP REPAIR INCIDENT STANDARD
Safe intervention sequence
Blindly deleting the directory can remove a live plugin and its only rollback copy. Compare the folder, installed component list and package slug first.
- Record the target directory named by the installer.
- Check whether WordPress lists the plugin or theme as installed or active.
- Compare the existing files and version header with the intended package.
- Review the previous failed install or deployment timestamp.
What must be verified
- The intended package installs with the correct version and files.
- Required settings and data remain intact.
- A future controlled update completes without leaving another partial folder.
Official technical sources
This guide explains the diagnosis. If the site is affected now, the intervention should preserve a rollback path and verify the real business journey.
See the emergency repair service →ABOUT THIS SYMPTOM
Frequently asked questions about this guide.
Is it safe to just delete the existing folder and reinstall?+
Not without checking first. The folder may be the only copy of an active plugin or a paid theme with no other backup, so deleting it blindly can destroy data instead of fixing the install. Always confirm whether WordPress lists the component as installed or active before removing anything.
What usually causes this error after a failed update rather than a fresh install?+
An interrupted installation is the most common cause: a timeout, disk issue, or extraction failure leaves a partial folder behind that the installer refuses to overwrite. This is different from a slug collision, where a completely different package happens to share the same directory name.
If I already deleted the plugin from the dashboard, why does the folder still block installation?+
Deleting a plugin in wp-admin does not always fully remove its files if permissions or leftover locks prevented cleanup. In that case the directory still exists on disk even though WordPress no longer lists it as installed, and the installer sees a conflict.
What's the safer alternative to a fresh install when the existing folder is the active plugin?+
Use a controlled update or direct file replacement instead of trying to force a new install over it. A fresh-install flow expects an empty destination, while an update flow is designed to replace files on top of an existing, active component.