If the plugin is distributed with Piwik, the auto-update process would ideally avoid reinstalling it.

I think the files should not be deleted automatically. The plugin should be in uninstalled state, with a message inviting user to delete the files?

This task sounds like the only critically missing piece of the plugin framework - am I missing something else?

The uninstall should warn that plugin-specific data may be deleted as part of calling the plugin's uninstall method, and may not be recoverable.

the uninstall method should also delete db colums if applicable.

I'm going to defer to post-1.0 since I have to make UI changes when I resume work on the plugin repository.

This is related to #60. We can't just uninstall a plugin (call uninstall to execute DROP TABLE *) as plugins might depend on that specific plugin. First we need to resolve dependencies.

Proposal: We add some way to specify a plugin as "Core" which is reserved to core plugins. Other plugins installed via the plugin repository can safely be uninstalled (including files), for core plugins we preserve the files as the auto-update mechanism would add them again.

So this requires #60

Hi,

I added the functionality in the plugin-installer plugin.
http://plugin.suenkel.org
(settings->pluginstore->advanced ->enable expertmode)

at the moment it does:

• goto maintainance-mode
• call uninstall
• move plugin/NAME/* to a tmp/pluginbackup/NAME
• remove tracker-cache/config.ini file-entries
• disable maintainence mode

this is done by "force" (aka ignore errors)
without #60 it is not possible to check dependendies and warnings to be ignored while deinstallation

@csuenkel2 I don't understand, it should be super simple

• Deactivate plugin is already implemented
• Add: Uninstall (that will call the SQL uninstall)
• Once uninstalled, user can "Enable" again which will enable+install
• Once uninstalled, user can "Delete" the plugin which will delete all files

This should cover 100% of the needs and no need to move files around. OK to set maintenance though (btw enableMaintenance etc. is implemented in: Piwik_Updates::enableMaintenanceMode()

of course you are right, but the "removePlugin" code in PluginManager seams to be unfinished.

• the functions are not consitent while using (loading and storing changes of) the config file (sometimes they rely on their own cached config-data - like unloadPlugin)
• some of the functions are declared as private
• e.g. the event dispatcher was unable to remove a "addMenu"-event
• for deinstallation the process "majorupdate" is missing
  ...

so at the end, I decided, without patching the PluginManager (which implies a lot of effort in testing and re-integration) to reuse as much as possible from the core and wrap the rest to an "expert-mode" (assuming "you know what you're doing"-people ;-)

of course you are right, but the "removePlugin" code in PluginManager seams to be unfinished.

absolutely, it's unfininshed and far from perfection :) so the best would be to improve this class (possibly split it into 2 smaller classes) and just make this code the one that is used in all plugin related things.

because this project is a "core" project, modifying & improving & refactoring & redesigning to KISS, all the related core files, is necessary!

In 2cfe210: Refs #546 Adding core "Uninstall" feature for Plugins and Themes + Cleanups + fix build by moving constant to PluginsManager
Todo

• ask for confirmation: "Do you want to uninstall X?" // warn that plugin-specific data may be deleted as part of calling the plugin's uninstall method, and may not be recoverable.
• call uninstall() method on the plugin class
• verify core plugins cant be uninstalled

In cc2d24c: refs #546 ask for confirmation before uninstalling a plugin

In b16d8cf: refs #546 call the plugins uninstall method before uninstalling it

In b79c18f: refs #546 display the name of the plugin in the confirm message