MyBB should start caching plugin versions for plugin authors to use. Remove them only on uninstall.
Right now I write my own cache and store all my plugin versions in that, but since MyBB has no built-in functionality to totally remove the a cache, I can't remove them on uninstall without more work (depending on storage method of course)
This would be nice for plugin upgrades. For an example of usage:
In my activate code, I grab any cached version number of the plugin, then I compare to the new version and if different, I call my upgrade script/code.
My upgrade code has a version compare block for every version I have released that needs upgrades to the DB or templates. That way it is incremental upgrades, so even plugins that are 5 versions old get upgraded properly. Works just like the MyBB upgrade
I guess if Dylan writes his proposed plugin_update() functionality, this would have to be part of it anyway. Anywhoo, it's still a good idea
If I write that plugin_upgrade() function, it would need to be there yes. In addition, you would be able to just swap plugin files to the new one (if well written even several versions different, since it would perform all intermediate updates too) and just click "Upgrade" on the ACP Plugins page listing for that plugin.
exactly. I currently rely on deactivate, upload, active method for my upgrades, just that a new upgrade acp option would reduce the amount of template work that normally goes on in those functions.
the upgrade option should be only available if the previously cached version is older than the new one. but the MyBB activate, install and upgrade code should all grab the existing version from the cache, run the plugin functions, then update the cache with the new version ID.
I would also want the plugin class' run_hooks() function to ignore out any plugins where the version reported by the file and the cached version are different; in order to prevent unwanted and incorrect functionality due to changes in the plugin's code.
that may be worthwhile. i am trying to think of any drawbacks, for the end user or the author.
(2012-01-14, 04:24 PM)pavemen Wrote: [ -> ]that may be worthwhile. i am trying to think of any drawbacks, for the end user or the author.
Only drawback would be things "missing" while they don't have it upgraded.
There is no need for a 'default' plugin_update() function in the core - the vast majority of upgrades to plugins typically require changes to files and those that do require upgrading are so complex that the core function would be ridiculous.
What we will be doing is adding a _delete method into the datacache.
(2012-01-14, 05:56 PM)Tomm M Wrote: [ -> ]There is no need for a 'default' plugin_update() function in the core - the vast majority of upgrades to plugins typically require changes to files and those that do require upgrading are so complex that the core function would be ridiculous.
What we will be doing is adding a _delete method into the datacache.
I think we're on a different page with this. What pavement and I are referring to is a function that, without reinstalling the plugin, will simply modify the plugin's settings, template modifications, and templates. Not a function that would automatically fetch new versions of the plugin for you. Hence why I changed the name to _upgrade, instead of _update.
An update/upgrade function (whatever you want to call it) in this case is for the plugin author to provide code that would make the incremental changes with the uploading of a new plugin file.
Its not meant to auto update a plugin, but make it easier and more consistent for plugin authors to track versions and apply incremental changes.
Right now, I have to create my own cache for the versions of my plugins, as would all other authors if they want to work similarly. If it was a centralized/official cache, that would make things simpler and the whole cache system does not get cluttered with a bunch of separate caches storing the same type of data. If the new update/upgrade function handles modifying the cache for us then there is no worry about authors messing it up.
Maybe have $plugins->get_cache_version($plugin_name) to get the currently cached version, then run the plugin_upgrade( ) in the plugin that will run the incremental changes via
if(version_compare($old_ver, '2.1.0', '<'))
{
//do the incremental change
}
if(version_compare($old_ver, '2.2.0', '<'))
{
//do the next incremental change
}
//and on and on
but the author has to provide this functionality if they want.
Then have a $plugins->set_cache_version($plugin_name) to set the new version for the next time the code is upgraded.
Tomm, it may not be very clean right now, but check out my MyShowcase plugin to see how I handle it. Look at the myshowcase_plugin.php and myshowcase_upgrade.php files.