When a WordPress core, plugin, or theme update fails, Admin often shows a short message: another update is currently in progress, destination folder already exists, installation failed: could not create directory, or a generic “update failed.” These are related but not the same failure. Each points at a different layer: an update lock row, a destination path the installer will not overwrite, or the filesystem refusing to create directories.
Work this checklist in order. Prefer staging when you can reproduce the update there. Take a backup before deleting options rows or plugin/theme folders on production. If the front end only shows “briefly unavailable for scheduled maintenance,” use the stuck in maintenance mode checklist for the .maintenance file—this article covers update/install error messages, not that front-end lockout. If one covered WordPress issue is clearly to blame and you want help, use the $99 one-time fix after you can authorize access.
Define what failed
- Copy the exact Admin or installer message (or a screenshot). The wording chooses the branch below.
- Note whether it was a core update, a plugin update/install, or a theme update/install, and which slug/name was involved.
- Confirm whether the public site still loads. A maintenance banner alone is the maintenance-mode path; a fully down site may need site down first.
- If a specific plugin’s features broke after a partial update, keep this article for the installer error, then finish with plugin not working.
Quick triage map
| What you observe | Likely layer | First useful check |
|---|
| “Another update is currently in progress” | Update lock option | Wait ~15 minutes; ask your host to confirm no update is still running before removing core_updater.lock |
| “Destination folder already exists” | Installer will not overwrite that path | Check whether this is an existing installation; prefer its normal update flow or supported ZIP replacement—do not assume the folder is trash |
| “Could not create directory” / “installation failed” | Permissions, ownership, or disk | Ask host about free disk space and write access for the web user |
| Front end stuck on scheduled maintenance | .maintenance file | Maintenance-mode checklist (do not only clear the update lock) |
| Update UI fails and the whole site is offline | Broader outage | Site down checklist, then return here |
Variant A — “Another update is currently in progress”
- Wait for the normal lock window. WordPress stores a short-lived update lock (commonly the
core_updater.lock option). It is meant to expire on its own—often within about fifteen minutes. If an update tab was left open or a prior run died mid-flight, waiting is the safest first step.
- Do not start overlapping updates. Avoid clicking Update again across multiple tabs, and do not run a host-level or WP-CLI update at the same time as the Admin updater.
- Before you remove the lock, confirm nothing is still running. Ask your host to confirm no Admin, automatic, host-managed, or WP-CLI update is still running before removing
core_updater.lock. Elapsed time alone is not proof.
- If the message remains and the host confirms the updater is idle, clear the lock with a backup. Export or snapshot the database first. Then remove only the stuck lock option (via a trusted WP-CLI command your host documents, or a careful options edit in the host’s database UI). Do not drop unrelated options. Retry one update afterward.
- If the front still shows maintenance copy, clear or finish that path with the maintenance-mode checklist—the lock row and the
.maintenance file are different controls.
Variant B — “Destination folder already exists”
- Check whether this is an existing installation. Prefer its normal update flow or the supported ZIP replacement option when offered. “Destination folder already exists” does not prove a leftover or incomplete install—it may be a valid installed plugin or theme.
- Use the product’s normal update path first. From Admin → Plugins/Themes (or the host’s supported updater), update that slug instead of forcing a fresh install over the same folder.
- If you use a ZIP, prefer the installer’s replacement option when WordPress offers it. Do not invent a delete-and-reupload habit for an active plugin or theme.
- Remove a folder only after confirming it is an unused incomplete copy and saving a private backup. Download a private zip of that directory first (store it outside the public web root). Do not delete an active plugin or theme to clear this message; ask your host if its status is unclear.
- Retry one update after the path is clear or the existing install was updated correctly. Retest the feature that plugin or theme provides—see also plugin not working.
Variant C — “Could not create directory” / installation failed
- Ask the host about disk space and inode limits. A full volume produces create-directory failures that no WordPress toggle will fix.
- Confirm the web user can write
wp-content. Updates need to create folders under wp-content/upgrade, plugins, and/or themes. Ownership or permission policies (especially after a migration) often block that. Prefer a host-approved fix over chmod recipes copied from random posts.
- Check whether the host requires a specific file-ownership model (for example deploy user versus PHP user). If policy blocks Admin installs, use the host’s documented deploy path or ask them to run the update.
- Retry one update after the host confirms write access. If it still fails, send them the exact error text, the plugin/theme slug, and the time of the attempt.
Safe habits before the next update
- Back up files and database before bulk updates.
- Update on staging first when the host provides it.
- Update one high-risk plugin at a time on production.
- Keep a SFTP/file-manager path ready so a stuck lock or unclear destination folder does not require guessing inside a half-broken Admin.
Common causes
- A previous Admin or CLI update exited early and left
core_updater.lock until expiry—or an update is still running elsewhere.
- Installer refusing to overwrite a destination path that already belongs to an installed plugin/theme (or, less often, an unused incomplete copy).
- Filesystem permissions or ownership after a host move.
- Disk full or host write policy blocking
wp-content creates.
- Overlapping update clicks across tabs or tools.
When a $99 one-time fix fits
Request the $99 one-time WordPress fix if you want help clearing one clearly defined update/install failure on one WordPress site—stuck update lock after the host confirms nothing is running, a destination-folder conflict you cannot safely classify, or a bounded permissions handoff with the host—so a specific core/plugin/theme update can finish. Paste the exact error text and what you were updating. We confirm the scope before work begins. Send credentials only through the private access link provided after your request is accepted.
Full site rebuilds, unmanaged multi-site fleets, recurring host policy fights, and unrelated feature work are outside this offer. Maintenance-banner lockouts belong on stuck in maintenance mode.
Related checks
If these checks do not clear the installer error, send your host the exact message, the plugin or theme slug, whether disk space was checked, and the start time. Suspected compromise needs a security investigation as well as finishing or rolling back the update.