We need a CLI counterpart for plugin actions: - Install (from a URL, from a .kpz) - Upgrade (from a URL, from a .kpz) - Uninstall - Configure based on some file format
+1000000 I opened Bug 25671 a while ago for this, but I ran out of time/energy for it, as we don't really use plugins much at this point. I'm happy for that bug report to be marked as a duplicate of this one, if Tomas is going to work on this. Really really looking forward to progress on this.
*** Bug 25671 has been marked as a duplicate of this bug. ***
Btw, it could be interesting after installing/upgrading a plugin to do a graceful restart on Starman using HUP as per https://metacpan.org/pod/Starman.
(In reply to Nick Clemens from comment #0) > We need a CLI counterpart for plugin actions: > - Install (from a URL, from a .kpz) > - Upgrade (from a URL, from a .kpz) > - Uninstall > - Configure based on some file format I actually had another thought about this... What if we had an instance-level configuration file that defined the plugin, the plugin version, and the plugin configuration? We could even re-use that configuration file across multiple Koha instances which would help with the logistical challenges of managing plugins. (We could use symlinks to point to a central file, or point to a central file from koha-conf.xml for instance.)
This would be great.. we do have https://git.koha-community.org/Koha-community/Koha/src/branch/master/misc/devel/install_plugins.pl of course.. but having a package friendly debian script with all the options described here would be much nicer.
(In reply to David Cook from comment #4) > (In reply to Nick Clemens from comment #0) > > We need a CLI counterpart for plugin actions: > > - Install (from a URL, from a .kpz) > > - Upgrade (from a URL, from a .kpz) > > - Uninstall > > - Configure based on some file format > > I actually had another thought about this... > > What if we had an instance-level configuration file that defined the plugin, > the plugin version, and the plugin configuration? I like baby steps. We should add the features to some script(s) and then we teach them to read from a config file.
(In reply to Tomás Cohen Arazi from comment #6) > I like baby steps. We should add the features to some script(s) and then we > teach them to read from a config file. Sounds like a plan to me. If the logic is in a module, then it should be trivial controlling the module from either CLI args or a config file I reckon. I've been revising my TODO list, and while this functionality has fallen down the list, it's still something I would still like to have. Happy to test patches on this one.
(In reply to Martin Renvoize from comment #5) > This would be great.. we do have > https://git.koha-community.org/Koha-community/Koha/src/branch/master/misc/ > devel/install_plugins.pl of course.. but having a package friendly debian > script with all the options described here would be much nicer. I didn't used to understand this script, but I think I understand it better now... I suppose a person could add a "pluginsdir" that points to a central location of curated plugins and then run this script to install them across the board. Or symlink from /var/lib/koha/<instance>/plugins/Koha/Plugins/<plugin>. We don't really use plugins except for one or two here or there, but I wonder sometimes if we would use them more if it were easier to install en masse. And maybe it has been and I just haven't been creative enough... ;)
(In reply to Nick Clemens from comment #0) > We need a CLI counterpart for plugin actions: > - Install (from a URL, from a .kpz) > - Upgrade (from a URL, from a .kpz) > - Uninstall > - Configure based on some file format I'm still keen on this one. I would love to turn on plugins for all my Koha instances while disabling the Plugin web upload. This feature would be a bit more convenient than using install_plugins.pl. Actually I was most of the way with Bug 25671, although that code didn't take into account that you could have multiple "plugin_dir" entries. That's a gotcha with this CLI feature. I suppose you could always assume a default path and override or fail as necessary. (Using a "default" attribute on the main plugin_dir path would be handy...) I don't know. I keep wanting to use plugins more, but it's just not been quite convenient enough. I'm still thinking a bit about my "Plugin Manager" Koha plugin which would provide a list of curated plugins that would let library staff install plugins with a click of a button. And then deploy that "Plugin Manager" Koha plugin using a centralized "plugin dir" and just run 'koha-foreach perl /usr/share/koha/bin/devel/install_plugins.pl' for install/upgrade of those centralized plugins that I want to enforce on all instances...