Might I suggest, to add indications of openfire version compatibility for the plugins in the repository? I see some are considered deprecated, some actually wind up causing blocking exceptions in the openfire server instance because of incompatibilities… Instead of just having a list of “available plugins”, it would be useful fo have some kind of indication of the versions of openfire that each plugin has been successfully tested on. If this feasible? Something like “tested up to openfire server version xxx”.
For example, I have “openfire focus provider” in the available plugins list. But if I install it, I come to find out that it is not needed in the more recent version of openfire. That would be nice to know before installing it…
There is indication of minimum required Openfire version here https://www.igniterealtime.org/projects/openfire/plugins.jsp (this is done recently and there was no such thing before). In Admin Console it shouldn’t show you new version or plugin at all, if it requires higher version than your Openfire. In repositories on GitHub this information is stored in pom.xml files.
Focus plugin is a unique issue. It is bundled together with 0.9.5 Meetings plugin. But one might still need it, if for some reason they want to use 0.9.4 version. So it wasn’t removed. Having it to somehow detect that you install 0.9.5 Meetings version and not offer you Focus plugin is probably too complex to implement. And in time Focus plugin might be removed (i guess, i don’t know exact plans).
Ok that is a good step forward. But perhaps it would be useful also to indicate up to which version a plugin has been tested? Let’s say a plugin requires a minimum of openfire version 2; it will show up in the admin interface for later versions of openfire. However if that plugin hasn’t been updated or tested on more recent versions of openfire, perhaps it could cause exceptions? I believe it would be useful to have two indicators, one for minimum version required and one for most recent version that is has been successfully tested on (“known to be compatible up to openfire version xxx”).
I’m just mentioning this because I have been playing around with getting an openfire server up and running on and off for a couple years now, and each time I do a fresh install on my server, everything seems to be working alright until I start installing plugins from the admin interface, then everything seems to go haywire. I’m having a heck of a time sifting through the error logs. And we’re talking about fresh installs… And the funny thing is that uninstalling all plugins one by one doesn’t seem to fix the exeptions in the logs, so either the plugins are leaving artefacts behind or there is something else in the openfire itself that needs to be ironed out…
Perhaps it would be useful in cases like the Focus provider, to add a note in the description (“not needed with Openfire Meetings since version xxx”). Instead of discovering by trial and error 
This community is driven by a few volunteers doing something in their spare time from their regular jobs. I see your idea. But there are no resources to do such thorough testing. So in the end such column would became stale and not useful. There are some automatic tests being added to Openfire to test features when building new version. Maybe at some point in future this could be extended to plugins, but i guess it would require a lot of work.
The assumption is that all plugins should work with the new versions of Openfire. Of course, with every major release some incompatibilities are found (like recently with 4.3.0 release some plugins stopped working correctly, oh and when they were fixed, then they stopped working with 4.2.3 and so on). In such case we expect bug reports and then such issues are fixed and new version is released. So i suggest posting such issues in the forums.
I think description on the downloads page is pulled from the plugin itself. So, to add such remark would require a new release of Focus plugin, which could make things even more confusing and could break the snapshots structure. I’m not sure, maybe releasing 0.9.4.1 version with such comment? @guus @Dele_Olajide
1 Like
My plan is to remove the offocus plugin in a few months, as ofmeet 0.9.4 is unlikely to give people a functioning video conference anyway (people should upgrade).
1 Like
Just to follow up on my last comment about things going haywire: after uninstalling all plugins, I was still having a strange issue of http-bind page being all greyed out and not letting me set to “enabled” even though it was working before, and even though the system properties page was saying that it was enabled. In the end I restarted the openfire service from my ssh console, and voilà everything started working again. I’ve reinstalled all plugins, and things seem to be working okay… The old advice of turning a machine off and on again really does still hold 
1 Like
Following up again, I tried installing the websocket plugin. After I install it I get this message:
| Openfire WebSocket | Provides WebSocket support for Openfire. | 1.2.1 | Tom Evans | |||
|---|---|---|---|---|---|---|
| The version of the plugin that is installed is no longer compatible with Openfire 4.2.0 and later versions! |
This is what I am referring to, I think it would be useful to have some kind of indication in the admin interface before installing a plugin, about which versions of openfire both min and max the plugin is compatible with.
When I say “tested with” I’m not necessarily talking about extensive testing techniques, it can also be a community feedback. Wordpress does something like this, you can click an upvote button if you have installed a plugin on a newer version of wordpress and you see that it still works just fine. So the next person that wants to install it will see that so many people have successfully installed this version of the plugin on this latest version of wordpress.
You have a knack for finding edge cases Websocket plugin was incorporated into Openfire core since 4.2.0. But it is still available for those using older Openfire versions. Well, at least it shows an error and you can then remove such incompatible plugin. I guess it has to download and try to install the plugin to then check its plugin.xml and see what min and max versions are. Not ideal. But i don’t know if there can be a better way dealing with this.
As for crowd sourced testing. Yeah, that would be great, but again, this needs infrastructure adjustment and expanding (to track these votes) and developing such system. All requires resources. Then one would hope that enough users would actually press the vote button But i would leave that for developers to decide whether such thing seem feasible.