iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.
The WordPress message “Could not remove the old plugin.” means WordPress failed to delete the existing plugin files during an update. The safest fix is to back up the site, identify the exact plugin folder named in the error, remove only that folder with your host’s file manager or SFTP/FTP, and then install a fresh copy. Do not delete the entire wp-content/plugins/ directory or an unverified symlink target.
What the error means
This is a filesystem failure in WordPress’s plugin upgrade process, not a problem with posts, pages, or other content. WordPress core defines the exact message “Could not remove the old plugin.” in the Plugin_Upgrader class (WordPress core source).
The upgrader’s delete_old_plugin method checks whether the old destination exists. When the path contains a directory separator, it attempts a recursive directory deletion; otherwise it attempts to delete the individual plugin file. If the filesystem delete operation returns false, WordPress reports the remove_old_failed error (Plugin_Upgrader reference).
In the historical update sequence, WordPress removes the existing destination before copying the replacement into place (WordPress changeset 11005). A failed deletion therefore stops the update before the new plugin can be installed cleanly.
Why WordPress cannot delete the old plugin
Ownership or permissions block the web server
The PHP process used by WordPress must be able to remove the plugin directory and its contents. If files were created by a different system user, restored from a backup with different ownership, or made read-only, the configured filesystem method may be unable to delete them. The dashboard can then download an update but fail at the replacement step.
The configured filesystem method cannot write
WordPress may use direct filesystem access or a host-configured method that requires credentials. A method that can read the directory but cannot write or delete it produces the same upgrade error. Your host can tell you which method is enabled and whether the account running PHP has write access.
PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteThe plugin path is a symlink
A symlink is not a normal plugin directory. Recursive deletion can behave unexpectedly when the path points elsewhere. WordPress Trac documents a symlink edge case in which recursive removal of a plugin path can lead to dashboard failures (Trac ticket 15134). Confirm where a link points before deleting anything, especially on a development or managed-host setup.
The installation is incomplete
An interrupted update, manual upload, or previous cleanup may leave a missing or partially present directory. WordPress can still retain the plugin’s entry in its installed-plugin list while the files on disk no longer match that state. The error may identify a path that exists only in part, or a path that has already disappeared.
Choose the safest removal method
| Method | Access required | Risk of deleting the wrong path | Auditability and backup options | Can fix ownership or permission problems? |
|---|---|---|---|---|
| Retry from the WordPress dashboard | Administrator access and a working filesystem method | Low if the error was temporary; no benefit if deletion is denied | Dashboard activity is visible, but it does not create a file backup | No |
| Host control-panel file manager | Hosting-panel access | Moderate; you can see the path, but a mistaken selection is still possible | Some hosts provide trash, rename, or archive features; make your own backup first | Sometimes, depending on the host’s permission controls |
| SFTP or FTP | A working SFTP/FTP account and client | Moderate; precise navigation helps prevent selecting another plugin | Local downloads provide a record and backup before deletion | Usually no; the host must correct ownership or server-side permissions |
| Host-assisted removal | A support request and enough information to identify the site and plugin | Low when the host confirms the exact path before acting | The host can record the change and preserve server-side backups according to its policy | Yes; the host can repair ownership, permissions, or filesystem issues |
Use the dashboard only for a quick retry after confirming the site is healthy. If it fails again, use the file manager or SFTP/FTP. If neither is available, ask the host to remove the exact directory and check its ownership.
Safe recovery procedure
1. Record the exact plugin path
Read the complete dashboard error and note the plugin name and slug. The slug is usually the directory name under wp-content/plugins/, but do not assume that a display name and folder name are identical. If the message shows a full path, preserve its spelling and capitalization.
2. Make a current backup
Create a backup of the database and site files before removing anything. At minimum, retain a copy of wp-content/ and any host-provided snapshot that can restore the site. A backup is especially important when the plugin stores uploaded files or custom configuration outside its own directory.
3. Deactivate the plugin when possible
If the dashboard still loads and the plugin is active, open Plugins, locate the affected plugin, and select Deactivate. Do this only if the site remains accessible without it. If a fatal error prevents the dashboard from loading, skip this step and proceed through the host file manager or SFTP/FTP.
4. Open the plugin directory
Use your hosting control panel’s file manager or connect with SFTP/FTP. Navigate to the WordPress installation’s wp-content/plugins/ directory. On a multisite network, verify that you are working in the correct site installation and not a staging copy or another document root.
5. Match the folder exactly
Compare the directory names on disk with the slug recorded in step 1. Check for similar names, renamed folders, and nested directories. If the reported item is a file rather than a directory, identify that exact file. Do not remove another plugin merely because its name looks similar.
Rank #3
6. Preserve a copy, then remove only the affected item
Download or archive the identified plugin directory if your host allows it. Then delete only that directory from wp-content/plugins/. Never delete the parent plugins directory, WordPress core directories, or a symlink target that you have not confirmed. If the item is a symlink, stop and verify its destination with the host before choosing a deletion command.
7. Check the site immediately
Load the front end and, if available, wp-admin. Confirm that the fatal error and the update notice are gone. Pages that depended on the plugin may lose a feature while its files are absent; that is expected until a compatible copy is installed.
8. Reinstall from a trusted package
Install the plugin again from the WordPress.org directory or the plugin developer’s trusted package. In the dashboard, use Plugins > Add New Plugin, search for the exact plugin, and choose Install Now. For a ZIP supplied by the developer, use Plugins > Add New Plugin > Upload Plugin, select the ZIP, install it, and activate it only after checking that the plugin is intended for your WordPress and PHP versions.
9. Test the feature that required the plugin
Check the plugin’s main settings, a representative page or workflow, and any connected service. Review the WordPress error log and the host’s PHP log if the feature now fails. Reinstallation restores files; it does not automatically prove that every previous setting, integration, or database table is intact.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Troubleshoot the removal itself
“Permission denied” or deletion fails in the file manager
Do not recursively change permissions across the whole site. Ask the host to verify the owner and group of the plugin directory and to provide a writable SFTP account or perform the removal. The correct ownership model differs between hosts, PHP handlers, containers, and security systems, so a broad permission change can create a larger vulnerability or break other updates.
SFTP or FTP will not connect
Use the host’s file manager if it is available. Otherwise send support the site’s domain, the exact plugin slug, and the full path shown by WordPress, and request removal of that one directory. Keep a copy of the support response so you know what was changed. A support case for this error recommends deleting the affected folder over FTP and reinstalling when the plugin file is missing; that is practical guidance, not a guarantee for every hosting configuration (WordPress support case).
The path is a symlink
In a file manager, a symlink may have a link indicator rather than a normal folder icon. In an SFTP client, its properties may show a target. Confirm the target path and whether other sites or deployments use it. Do not run a recursive delete against an unverified link; the documented Trac edge case explains why this can affect dashboard behavior (Trac ticket 15134).
The folder is already missing
If no matching directory exists, refresh the Plugins screen and check whether the plugin entry remains. A missing folder can leave an inconsistent install state. Remove the stale entry only through normal WordPress plugin controls or a host-assisted repair; do not edit core database tables by hand unless you have a tested recovery plan. Then install a fresh package and verify the site.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Scan for outdated or missing drivers - takes under a minute3Repair Windows errors before they cause bigger problemsThe dashboard still reports the old error after deletion
Clear any host or page cache and reload the update screen. Confirm that you removed the directory in the active document root, not a staging or backup copy. If the path is correct and the problem persists, ask the host to inspect disk quota, filesystem errors, security tooling, and PHP or web-server logs. Those checks require site-specific access and cannot be diagnosed from the WordPress message alone.
The update fails again after reinstalling
Stop repeating the same update attempt. Verify that the new package extracted into the expected slug, that the PHP process can write to the plugin directory, and that the account has available disk space. Have the host check ownership, quota, filesystem health, malware or web-application-firewall interference, and relevant logs. If the vendor supplies a previous compatible release, install it only from a trusted source while the underlying write problem is being corrected.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Plugin files and plugin data are different
Deleting a plugin directory removes its PHP, JavaScript, CSS, and other files. It does not by itself establish whether the plugin’s database tables, options, scheduled tasks, uploaded assets, or external account data were removed. Some plugins provide an uninstall routine; others intentionally retain settings for a future reinstall.
Before promising a clean removal, read the plugin’s uninstall documentation and look for an explicit setting such as “remove data on uninstall.” Keep the database backup from step 2 until the replacement is working and you have confirmed which data should remain.
When to involve the host instead of deleting files yourself
- You cannot obtain a working file-manager or SFTP/FTP login.
- The directory owner is a system account you cannot change safely.
- The plugin path is a symlink, bind mount, or shared deployment location.
- The host uses a security tool that may quarantine or recreate files.
- The site is a production store, membership system, or multisite network where an incorrect deletion could affect other sites.
Give support the exact error text, the plugin slug, the full path, the time of the failed update, and confirmation that you have a current backup. Ask them to confirm the directory they removed and whether they corrected ownership or permissions, rather than merely retrying the dashboard update.
Prevent the error on future updates
- Keep a tested file and database backup before plugin updates.
- Update one plugin at a time on important sites so the failing path is unambiguous.
- Use staging for major plugin changes and confirm that the deployment process handles ownership consistently.
- Do not mix manual uploads, automated deployments, and host restores without checking which system user owns the resulting files.
- Record symlinked or shared plugin paths in deployment documentation.
- Keep host contact details and a working file-manager or SFTP/FTP method available before an emergency occurs.
What success looks like
The repair is complete when the old directory is gone from the correct wp-content/plugins/ location, the site and dashboard load without the fatal error, a fresh trusted package installs into the expected slug, and the plugin’s primary feature works after activation. If any of those conditions is missing, treat the problem as an unresolved filesystem or compatibility issue rather than forcing another update.
Quick Recap
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.
