You upload a theme zip through the dashboard, wait for the progress bar, and hit this instead: Installation failed: Destination folder already exists. I ran into this last week while pushing a theme update on a staging box. The good news: it takes about two minutes to sort out once you know why WordPress is blocking you.
WordPress throws this error because a directory matching your theme’s slug already exists inside wp-content/themes/. Maybe an earlier install timed out, an automatic update got interrupted, or an old backup folder was left behind. By default, WordPress refuses to overwrite an existing folder during a zip upload. Here is how to fix it via the dashboard, SSH, WP-CLI, or SFTP.
Why WordPress Throws the Destination Folder Error
When you upload a theme through Appearance > Themes > Add New > Upload Theme, WordPress unpacks the zip into a temporary folder (usually in /tmp or wp-content/uploads/), checks the theme’s folder name (its slug), and checks whether wp-content/themes/[theme-slug]/ already sits on disk.
If it finds a matching folder, the installer halts immediately to prevent data loss. It is a sensible safety check so you don’t accidentally wipe custom template files, but it regularly triggers false alarms:
- Interrupted updates: An auto-update timed out mid-extraction, leaving behind half-unpacked files.
- Failed uploads: A script hit PHP’s
max_execution_timeor memory limits and died halfway through. - Bad zip packaging: You downloaded a bundle from Envato Market or ThemeForest that includes docs, demo data, and licensing files instead of just the installable theme zip.
- Stuck directories: You deleted the theme from the dashboard, but permission issues kept PHP from wiping the physical folder from disk.
If your zip is nested or structured incorrectly, you might also run into the theme missing style.css stylesheet error.
Method 1: Use the Built-in “Replace Active with Uploaded” Prompt
WordPress has a built-in comparison tool for folder conflicts during manual uploads. If you’re using the admin dashboard, you might not even need SSH or SFTP.
When the folder conflict happens, WordPress shows a comparison screen with two panels:
- The current version on the server (version number and folder name).
- The uploaded version extracted from your zip.
Click Replace active with uploaded at the bottom. WordPress wipes the old folder and swaps in the new package. If this fails with a blank screen or a permission error, your PHP user lacks write access to the directory, or the server timed out during extraction.
Method 2: Remove or Rename the Folder via SSH (Fastest)
If you have terminal access, fixing this via the command line is the quickest route. It bypasses web server upload limits and lets you keep a safety backup before deleting anything.
First, SSH into your server and head to your themes directory:
cd /var/www/html/wp-content/themes
ls -la List the directory to find the conflicting folder. For example, if you’re installing Astra and the target is astra, check what is currently sitting inside:
ls -la astra/ Instead of jumping straight to rm -rf, rename the folder first. That gives you an instant fallback if the new upload is missing assets:
mv astra astra-backup-$(date +%F)Head back to your dashboard and retry the upload via Appearance > Themes > Add New > Upload Theme. It should install without complaints. Once you confirm the site works, clean up the renamed backup folder:
rm -rf astra-backup-*Method 3: Overwrite Themes with WP-CLI
If you manage sites via terminal or deployment scripts, the WP-CLI theme install command is way faster than messing with browser uploads. It also has a flag specifically designed to ignore destination collisions.
Run this from your WordPress root, replacing the path with your zip location or the repository slug:
wp theme install /path/to/theme-package.zip --force The --force flag tells WP-CLI to overwrite any matching folder inside wp-content/themes/ without asking. To activate it in the same run, add --activate:
wp theme install /path/to/theme-package.zip --force --activateVerify that the theme is active and running the right version:
wp theme listIf you run updates across multiple sites, pairing WP-CLI with cron jobs saves hours. Check our guide on how to automate WordPress backups with WP-CLI and Cron before rolling out batch updates on production.
Method 4: Delete Orphan Directories via SFTP or File Manager
If you don’t have SSH access, use an SFTP client like FileZilla or your host’s File Manager (cPanel, Hostinger hPanel, etc.).
- Connect to your server via SFTP (usually port
22) using your credentials or SSH key. - Navigate to your web root (typically
public_html,www, or/var/www/html). - Open
wp-content/themes/. - Find the directory matching the theme you want to install.
- Right-click the folder and rename it (e.g., change
generatepresstogeneratepress-old). - Go back to the WordPress admin and run the zip upload again.
Once the upload succeeds and you check the site, delete that renamed -old folder to keep disk usage clean.
Fixing File Permissions and Ownership Conflicts
A common gotcha: you delete a theme inside the WordPress admin, but the folder stays stuck in wp-content/themes/. When you try to reinstall, you hit the destination error all over again. This happens when the web server user (like www-data, apache, or nginx) does not own the files, so PHP can’t remove them.
Check the ownership of your themes directory via SSH:
ls -ld /var/www/html/wp-content/themes/* If ownership shows root:root or an unprivileged user like ubuntu:ubuntu, PHP won’t be able to touch those directories. Fix ownership using the GNU chown utility:
# For Ubuntu/Debian running Apache or Nginx
sudo chown -R www-data:www-data /var/www/html/wp-content/themes # Set correct directory and file permissions
sudo find /var/www/html/wp-content/themes -type d -exec chmod 755 {} ;
sudo find /var/www/html/wp-content/themes -type f -exec chmod 644 {} ; Standard permissions should be 755 for directories and 644 for files. Never set permissions to 777 to get around an upload error—that leaves your server open to arbitrary script execution.
Preventing Unzip Timeouts and Broken Uploads
Large commercial themes (often 30MB+ with bundled plugins and demo assets) can easily hit PHP limits. If the upload or extraction takes longer than PHP allows, the process dies halfway through, leaving a broken directory that triggers the error on your next try.
Low limits can also cause errors like the link you followed has expired.
Bump your PHP limits in your php.ini file per the PHP core directives:
; Adjust PHP parameters for large theme uploads
upload_max_filesize = 64M
post_max_size = 64M
max_execution_time = 300
max_input_time = 300
memory_limit = 256M If you’re on shared hosting without php.ini access, add these rules to your root .htaccess file instead:
# Increase upload limits for WordPress
php_value upload_max_filesize 64M
php_value post_max_size 64M
php_value max_execution_time 300
php_value max_input_time 300Restart your web server or PHP-FPM service so the new limits load:
# For Nginx + PHP-FPM on Ubuntu
sudo systemctl restart php8.2-fpm
sudo systemctl restart nginxFrequently Asked Questions
Will deleting the existing theme folder erase my site settings?
No. Customizer settings, widgets, menus, and layout options are saved in your database inside the wp_options table (under theme_mods_[theme_slug]). Deleting the folder inside wp-content/themes/ only removes the PHP, CSS, and JS files. That said, if you edited functions.php or core template files directly instead of using a child theme, those custom edits will be lost.
Why does this error happen when updating an already installed theme?
During an update, WordPress downloads the new archive, extracts it to a temp folder, deletes the old theme directory, and moves the new files in. If your server hits a timeout, runs out of disk space, or encounters a file permission lock during that delete step, the cleanup fails and the old folder stays in place.
How do I extract a theme zip manually on the server?
Upload the theme.zip file into wp-content/themes/ using SFTP or scp, SSH into the server, and unpack it directly with unzip:
cd /var/www/html/wp-content/themes
unzip theme.zip
rm theme.zipMake sure the web server user owns the extracted files (e.g., chown -R www-data:www-data [theme-folder]), then activate it in your dashboard.
