View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0025977||mantisbt||plug-ins||public||2019-08-06 16:25||2019-08-11 16:28|
|Target Version||Fixed in Version|
|Summary||0025977: Question about a new plugin for checking latest release of plugins|
I'm playing with a plugin that uses the GitHub API to check if there is a new version available, and adds a button to download, unpack, back up existing version, and update to new version. I think it's really nice and makes updating plugins easy and convenient. Just raw form right now, I would say I'm about half way done to make it really usable.
Is there any interest to have this functionality added to 'Manage Plugins' of the main project? Or, should I just continue to put this into a "Extra Plugin Management" plugin? It would require using a user token, otherwise I think users would see max api request errors if they tapped it a few time a day, which I think maybe is why it should remain in a plugin. But I guess it could be turned on/off in the main app.
Anyway, just wanted to see what the mantisbt team thought about it
|Tags||No tags attached.|
I believe the original intent of @jreese (who authored the Plugin API in Mantis 1.2) when he created the mantisbt-plugins org, was to create a global plugins repository, allowing to do not only what you suggest, but also have the ability to search and instal plugins from the list.
I have myself had the intention of implementing something like that, after seeing what other tools do that (e.g. Wordpress, DokuWiki), but never got around to it. IMO it's definitely something that would be useful to the community, so if you're willing to work on that, great !
If all features can be fully implemented within a plugin, then I'm sure we would consider making it a Core plugin when it's ready and well-tested, but to achieve that we might need to make changes to plugins structure.
I would gladly participate in discussion, development and testing, as time allows (I don't have much of that nowadays, unfortunately).
What about using composer for plugin management?
Keep security in mind.
@dregad i will target it then to be a replacement type thing for the current plugin management, with all of the existing functionality, plus the new
It would be good to see a plugin able to specify a URL for updates. This would allow companies to install/deploy updates on their own plugins; that might not be published externally.
I think the main thing to avoid is a requirement that plugins are hosted in a specific way/location to be able to update. For example, "it must be in the mantis-plugins repo on GitHub" - As we all know other the years platforms have come and gone; some people moved away from GitHub in protest to gitlab when Microsoft bought them out.
A command line approach would be good - most of the time, the likely reason updating a plugin will be that the core has been updated - to be able to update the core, and then run a command to update plugins to match the core would be good. I'd definitely avoid trying to do it in the web interface; it adds security risks like @atrol describes - and also would mean that the plugin is being updated whilst having hooks loaded by the user using the system.
The other factor here is the rate of change is quite low.
We have web server configured not to be able to write to the filesystem where possible, so the non-UI approach would be great!! Would really look forward to seeing that.
Maybe it would be worth defining an update schema that could be published e.g.
So with the above, current version of the plugin is 2.0, but requires mantis >2.2.1
IF a user were on an old version, that could be offered / would only be warned they are out of date if they meet the requirements. So a mantis user stuck on version 1.2.19 of mantis, would be offered version 1.0 of the plugin.
A user on version 2.2.0 of mantis would be offered 1.5 of the plugin.
They would know that they are out of date / not on the latest version, but not be able to download the updated plugins via the console
I like the idea of being able to specify a location (kind of a "store") for plugins.
Command-line is good, and as you explain might be a requirement in corporate scenarios, but it can't be the only option - some shared hostings do not provide access to command-line.
Having an effective GUI is essential IMO, even if security does not allow writing, it will help admins to identify which plugins require upgrading.
The "update schema" would probably need more attributes to work - some plugins manage support for Mantis in separate repo branches
Anyway, this is starting to look like a lot more than just a plugin ;-)
Maybe I'm missing something, but "specifying a URL for updates"... based on what protocol to find version number, changelog, etc? That's even more restrictive than saying all plugins should be on GitHub with "releases", at least the protocol is in place. Anything built to produce to a client I/we build would have to know of the protocol, how versions will be requested, etc, to display that a new one is available, etc... Can you please your thought more when you have a chance?
Keep in mind I am merely a minor contributor, so I don't want to stray to far away from my own needs, where that would be GitHub releases. I already have a working prototype now, I started by just adding the additional functionality to the existing Plugin management, in a separate plugin of course though. so it basically looks the same with the additional feature of checking for and displaying new version number if one is available, updating to new version, and restoring previous version. I don't see how specifying a url could even work without a defined rc config file in place like npm, kind of like you mentioned in your second post, but that is waaay out of scope for a one or a even a few developers doing this on the side.
The GUI is essential for me, so that's my main goal to start with. Only the plugin directory itself needs to be writable, which is fine for my small situation.
ss-get-version-buttons.png (34,309 bytes)
ss-get-version-buttons.png (34,309 bytes)
"based on what protocol" - I think the point was one would define something that makes sense for mantis.
For example, we currently have a development and production server - it would be useful to be able to do a release which could then be easily deployed to the production server - however as they are internal plugins, they do not live on GitHub.
Even looking at yourself, where you seem to have some references to SVN - I think you will understand the corporate environment which may not have all their code publicly on GitHub (for various reasons).
So in this case, the plugin object would allow an additional URL, for instance: 'update_url' - that can return the latest version that is appropriate and where to download it from.
In terms of the schema example I added - the logic is already available for that in the core - as the core detects what plugins can be activated based on the versions.
The other benefit of the plugin defining an update URL is it would allow forks of a plugin - so for example, let's say that we took the plugin listed above 'Server Files' and customised it for our company needs. As it stands, we'd have to rename the plugin, as the plugin would not realise that it is not the same one, and would try to install the wrong plugin. (that problem would also apply if two plugins had the same name).
If you are using mantis in a company, you might get asked at some point to create a plugin that would be internal to your company and not for public use - at which point, you wouldn't be able to use the update mechanism for it.
@dregad made valid points regarding supporting webhosting/GUI scenarios - I know we've had failed wordpress updates with their infrastructure in the past trying to use the GUI - e.g. if the web server is keeping the file php open such that it can't extract the replacement / delete the old etc - hence suggestion of the command line approach. My only comment back on webhosting/GUI scenarios is whether people are using them less - with the move to azure/aws/containers etc - are 'shared' setups a dying option?
I could mock up a prototype if people are able to agree on a schema.
|2019-08-06 16:25||spmeesseman||New Issue|
|2019-08-08 11:22||dregad||Status||new => feedback|
|2019-08-08 11:22||dregad||Note Added: 0062530|
|2019-08-08 12:58||cproensa||Note Added: 0062534|
|2019-08-08 13:32||atrol||Note Added: 0062535|
|2019-08-08 23:24||spmeesseman||Note Added: 0062538|
|2019-08-08 23:24||spmeesseman||Status||feedback => new|
|2019-08-10 04:08||tjones82||Note Added: 0062552|
|2019-08-10 04:13||tjones82||Note Added: 0062553|
|2019-08-11 04:29||dregad||Note Added: 0062555|
|2019-08-11 14:17||spmeesseman||Note Added: 0062556|
|2019-08-11 15:22||spmeesseman||File Added: ss-get-version-buttons.png|
|2019-08-11 16:28||tjones82||Note Added: 0062557|