Oh this is going to be difficult to fix.
The plugin has no way to know if a premium plugin is using the same name as a plugin in the free WordPress repository, I think it is the responsibility of the author of the premium plugin to avoid name collisions. On the other hand, WordPress should be in contact with the author of the free plugin to make sure that it is still compatible with the latest version of the CMS, as you mentioned, the free plugin hasn’t been updated in +2 years which makes things even worse.
I will think about this for a couple of days, maybe I can find a way to prevent name collisions from the Sucuri plugin, but be aware that there may not be a good solution for this.
Thank you for the report.
@yorman,
The only way I can think of to disambiguate a directory naming collision would be to parse the Plugin URI: value from the header comment. It should be unique.
I don’t know if the so-called “GPL Clubs” change this value. Even if they do, all the affected plugins are going to be premium ones.
Drew Mathers
The plugin is already parsing those headers, you can see the code here [1].
When the URI matches the domain name of the WordPress repository, the Sucuri plugin assumes that you are using a free add-on, otherwise assumes that you are using a premium code base and disables the reset option for that specific plugin. Since you were able to reset that premium plugin in your installation, I will assume that the URI in its headers was matching the condition highlighted in the code [1].
I think it would be easier to contact the author of that premium plugin and ask him to change the name, if they know that it causes conflicts with the WordPress repository, no matter if the free plugin is already deprecated.
[1] https://github.com/Sucuri/sucuri-wordpress-plugin/blob/13de2f4/src/api.lib.php#L909-L919
I am at a loss to explain this then, as the premium plugin’s Plugin URI didn’t point to wordpress.org. However, as both plugins are obsolete, it is probably not worth investigating further.
If you don’t mind sharing a copy of the code that powers the premium plugin, maybe I can find a solution, but as you say, this is such an isolated and rare case that implementing a solution may not be necessary. You can send the code to [removed] (removed to avoid spam) which is my personal email.
Alternatively, I could offer a different (unrelated) solution, force the Sucuri plugin to create a Zip archive of the plugin that is being reset because the action is executed. This way, if something wrong happens, like in this case with the name collision, you can simply revert the changes back to the original state with the backup from the archive.
I could not find the option for Sucuri to create a Zip archive of plugins before they are reset.
