Do you ask for passwords in the form?

No. The public form never requests access. Secure credentials are requested only after the scope and quote are approved.

Who reviews the incident?

The request goes to Jordi Ensenyat, founder of Code Barcelona and a WordPress specialist with more than 15 years of experience.

Is anything changed before the quote?

No. Visible symptoms and scope are reviewed first. Intervention begins after approval and with a rollback path prepared.

Do you work internationally?

Yes. WP Repair handles WordPress and WooCommerce incidents in English and Spanish through a remote service.

“Destination Folder Already Exists” During Plugin Installation

WordPress extracts a plugin into wp-content/plugins/<slug>. If that directory already exists, it will not merge a new package blindly. The folder may contain an active plugin, an incomplete update, a manually uploaded copy or unrelated code using the same slug.

Do not delete it until you identify its contents, version and data dependencies.

Identify the exact directory

Record the plugin/package name, source, intended version and destination path from the error. Inspect the directory through authorised file access.

Check:
main plugin file/header
current version
file modification times
directory size/count
activation status
recent update failure

Do not execute unknown PHP files to identify them.

Check whether the plugin is active

Review the Plugins screen if accessible or the active_plugins option through safe WordPress/CLI tools. Multisite network activation is stored separately.

A missing plugin from the screen can still have files if its main filename changed or header is damaged.

Do not rename/delete an active business-critical plugin during traffic without an outage plan.

Back up files and database

Archive the existing directory outside the public plugin path and take a database backup. Plugins often store settings/content in MySQL, which uninstall hooks may delete.

Simple folder removal normally does not run the uninstall hook, but confirm plugin behaviour.

Keep the trusted installation package and checksum/source.

Determine why the folder remains

Look for interrupted extraction, disk/inode exhaustion, permission errors or a failed previous manual upload. Check update/PHP logs at matching timestamps.

If files are a complete older version, this may be a replacement/update rather than a new install.

Fix resource/ownership problems before retrying or the next extraction will also fail.

Check slug and edition collisions

Two different products can occasionally use the same directory slug, especially a free plugin and a vendor’s premium replacement. Compare plugin headers, vendor and documented installation path before renaming.

Do not install the second package over the first unless the vendor explicitly supports in-place replacement. It may need the free base plugin to remain active under its original directory while the add-on uses another slug.

Compare with the trusted package

Diff filenames/checksums against the official vendor/WordPress package. Unknown additional PHP files require a security review before restoration.

Do not copy only the missing files into an uncertain directory; mixed versions can produce fatal errors and leave removed vulnerable code.

Use licensed vendor downloads for premium plugins, not another client’s directory.

Replace the directory atomically

On staging, deactivate if required, rename the old folder and place a complete new folder under the exact expected slug.

plugin-slug -> plugin-slug.backup
plugin-slug.new -> plugin-slug

Preserve ownership and permissions. Avoid a long period with both active copies using different slugs because WordPress may load duplicate classes.

Clear OPcache after replacement.

Handle database upgrades

Activating the new version may migrate its schema/options. Read release notes and take another backup before a large version jump.

Do not toggle activation repeatedly while a migration fails. Capture the first PHP/database error and use the vendor’s documented recovery.

Rolling files back may not reverse database changes.

Preserve translations and local assets

Official WordPress translations usually live outside the plugin directory, but some vendors store generated CSS, licences or templates inside their folder. Identify such writable data before replacement.

Move only documented local assets into the supported uploads/config location. Do not carry unknown PHP files into the clean package. After reinstalling, verify translations and regenerate vendor assets through the plugin’s own tool.

Verify and clean up

Test the plugin’s actual feature, administrator page, cron, REST/AJAX and logs. Confirm WordPress reports the intended version.

Retain the old folder outside the public document root only for the rollback window, then remove it according to policy. Recurring care should check disk, permissions and package integrity before updates; the error is safe WordPress behaviour that prevents uncontrolled directory merging.