plugin updates during upgrade

gangeli

Planning on updating from 1.17 to 1.17.3 soon.

I was just curious what the proper procedure is to upgrade plugins.
Do I just download them and overwrite the ones in /include/plugins when replacing the other files?
Or should I disable them first, overwrite them, and enable them again after the upgrade?

Are plugin settings saved in the database? I want to make sure I don't do anything to lose the settings, as setting up oauth2 was not my favorite thing 🙂

I'm also curious what the /plugins dir is for vs /includes/plugins

Thanks

KevinTheJedi

gangeli

Update plugins by replacing old .phar with new one. Then you can upgrade osTicket. You do not need to disable them at all.

Yes, everything done through the UI is saved in the database and persists across upgrades.

There is no /plugins directory, only /include/plugins. If you have a /plugins directory then you or someone else must've added it by mistake.

Cheers.

sjswarts

@KevinTheJedi - Does this also apply to the language .phar files?

I overwrote the language file in /include/i18n/en_GB.phar and now in /scp/system.php it shows:

Also are you meant to see any changes in version numbers? Prior to adding the new plugins to the directory /include/plugins I took a screen shot and the numbers didn't change from:

KevinTheJedi

sjswarts

Look at the Built date.

Plugin version numbers rarely change.

Cheers.

sjswarts

@KevinTheJedi - Thanks for your reply.

The first screenshot was to focus on the warning that says "The originator of this extensions cannot be verified". What is this? Something wrong with the .phar file or new security mechanism's being deployed?

The second screen shot was to show that there are no build dates visible. So how do I know that the plugin is the latest without the version changing? Seems very odd. Why would you not change the version? Or if you insist on only keeping the build date approach there needs to be another column which says "Build Date" bit like the language plugin.

I couldn't find any documentation on updating plugins on the Wiki.

osTicket ideally would move to updating plugins directly in the WebGUI interface. Surely that would be more secure, less potential for error, easier to document (if even needed)??

KevinTheJedi

sjswarts

We have to sign language packs and plugins but we have an issue (we are currently working on) that prevents us from doing so. You’re fine.
I was looking at language packs not plugins so my mistake. Version numbers for plugins only change if there are significant changes. Kind of like the core's "major" versions.
That’s because updating plugins is very simple; simply replace the PHAR with the new build and you’re done.
That might be possible with v2.0 but with the current code that’s not possible.

Cheers.

sjswarts

KevinTheJedi I was looking at language packs not plugins so my mistake. Version numbers for plugins only change if there are significant changes. Kind of like the core's "major" versions.

That may be so, but I don't know many software companies that if they make any update (even small) don't increment the version. If you have 0.6, just put 0.6.1. Otherwise how does anyone know it is the latest version?

The reason why I'm making a point is that you mentioned in the release notice "Language and Plugins updated"... so clearly the intent is to update the plugins.

The problem is that we don't know what languages or plugins are updated. If the download site were to reference the version numbers it would be simple to just go:

Oauth2 Client = 0.6.1
My osTicket says 0.6, update required.

Two Factor Authenticator = 0.3
My osTicket says 0.3, no need to update.