Roll Back of an Add-on/Plugin

Roll Back of an Add-on/Plugin

by Ken Task -
Number of replies: 5
Picture of Particularly helpful Moodlers

Didn't find a forum that 'fit' ... so this one closest? to what is sought, I think.

When an add-on/plugin is initially installed it creates it's own tables
in the DB and they also update/add data to some core tables.
Example: An add-on called eduvision has entries in mdl_modules
and mdl_config_plugins - others?

There are also entries in mdl_config related to eduvision.
Is that 'normal' - entries in mdl_config?   Think it's the only one I've seen that does that.

When there is an update available for a plugin/addon via mdeploy,
the process for update shows a link to a zip file where the update will
be acquired in the warning screen that states no backup is made prior to
the update/upgrade of the plugin.   It suggest to make a 'snapshot' backup
at that point.

What other core tables would be involved in updating/upgrading an add-on?
And, if one were to do a 'snapshot' that is NOT full SQL dump and tar ball
of the code, could a home grown  'snapshot' be a single sql dump of core tables + tables
for the addon/plugin and code of the addon/plugin thus enabling a 'rollback' of the addon/plugin?

That's close to what mdeploy does right now, I think, but no 'rollback utility'
exist in admin interface to use mdeploy directory files and 'rollback' a troubled upgraded addon/plugin.

A rollback would be a great improvement over entire site SQL dump.  IF, for example,
in-compatibilities was discovered a week later or white screens of death started to
appear, rolling back the entire site means students/teachers/site looses data collected that entire week.   Best, if one could rollback only that which was
updated/changed specifically to the troubled addon/plugin (might still loose some data, but that would be limited to just the plugin/addon.

And another thought ... there is a tool to check how your server suits current and future installation requirements ... shows things like Moodle version, PHP and extensions, MySQL(DB) version etc.   Sure would be nice to have a similar tool that checked all plugin/add-on compatibility for current version to higher versions.

Thanks, in advance, for any thoughts.

'spirit of sharing', Ken

Average of ratings: -
In reply to Ken Task

Re: Roll Back of an Add-on/Plugin

by Howard Miller -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers

There is no concept *anywhere* in Moodle to rollback. Your only reliable option is to delete it (dumping your data) and re-install. 

The issue isn't what's in the various core tables, it's what's in db/upgrade.php for the plugin. You need to go and look at that code and work back from there. It could, potentially, be *anything*. 

Average of ratings: -
In reply to Howard Miller

Re: Roll Back of an Add-on/Plugin

by Ken Task -
Picture of Particularly helpful Moodlers

First, thanks for reply.   Yep, kinda figured there wasn't any tool for rollback from the Moodle Admin UI, but was considering how one might be able to pull off such a feat.

Other info not shared previously .... troubled addon not functioning as it should.   The last version available via mdeploy ('the Moodle Store') showed compatibility below version of active Moodle site now at a higher version.   Maintainer sent to OP a zip file.  OP tried to 'install' and ran into the 'cannot install' issue (directory exist).

Site has over 1000 courses and in/among those this troubled addon used a lot ... plugins checking shows over 3000+ instances of this troubled addon.

Removing the current version would mean Moodle would also remove all it's data.  Uhhh, opps ... just broke the majority of courses and 3000+ instances.

So that's why the question about rollback ...

The only thing I could think to do is get a mysqldump of the tables for the troubled plugin and make sure I got all tables that might need to be included ... like mdl_config (in this case), etc..  Then remove the plugin.  Data now gone.   Install new (supposedly fixed) plugin.   To get the data back, restore the dumped tables (might also run into issues there, I realize).

Had tried the old/old way of hiding the plugin directory.   Uploading the zip to proper location, unzipping, checking ownerships/permssions.   Then accessing the Moodle going to Notifications to trigger the event of an update/install of the plugin.   That did NOT occur ... no install nor update.   And in looking at real time logs ... oops ... X number of users getting 500 errors.   Good thing I hid the original directory!   Un-did what I did ... site back to 'normal'.

So is there something I didn't do ... should have done differently?

Thanks, in advance for any strategy ...

'spirit of sharing', Ken



Average of ratings: -
In reply to Ken Task

Re: Roll Back of an Add-on/Plugin

by AL Rachels -
Picture of Core developers Picture of Particularly helpful Moodlers Picture of Plugin developers Picture of Testers

Hi Ken,

If I'm not mistaken, you need to also find the Moodle database entry for the addon in the mdl_config_plugins table, that lists it's current version, then set the version to something prior to the "rollback" version, so that an "upgrade" to setup the old version will be triggered.

I've had to do this before, and it did get the previous version of a plugin to working.

Average of ratings: -
In reply to AL Rachels

Re: Roll Back of an Add-on/Plugin

by Ken Task -
Picture of Particularly helpful Moodlers

Thanks, Al.

Finally discovered that. :\

However, a qustion about the 'date prior to' thing ... so if It shows: 2016080300 then to get it to trigger an update/upgrade, one would change that value to something 'before' ...  like 2016070300?

In doing a diff comparing the version.php files of an archive of the plugin versions:

diff ./eduv1/eduvision/version.php ./eduv2/eduvision/version.php

Get this:

< $module->version   = 2012072501;      // The current module version (Date: YYYYMMDDXX)
< $module->requires  = 2011070100;      // Requires this Moodle version
< $module->release  = 'v1.0.0';      // Requires this Moodle version
< $module->cron      = 0;               // Period for cron to check this module (secs)
< $module->component = 'mod_eduvision'; // To check on upgrade, that module sits in correct place
---
> $plugin->version   = 2016080300;      // The current module version (Date: YYYYMMDDXX)
> $plugin->requires  = 2015051100;      // Requires this Moodle version
> $plugin->cron      = 0;               // Period for cron to check this module (secs)
> $plugin->component = 'mod_eduvision'; // To check on upgrade, that module sits in correct place

And it gets stranger and stranger ...

Have a new fresh install of moodle code that slightly higher in versions of 2.9.x.

The plugin installs in the new moodle.   Can be used ... everything appears to function.

In the older site, the Settings link in the modules.php file of the site begets an error.

Section error!

More information about this error
Debug info:
Error code: sectionerror
Stack trace:

    line 481 of /lib/setuplib.php: moodle_exception thrown
    line 26 of /admin/settings.php: call to print_error()

https://docs.moodle.org/29/en/error/admin/sectionerror

error/admin/sectionerror

The error means that a new admin page 'foo' (the one you're developing right now) is not registered with the Admin menu.

And following the 'more info' it shows:

The solution is to add a reference to the page in the appropriate file in admin/settings/XXX.php. Something like:

$ADMIN->add("parent_section", new admin_externalpage('foo', "Foo Admin Component", "$CFG->wwwroot/$CFG->admin/foo.php"));

The appropriate file is?

In the admin/settings/ of the site that needs fixin:

appearance.php  courses.php      frontpage.php  language.php  mnet.php     security.php  subsystems.php  users.php badges.php      development.php  grades.php     location.php  plugins.php  server.php    top.php

in the admin/settings/ of the new fresh 2.9.x code where it works:

appearance.php  courses.php      frontpage.php  language.php  mnet.php     security.php  subsystems.php  users.php badges.php      development.php  grades.php     location.php  plugins.php  server.php    top.php

So which .php file is 'foo.php'?

Restore of a DB backup is out of the question ... too much time has passed.   Site gives weekend workshops in which the site is used and there are all the other ongoing courses as well.

Hope that kinda explains why  I was asking about rollback without loosing data.

Will continue to dig ... :\

'spirit of sharing', Ken

Average of ratings: -
In reply to Howard Miller

Re: Roll Back of an Add-on/Plugin

by Ken Task -
Picture of Particularly helpful Moodlers

Follow up questions ...

"only reliable option is to delete it" means deleting the addon.

This right after "(dumping your data)" means that action of deleting the addon will dump the data ... ie, destroy/erase all data (the links to videos)?   

Have to ask such questions to clarify for OP (who is probably lurking this conversation by now).

Thanks, in advance, Ken


Average of ratings: -