Opened 21 months ago
Last modified 8 weeks ago
#60550 new defect (bug)
A plugin is deactivated if it is updated and the plugin folder has been renamed at some point.
| Reported by: |
|
Owned by: | |
|---|---|---|---|
| Milestone: | Awaiting Review | Priority: | normal |
| Severity: | major | Version: | 6.4.3 |
| Component: | Plugins | Keywords: | needs-patch |
| Focuses: | administration | Cc: |
Description
This seems to be a new unexpected behavior:
A plugin whose folder has been renamed will be deactivated as soon as you update it.
Reproduce:
- Rename the folder of an activated plugin to something like plugin-name-xy (People do this all the time for several reasons)
- The plugin will be disabled (expected due to the modified plugin folder)
- Activate again the plugin via wp-admin
- Update the plugin to a new version
- The plugin folder will be renamed to plugin-name (Unexpected)
- The plugin will be disabled silently (Unexpected)
Change History (3)
#2
@
21 months ago
A collegue just told me this behavior exist from the beginning and I assume it's caused by the zip folder structure where the plugin main folder name is the first folder of a plugin.zip.
In that case I suggest adding a red colored plugin meta notice like this then:
https://monosnap.com/file/sJQnbqeC8GzGOg9eeR6zUPot005f8K
"You have renamed the plugin folder plugin-name/plugin-name.php to something else. Please rename it or this plugin will be disabled on next update."
This could be realized by a simple check if the plugin slug exist as folder inside the wp-content/plugins/ folder and would not be an expensive check.
#3
@
8 weeks ago
- Keywords needs-patch added; 2nd-opinion dev-feedback removed
Thanks for the detailed report and reproduction steps.
I can confirm the behavior:
- When a plugin folder is renamed, WordPress allows re-activation.
- On the next update, the folder name is reset back to the original slug, which leads to the plugin being silently deactivated.
This is indeed unexpected behavior and can negatively impact sites, since users may not notice the deactivation right away.
Your suggestion to display a notice is a good approach. A lightweight check for mismatched folder names at the plugin list screen could prevent silent failures and provide clear guidance to site owners.
I am aware the plugin is disabled because wordpress renames its folder, so the result is not unexpected from a technical viewpoint but WP should not do that, especially not silently after an update and I "believe" this was not always the case. Did this change intentionally?
The problem is that a user might not notice that a plugin is disabled, especially when plugins are automatically updated.