Hi Ken,
I'm a fairly happy bunny today I have managed to complete the march to 2.6.1 from 1.9.10. on my test server at least. Your help and advice has been very encouraging and helpful.
In the spirit of sharing this is how i did it version 1.9.10 > 1.9.19 > 2.0.10 > 2.2.11 > 2.3.11 > 2.5.4latest to 2.6.1latest. My test server will take 2.7 but my host is limited to 2.61 so until hosting is changed this is my limit.
I think the big lesson to be learned from this is don't do this on your live server! you will go from e.g 1.9.10 to 2.61 as in my case but you will be restoring the site from a backup of your testserver which starts with a backup of your live site gets upgraded and then this is backed up and transferred to your public site.
Back up the existing site download moodledata and moodle and the current database and recreate the site on a test server with proper access.
I used apache and used 'sites available' to tell it it was serving the live site.
why, because some code, pictures mainly will be linking to files on the live site address.
I also used hosts to redirect my browser on my client computer to fetch data from my test server
e.g 192.168.1.15 mymoodlesite.com in hosts it won't go looking for it on the internet and moodle won't complain about the wrong site name.
I also had ssh access from my client to my server i and used filezilla for transferring files both ftp from my live site and via ssh to my server. one thing to note with filezilla in its default configuration it treats files without extensions as ascii as moodle stores files with a string of random looking letters and digits as a file name in later versions with no extension you need to change the default to binary. Otherwise you will corrupt all your docs, powerpoints pdfs and pictures.
it also pays to have command line access with mysql
very useful is
mysqldump -u root -p moodle > 2.6.1db.sql
I call each dump by the version of moodle it works with
mysql - u root -p moodle < 2.6.1db.sql
is also very useful you use this on an empty database usually (I did use a dump I called patch.sql which just had the 3 block tables with slightly changed contents it deleted the tables recreated them and filled them).
There is documentation on line for converting to unicode and innodb
mysql -u root -p
gets me into mysql.
DROP DATABASE moodle;
easiest way to clean up replace the moodle by your database name.
CREATE DATABASE moodle;
creates a new empty database you populate it with your database backup as shown earlier.
SHOW DATABASE;
fairly obvious shows the databases you have created on the system.
USE moodle;
select which database to work with in this case moodle
SHOW TABLES;
gives you a list of tables on the current database.
DROP TABLE mdl_upgrade_log;
this table is a pain if something went wrong even after you fixed the problem 2.0.11 will not proceed to upgrade if this table exists,
GRANT SELECT,INSERT,UPDATE,DELETE,CREATE,CREATE TEMPORARY TABLES,DROP,INDEX,ALTER ON moodle.* TO moodleuser@localhost IDENTIFIED BY 'apassword';
you should only need to do this once its the user and password used in config.php and is essential to letting moodle do anything. change moodleuser and apassword to your requirements.
SHOW GRANTS For 'moodleuser';
should show you permissions for your moodleuser its not very readable but should be ok.
EXIT;
takes you out of mysql and back to your regular command line.
Don't be afraid to do an install instead of an upgrade if you need a copy of a clean set of tables set to defaults
I needed this because my admin block's were missing I looked at the three block tables and found some missing entries I copy pasted these into my copy of the live database. each line is indexed e.g (1, xxx), (2,xx),
(4,xx) so i know (3,xx) is missing so I add that entry and save the sqldump under a new name and drop the database create it again then fill it again with my modified dump at the command line. This got me my missing blocks back once happy with the site in its current version i back up the database again with its current moodle version number and move on to the next upgrade.
if the upgrade fails I can rename moodle to moodleversion and rename the old version back to moodle restore the database for the old version. check its ok and then try to upgrade again (e.g 2.2.11 was too big a leap from to go to 2.6.1 so i added some intermediate steps 2.3.11 and 2.54latest which did work, (problem was I had lost my password in the jump from 2.2 to 2.6 also unit tests was missing).
So finally I am at version 2.6.1 but it's not finished the old courses are now in legacy format so now its a case of working my way through them adding the missing files which are in moodle data. I can use the live site as a guide so i can see what needs to go where. Once I've finished that I can upload the new site to the host.
unfortunately the host doesn't give me a command line so i'll have to use phpmyadmin and copy paste my updated database using sql queries i'm writing to clean new tables as if i tried to overwrite the old ones there would be duplicate keys. best practice would be to use a fresh database however you can get by using a new prefix e.g if your old moodle used mdl_ as the prefix then use say mdl2_ as a prefix and when your ready switch to mdl2_ as the prefix in config.php you will need a few changes to config.php as your site root and moodledata root will be different to the paths on your host. But to your website everything looks the same.
Anyway hopefully this post will be of some use to future upgraders. Do not do the march on your live site!it is tedious slow and you may not even have the tools to hand to do the job, once your new site version is ready then you can ftp the new version and set the config.php to look at the right database tables. If it goes wrong you can easily revert to your old site and figure out what went wrong.
hope this post is useful and not too confusing to follow.
I know I skipped converting to utf and innodb but this should help
http://docs.moodle.org/26/en/Converting_your_MySQL_database_to_UTF8
(i used vi not vim but it works the same)
regards
john