Manually installing a deleted plugin fails

[jonathanbossenger]

Quick summary

Sometimes, during plugin development, a developer might want to deactivate and delete a plugin and then manually install it using a zip via the Upload Plugin screen.

If a plugin is deleted through the Plugins interface, and then an attempt is made to manually reinstall the plugin, the error "The destination directory already exists and could not be removed." appears. The only current way to work around this is to restart the Studio site.

Steps to reproduce

1. Navigate to the wp-admin of a Studio site
2. Manually upload a plugin zip via Plugins -> Add New -> Upload Plugin
3. Delete the plugin via the Plugins list page
4. Attempt to manually upload the plugin again

What you expected to happen

The plugin should upload successfully

What actually happened

The "The destination directory already exists and could not be removed" error appears.

Impact

One

Available workarounds?

No and the app is unusable

Platform

No response

Logs or notes

I assume this is related to how the filesystem is mounted when the Studio site is started.

[katinthehatsite]

@jonathanbossenger could you please let us know which plugin it was? I tried reproducing this, for example, with WooCommerce but was not able to see this error. Also, what version of Studio were you using? Thanks!

[chubes4]

I reproduced this with a deterministic upload/delete/upload flow against a fresh Studio site.

Findings:

• This reproduces when the site is using the sandbox/WASM runtime.
• I could not reproduce the same error with the native PHP runtime.
• After deleting the plugin through wp-admin, the plugin directory is gone from the host filesystem, but the running sandbox/WASM runtime still behaves as if the destination exists during the next upload. That leads WordPress to show: The destination directory already exists and could not be removed.

Workaround: switch the site to the native PHP runtime, then retry the plugin upload.

Given native PHP is becoming the default runtime, this may only need fixing if we want to keep this workflow fully supported for sandbox/WASM sites.

[linear]

from kateryna:

Thanks for clarifying! I will add it to the Yolo queue

[jonathanbossenger]

Hello folks, I just returned from a week's AFK, updated Studio to v 1.13.0, which defaulted my site to the PHP runtimes, and can confirm the error only exists when using the sandbox/WASM runtime.

If the native PHP runtime is becoming the default, feel free to close this issue. I don't see the point of spending development time fixing something that only a small percentage of folks will even see.