Is the current behavior causing problems? I kind of like the fact that settings stick around, but I'm not sure of the implications with lazy-load plugins or blocks.

(In reply to comment #1)
> Is the current behavior causing problems? I kind of like the fact that settings
> stick around, but I'm not sure of the implications with lazy-load plugins or
> blocks.

I'm not sure whether having the settings stick around might cause problems or not -- that was just an observed behaviour, and I honestly have no idea if it's a possible issue. However, I think allowing enabled plugins to be deleted without first disabling them isn't ideal. I'll definitely agree that this is small potatoes.

I've just deleted the Help Block Plug-In and noticed two strange things:

1. The plug-in is deleted for all journals -- Wouldn't it be better to only provide the option to disable a plug-in for journal managers? I am not sure if the journal managers are aware what does it mean to delete a plug-in from the server file system and I think that they actually shouldn't be able to decide it for other journals hosted on the same installation. For most of the plug-ins (except gateway and generic) they even don't have the possibility to disable but only to delete the plug-in. Maybe to allow the deletion only to the admin?

2. Deleting the plug-in didn't delete the entry in the database table 'versions' that leads to the error 'DB Error: Duplicate entry 'help-1-0-0-0' for key 1' and thus makes it impossible to install the plug-in again.

Hello,

Deleting the plug-in (in 2.3.5) doesn't delete the entry in the database table 'versions' that leads to the error 'DB Error: Duplicate entry '...'
for key 1' and thus makes it impossible to install the plug-in again.

Is this a bug?

Thanks!

Yes, that's definitely a bug. The plugin installer shouldn't presume that there are no settings already in place.