Talk:Upgrading

Notes --Chris collman 07:34, 29 October 2006 (CST)

Sorry for this ramble but... this page needs more work. My instincts don't like the instructions for using download archive, but I am not qualified. Suspect they are Moodle 1.0 .

For example, this section the instructions tell me to copy the old moodle to moodle-backup, then unpack moodle-latest to moodle-backup (that is what the mv command says I believe). Big issue not mentioned is that non-standard modules (Score Lock comes to mind) alters the SQL tables. While any non-standard module should not, who knows the ways a site may have been improved which will impact more than just the moodle files. We just have to be careful about being too specific and run up a huge red flag for those who like to jump off cliffs

This page starts off by refereing to installing 1.6 (good) for more specific instructions. I think the entire page needs to either be more generic with lots of links, and/or give general instructions as in a checklist. There are too many types of Moodle installations to get specific. How different are installs from updates? --Chris collman 07:46, 29 October 2006 (CST)

What does the below line mean?

You can also use the "Export" feature in Moodle's optional "Database" web interface to do the same thing on all platforms.

Is it a reference to PHPMyAdmin, maybe? If yes, then this might confuse people now that there is a Moodle module "Database" too, which is quite unrelated to the whole Moodle installation database... Samuli Karevaara 17:43, 15 April 2006 (WST)

I agree - this comes from a time space where there wasn't such a thing as a database module. I see that it is called MySQL Admin on the download pages these days - I'll update the page accordingly --Koen roggemans 18:37, 17 April 2006 (WST)

Okay, I see! Now, specially with the new descriptive text and a link, it makes a lot more sense :-) Samuli Karevaara 20:53, 18 April 2006 (WST)

mysqldump paramaters

According to mysqldump --help, parameter "-a" is deprecated. You should use "--create-options" instead.

I have updated the docs page to replace -a with --create-options Jon Witts 21:46, 24 June 2009 (UTC)

Improvements needed

Let me start by saying I agree with CC (note #1) that this page needs work. Let me start with the very first sentence: "Moodle is designed to upgrade cleanly from any earlier version to any later version." Well, it may be designed that way, but it doesn't work that way. I have seen several problems reported in the forums by Moodlers who tried to skip a major version in their upgrading (1.6 to 1.8, 1.4. to 1.6, etc.). The page should warn people about that. I don't think I know enough to say all that needs to be said about that correctly, so I hope a Moodle expert does something about this.

Also, while this page warns people, as the installation FAQ does, not to upgrade by overwriting the old code, it doesn't really say enough about how to handle patches to the code that have been made that will be lost if the old code is simply moved out of the way, in effect, and replaced by the new. Not just non-standard blocks and modules, themes, and language packs, but patches as well. --Richard Enison 04:57, 13 February 2008 (CST)

LOCK TABLES

When I was trying to dump the database using the command on the article page, I got a mysqldump error

mysqldump: Got error: 1044: Access denied for user 'moodle'@'localhost' to datab
ase 'moodle' when using LOCK TABLES

I then added the following option and it seamed to work

--lock-tables=false

Hope that was correct!?

Lindsay Magnus 01:19, 5 March 2008 (CST)

Location of MySQL Admin Module

The reference to the location of the MySQL Admin module is incorrect. It is now actually in the Modules and Plugins database. The direct link is http://moodle.org/mod/data/view.php?d=13&rid=448 --Ron Meske 08:40, 22 August 2008 (CDT)

Come on! Upgrading has to be simpler and clearer than this!

I'm not an IT ninny, but having a precious Moodle website the last thing I need is any uncertainty about the upgrading process if all I am doing is going from 1.8 to 1.9.

For a start, how about about simple graphics to outline the overall process with links to bypass those that may not apply to all users (MySQL backing up, for instance).

What isn't clear is what happens when I've shunted all my 1.8 files across to a new holding folder and then unzipped the new stuff into the main site folder, and then go into Moodle>admin to do the biz - what biz?.

Remember that for many smallish VLE site administrators like me, most of the work is on coordinating content and users, not tinkering with technology. Messing around with the engine itself is so infrequent that an upgrade is a very new (and therefore risky) procedure to take on board. Nothing should be presumed.

From a confidence point of view, the trouble is if you're a Moodle-engine innocent as I am, it is important to know in advance exactly what standard files and common personalised ones to copy across from 1.8 to 1.9 (like a check list of them rather than an 'etc'?), and what the final process in Moodle will look like (i.e. are there important options to know about beforehand in the interface etc), what error messages could occur, and what to do about them.

If the process fails and the site won't load properly, then one really is working in blind desperate hope! If the process is really as simple as the article says, then great, but it does not read like that at the moment. Trepidation rules ok! --Toby Heriz-Smith, 15:05, 4 September 2008

It looks like the Upgrade instructions have not kept pace with the installation instructions. For install, we now have install quick-start, as well as more detailed instructions, and then step-by-step instructions on a number of different platforms: Administrator_documentation. It would be nice to have the same for upgrade, but people will have to write it.

Also, one of the reasons that the upgrade instructions are so short is that normally it is that easy and does not often fail. The outline procedure is just:

1. Backup everything just in case
2. Update the moodle code files
3. Go to the admin notifications page and let Moodle update itself.

Of course, in a real situation, you probably want to test before updating your live system, which adds a few steps. http://moodle.org/mod/forum/discuss.php?d=104887--Tim Hunt 20:22, 4 September 2008 (CDT)

Agreed

I will put that one on my "remember to do when" list. As Tim points out the instructions have not kept pace and I suspect my comment back in 2006 is being echoed by Toby. I will get pretty good at upgrading when we upgrade our production 1.5 Moodles to 1.9. So that will include a 1.8 to 1.9 upgrade as well :) Or not, because my site administrator is opinionated on how we will do it. I do fresh installs all the time and rarely update. --Chris collman 16:56, 10 September 2008 (CDT)

Page not clear : should we unpack the upgrade in an empty directory ?

Some sentences let readers think that we should unpack the upgrade file in an empty directory : "The best way is to rename the current Moodle directory to something else, then unpack the new Moodle archive into the old location." : said twice in the page. "Do not overwrite an old installation unless you know what you are doing ... sometimes old files can cause problems in new installations"

But other sentences let readers think that we should unpack the upgrade file in a directory containing previuous install files : "Unzip or unpack the upgrade file so that all the Moodle software program files are overwritten on the server." let us think that we should unpack in a directory containing the old files so that they will be overwritten. In the "Finishing the upgrade" section the sentence "Moodle will automatically detect the new version and perform all the SQL database or file system upgrades that are necessary." may mean that Moodle will upgrade the old install file system.

not clear : when should we use saved files ?

It's not clear if we should copy the old config.php file in the new directory before or after using the notification link in the site administration to start the upgrade process.

Linux instructions for copying old files accross

Regarding the three instructions:

cp moodle.backup/config.php moodle

cp -pr moodle.backup/theme/mytheme moodle/theme/mytheme

cp -pr moodle.backup/mod/mymod moodle/mod/mymod

The first line seems fine, whereas I am wondering if there is a mistake in the second two. Should the correct instructions be:

cp -pr moodle.backup/theme/mytheme moodle/theme/

cp -pr moodle.backup/mod/mymod moodle/mod/

?

Suggestion for clarifying this page

I think this page would be much clearer if it simply linked to Site_backup at the appropriate point, rather than duplicating all the instructions on how to take a backup in this page. It means we have two inconsistent descriptions of how to do a backup. Clearly the two descriptions of how to take a backup should be merged, keeping the best features of each, before this copy is deleted. I am afraid I am not volunteering to do this.--Tim Hunt 08:25, 20 November 2010 (UTC)

Thanks Tim, will do over my first cup of coffee this AM. Just my kind of edit :) --Chris collman 13:55, 20 November 2010 (UTC)