Upgrade woes

Upgrade woes

by Peter Brown -
Number of replies: 6

I'm experiencing a similar problem to the one reported by Debbie Unterseher about a month ago.  I upgraded my site from Moodle 3.1 to Moodle 3.3.  At the same time, I upgraded mod_attendance from 3.1.0.3 to 3.3.5.  I removed the old files and installed the new ones.  Running the upgrade, however, just hangs when it tries to upgrade mod_attendance.

I get the same result upgrading from the command line or from the browser; whether I'm upgrading from 3.1.0.3 to a 3.3.5 downloaded from the Moodle plugins directory, to a 3.3.5 cloned from Git, or to 3.2.4. Enabling error messages gives me no error messages—the upgrade process just silently hangs when it reaches mod_attendance.

I've checked the file ownership.  The files are all owned by the same account that's running the upgrade.

Any ideas for possible fixes would be much appreciated!

Average of ratings: -
In reply to Peter Brown

Re: Upgrade woes

by Dan Marsden -
Picture of Core developers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers Picture of Plugins guardians Picture of Testers Picture of Translators
Hi Peter,

Please make sure you have escalated your debugging settings by setting display errors to 'on' and setting your debugging level to "developer"

then try upgrading and check to see if any further information is shown.

If it is still not working, please take a screenshot of what happens when it hangs - (unless it's just a white screen)

Also in your database check to see what the value is of the "version" field in attendance is by running this query:

select * from mdl_config_plugins where plugin = 'mod_attendance' and name= 'version';

That will help to identify at which point the upgrade is failing.

thanks,

Average of ratings: -
In reply to Dan Marsden

Re: Upgrade woes

by Peter Brown -

Thank you!

I set display errors to On and the debug level to Developer.

I removed the old code for both mod_attendance (which was 3.1.0.3, version 2016052201) and block_attendance (which was 3.2.1, version 2016050901).  In their places, I unzipped mod_attendance_moodle33_2017050204.zip and block_attendance_moodle33_2017020700.zip (both downloaded from the Moodle plugins directory).

Running the upgrade got me this window (unchanged after ten minutes while I did something else):

Screenshot

mod_attendance and blocks_attendance were the only plugins to be upgraded.

The database query (executed *before* I did anything to stop the upgrade process) returns the following:

mysql> select * from mdl_config_plugins where plugin = 'mod_attendance' and name= 'version';
+-------+----------------+---------+------------+
| id    | plugin         | name    | value      |
+-------+----------------+---------+------------+
| 10420 | mod_attendance | version | 2016052201 |
+-------+----------------+---------+------------+
1 row in set (0.00 sec)

I can see that it failed before updating the version in the database.  Hopefully that tells you more than it does me smile.

How can I be of further help in isolating this thing?

Peace,
--Peter

Average of ratings: -
In reply to Peter Brown

Re: Upgrade woes

by Dan Marsden -
Picture of Core developers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers Picture of Plugins guardians Picture of Testers Picture of Translators

looks like it's probably timing out when running the calendar upgrade. It adds an event in the calendar for every attendance session.

if you run the upgrade via cli scripts instead of via the web it will probably work a bit better.

Alternatively you could probably comment this line out in the upgrade.php:

https://github.com/danmarsden/moodle-mod_attendance/blob/MOODLE_33_STABLE/db/upgrade.php#L175

(add a double slash // in front of the "attendance_upgrade_create_calendar_events()" line.)

The version of the plugin in github allows you to disable the calendar events in the admin settings and also has a script on the admin page that lets you create/delete events if required so the step in the upgrade can be skipped.

hopefully that makes sense.

Average of ratings: -
In reply to Dan Marsden

Re: Upgrade woes

by Peter Brown -

Not only does that make perfect sense, it solved my problem.  Thank you! smile

I shifted to the Github version of mod_attendance, and tried the upgrade from the command line.  It hung again.  I commented out line 175 in mod/attendance/db/upgrade.php, and the upgrade ran fine.

That let me get to the settings page for the module, where I unchecked "Create calendar events".  I then went back and re-checked out the mod_attendance code from Github, so I'd be clean WRT the upstream.  (If I'd been thinking, I'd have tracked the MOODLE_33_STABLE branch *before* doing my Moodle upgrade.  Since Moodle won't let me downgrade, though, I'm now riding the bleeding edge with master.  But I figure there are a lot worse problems I could have smile.)

Thank you again!

Peace,
--Peter

Average of ratings: -
In reply to Peter Brown

Re: Upgrade woes

by Dan Marsden -
Picture of Core developers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers Picture of Plugins guardians Picture of Testers Picture of Translators

at the moment there aren't really any differences between the master and MOODLE_33_STABLE branch except the version. (but that is likely to change in future and the master branch may not work on the 3.3 stable branch in future.)

To fix it up you could just replace the code in your install with the moodle 3.3 branch and then update the version in the config_plugins table:

update mdl_config_plugins set version = '2017050214' where plugin = 'mod_attendance';

version "2017050214" is the version currently on the 3.3 stable branch in github - that value may change if I push any other changes through before you do this.

and of course - do that at your own risk etc. etc....

Average of ratings: -
In reply to Dan Marsden

Re: Upgrade woes

by Peter Brown -

Of course--I'd seen the database downgrade fix before, but had forgotten it.  I'm now happily tracking MOODLE_33_STABLE.

For the benefit of anyone coming along later who may see this, the correct SQL query is 

update mdl_config_plugins set value = '2017050214' where plugin = 'mod_attendance';

where the value to use in place of '201705214' the the value of $plugin->version in version.php of /mod/attendance/version.php.  (That's *so* close what you had, Dan, that it was dirt simple for me to tweak it.  But a future admin might or might not have the right context for it to be so simple.)

Thank you again!

Peace,
--Peter

Average of ratings: -