The WordPress message “Could not remove the old plugin.” means the updater failed to delete the existing plugin files before installing the replacement. The quickest safe fix is to back up the site, identify the exact plugin folder named in the error, remove only that folder through your host’s file manager or SFTP/FTP, and then reinstall the plugin. If deletion is denied, the problem is usually ownership, permissions, the configured filesystem method, or an unusual path such as a symlink—not a problem with posts or pages.
Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.
What the error means
This is a filesystem failure in WordPress’s plugin upgrade process. WordPress core displays the exact sentence “Could not remove the old plugin.” in the Plugin_Upgrader class (WordPress core source). The class handles plugin installation and upgrades, including a delete_old_plugin method documented in the WordPress Developer Reference.
As an Amazon Associate I earn from qualifying purchases.
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →During an update, WordPress checks whether the old destination exists. If the plugin path contains a directory separator, it attempts to remove that directory recursively; otherwise it attempts to remove the plugin file. A failed filesystem deletion produces the remove_old_failed error. The historical core update sequence confirms that WordPress removes the old destination before copying the replacement into place (WordPress Trac changeset 11005).
Because the old copy cannot be removed, WordPress stops the update rather than silently overwriting an uncertain installation. The error therefore identifies a failed deletion step, not a general content, theme, or database error.
Why WordPress cannot delete the plugin
Ownership or permissions do not allow deletion
The web server account, WordPress’s configured filesystem method, or your SFTP/FTP account may not have permission to remove the directory. A folder can appear in the dashboard and still be owned by a different system user—for example, after a manual upload, a migration, a restore, or a host-side security process. Read access is not enough; the account performing the update must be able to delete every relevant file and the containing directory.
Do not recursively change permissions across the entire site as a first response. Hosting providers use different user, group, and isolation models. Ask the host to correct ownership and provide a writable SFTP account if you cannot establish which account should own the files.
The path is a symlink or another non-standard filesystem object
A normal plugin installation is a directory containing plugin files. A symbolic link points somewhere else, and recursive deletion can behave differently from deleting a normal directory. WordPress Trac documents a symlink edge case in which removing a symlinked plugin path can trigger dashboard failures (Trac ticket 15134).
If the failing path is a link, confirm where it points before deleting anything. Never assume that removing the visible entry will remove only files inside wp-content/plugins/; the target may be outside the WordPress installation or shared with another deployment.
The folder is missing or only partly installed
An interrupted update, manual deletion, failed deployment, or restore can leave WordPress with an inconsistent install state. The dashboard may retain an entry for a plugin whose directory is missing, or it may show a directory containing only part of the expected files. In that state, a retry may continue to fail because WordPress is trying to remove a destination that is not a normal, complete plugin directory.
The configured filesystem method cannot perform the operation
WordPress can use the server’s direct filesystem access or another configured method. If that method cannot write to the plugins directory, the updater cannot complete the removal even when the site itself loads normally. This is a server-access issue; repeatedly clicking Update does not grant the missing capability.
Rank #3
Safe recovery: remove and reinstall one plugin
Follow these steps in order. Stop if the path shown in the dashboard does not match the folder you find on the server.
- Record the exact plugin path. Copy the plugin name and, if shown, its slug or folder path from the update error. Similar names can belong to different plugins, so do not rely on a shortened display name.
- Create a current backup. Keep a restorable copy of the database and WordPress files before deleting anything. A backup gives you a recovery point if the wrong directory is selected or the plugin stores required configuration in files.
- Deactivate the plugin when possible. If WordPress still lists it as active and the site remains accessible, deactivate it from Plugins → Installed Plugins. If the dashboard is unavailable or the plugin is already inactive, continue with the file-based steps; do not repeatedly load a broken admin page.
- Open a server-side file tool. Use your hosting control panel’s file manager or connect with SFTP/FTP. Navigate to
wp-content/plugins/. - Match the folder exactly. Compare the folder name with the slug/path from the error. Check that it is the affected plugin and not the parent
pluginsdirectory, another plugin with a similar name, or a symlink whose target you have not verified. - Remove only the affected plugin folder. Delete that one directory and its contents. Never delete the entire
wp-content/plugins/directory, WordPress core folders, or an unverified symlink target. - Load the site and test the fatal-error condition. Open the front end and, if available, the dashboard. Confirm that the error caused by the damaged plugin is gone before installing a replacement.
- Reinstall from a trusted package. Install the plugin again from WordPress.org or the plugin developer’s trusted distribution. Use the current package appropriate for your WordPress and PHP environment.
- Activate and test the feature. Activate the newly installed copy only after the files are present. Test the feature the plugin provides, check key pages, and review the site for new warnings before considering the repair complete.
A WordPress support case for this specific message recommends deleting the affected folder through FTP and reinstalling when the plugin file is missing (WordPress support discussion). That is practical guidance for this recovery pattern, not a guarantee that every host uses the same permissions or filesystem setup.
Choose the safest removal method
| Method | Required access | Risk of selecting the wrong path | Auditability and backup options | Can it fix ownership or permission problems? |
|---|---|---|---|---|
| Dashboard retry | Working WordPress administrator access and a filesystem method that can write to the directory | Low path-selection risk, because WordPress chooses the plugin; repeated retries do not solve a denied delete | Usually limited to whatever backups and update logs your site already keeps | No; it depends on the existing server account and permissions |
| Hosting file manager | Control-panel login with access to the WordPress files | Moderate; you can see the directory but can still delete the wrong folder | Often includes trash, timestamps, or host snapshots; verify what your host provides before deleting | Sometimes; a host administrator can correct ownership, but a normal account may not |
| SFTP/FTP | Credentials for an account that can access wp-content/plugins/ |
Moderate; the remote path must be checked carefully before deletion | Good visibility of names and timestamps; make a backup before the transfer or deletion | Usually no; if deletion is denied, the host must change ownership or permissions or issue a suitable account |
| Host-assisted removal | A support request and proof that you control the site | Lowest when you provide the exact path and ask for one-folder removal | Best chance of a host snapshot or support record; ask what was changed | Yes; the host can repair ownership, permissions, quota, or server-side filesystem issues within its security model |
Use the dashboard only when the underlying filesystem access is healthy. Prefer a file manager or SFTP/FTP when the dashboard cannot remove the old copy. Choose host-assisted removal when you cannot verify the path, lack file access, or encounter a permissions error.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Troubleshoot the failure by symptom
“Permission denied,” “operation not permitted,” or an undeletable folder
- Stop trying broad permission changes. Record the exact path and the account that received the error.
- Ask the host to confirm which system user owns the plugin files and which user the web server or PHP process uses.
- Request correction of ownership and the minimum permissions needed for WordPress updates, or request a writable SFTP account.
- Retry the update only after the host confirms the change. Keep the rest of the site untouched.
SFTP or FTP will not connect
Use the host’s file manager if it provides one. If neither tool is available, ask the host to remove the single, verified plugin directory. Do not guess at credentials, switch protocols repeatedly, or delete files through an unrelated deployment account.
A symlink appears in the plugins directory
- Inspect the link target and determine whether it is intentional, such as a deployment or shared-code setup.
- Do not recursively delete the target until you know what else uses it.
- Ask the deployment owner or host to replace the link with a normal plugin directory or perform a controlled update.
The documented Trac case explains why recursive deletion of a symlinked plugin path is risky (WordPress Trac ticket 15134).
The plugin folder is already gone
Confirm that the folder name in the error exactly matches what is (or is not) under wp-content/plugins/. If it is absent, refresh the Plugins screen and check whether WordPress still lists the plugin. Reinstall the plugin from a trusted package only after confirming that no similarly named directory remains and that the site loads without the old plugin.
The folder exists but is only partly present
Do not copy new files over an uncertain partial installation. Back up first, remove only the affected directory, then install a complete package. If deletion itself fails, treat it as an ownership, permission, filesystem-method, or symlink issue rather than trying to repair individual files in place.
The update still fails after the folder is removed
At that point, the original deletion error may no longer be the blocking condition. Check the site’s available disk quota, filesystem health, security tooling that may block writes, and the host’s PHP and web-server error logs. These checks require access to your particular hosting account; the WordPress error alone cannot identify which one is responsible. Ask the host to review the failed update time and the exact path if you cannot access those logs.
What happens to plugin settings and database data?
Deleting the plugin’s files is not the same as proving that its database tables, options, uploads, or scheduled tasks were removed. The safe recovery sequence above restores the executable files; it does not promise a clean data uninstall. Before deleting data, read the plugin’s uninstall documentation and identify whether it provides a separate “remove data” option. Preserve the backup until the replacement is installed and the site’s required settings and features have been verified.
Prevent the error from returning
- Keep a current backup before plugin updates, especially on a production site.
- Use one consistent deployment method. Mixing manual uploads, control-panel restores, and automatic updates can leave files owned by different accounts.
- Keep the plugin directory on a filesystem account that the update method is allowed to modify; ask the host how its PHP and SFTP users are mapped.
- Document intentional symlinks and deployment targets so a future update does not treat a link as an ordinary plugin directory.
- Monitor disk quota and host security rules that can block file writes, and retain the timestamp and path whenever an update fails.
- After a reinstall, test the plugin’s actual feature and the front end rather than relying only on a successful activation message.
When to stop and contact the host
Contact hosting support instead of experimenting when you cannot verify the correct folder, the directory is a symlink, deletion returns a permissions error, the site is in a managed deployment, or the dashboard and file tools show contradictory states. Provide the exact plugin slug/path, the time of the failed update, the error text, and confirmation that you have a backup. Ask support to remove only that directory or explain why it cannot be removed, then request the ownership or filesystem correction needed for future updates.
Quick Recap
Quick checklist
- Copy the exact plugin slug or path from the error.
- Back up the database and files.
- Deactivate the plugin if the dashboard is usable.
- Open the host file manager or SFTP/FTP and go to
wp-content/plugins/. - Verify the directory name and check for a symlink.
- Delete only the affected plugin folder.
- Load the site and confirm the fatal error is gone.
- Reinstall from a trusted package, activate, and test.
- If deletion is denied or the update still fails, have the host inspect ownership, permissions, quota, security tooling, and logs.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
