Recovering from a Fantastico installation

Recovering from a Fantastico installation

by John Wheaton -
Number of replies: 8
I wrote this up as a how-to, in the hope others may benefit.

Fixing a Fantastico installation of Moodle

I fell prey to temptation and went for the one-button click method to install Moodle on my web server. Big mistake, as I learned soon enough.

Fantastico, on my server, installed version 1.8.2. No problem, I figured. I'll just install the newest version of Moodle right over 1.8.2. Big problem - I got an error right away, saying it could not find $libdir/adminlib.php.

After searching through Moodle forums at www.moodle.org, I found the admonition that you should never, never, never use Fantastico to install Moodle. As others have discovered before (and probably since) I did it, Fantastico installs make it very difficult to upgrade Moodle manually.

I was already in the process of developing my Moodle site, so I did not want to trash that work and start over. So, I attempted to install a parallel Moodle site, using the Moodle-developer-approved upload method, and wrest control of my site from Fantastico's version 1.8.2. My goal was to recreate the site using a manually installed version 1.8.6.

To make a long short, it worked. (I should say here that none of my 1.8.2 files were altered in any way. I had a plain vanilla 1.8.2 installation.) So here's what I did.

SUMMARY:
Fantastico -- Moodle 1.8.2 root directory: /public_html/moodle; database: mdle1; data directory: /moodle/uploaddata (I did later change this config.php setting to /moodledata and moved the location outside /public_html, per Moodle recommendations.)

Manual install -- Moodle 1.8.6 root directory: /public_html/moodle186; database: moodle; data directory: /moodledata186

Procedure -- Backup existing moodle database. Create new empty moodle database. Upload Moodle 1.8.6 files to /public_html/moodle186 directory. Install Moodle 1.8.6 using empty moodle database. Use the same username and password for admin account as Moodle 1.8.2 installation. Ensure 1.8.6 works. Alter 1.8.6 config.php to point to the 1.8.2 database (mdle1) and moodledata. Reload the 1.8.6 homepage. Comply with notification to update the database. Moodle 1.8.6 now looks exactly like previous 1.8.2 installation. Change directory names and config.php to point users to version 1.8.6 (moodle186 --> moodle; moodle --> moodle182). Fantastico site is now out of commission. "Official" site is now default.

DETAILS
First, the preliminaries.
1. Database character set encoding. One problem with Fantastico is that it frequently does not use utf-8 charset encoding and collation for the MySQL databases it creates. Official Moodle installations, however, do use utf-8. My Fantastico Moodle database, mdle1, was using the latin1_swedish charset. I figured that would cause problems during the database handoff, so found this php script at http://www.webhostingtalk.com/showthread.php?t=682119 to convert all my tables' charset encoding and collation.

code---------
<?php
// your connection
mysql_connect("localhost","root","***");
mysql_select_db("db1");

// convert code
$res = mysql_query("SHOW TABLES");
while ($row = mysql_fetch_array($res))
{
foreach ($row as $key => $table)
{
mysql_query("ALTER TABLE " . $table . " CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci");
echo $key . " =&gt; " . $table . " CONVERTED<br />";
}
}
?>
-----------/code


To see if all was well, I reloaded the Moodle 1.8.2 page. Other than an advisory to reload and log in again, there were no worries. (I suppose clearing my browser cache would have simplified matters.)

2. Moodle's data directory. Fantastico creates the user upload data directory (which it calls uploaddata) within the Moodle root directory. The official Moodle advice, however, is to keep this data directory outside the web root (/public_html in my case) for security reasons. So I had manually created a /moodledata directory, copied the folders and files from Fantastico's ./uploaddata into it, and edited the config.php file to reflect the new location. Probably unnecessary, given my upgrade plans, but I'd rather be safe than sorry.

3. Moodle upgrade version. From previous experience with CMS applications, I knew an incremental upgrade would be easier than a major version jump. Fantastico installed Moodle 1.8.2, and the Moodle download site has 1.8.6. So, I went with that one. I figured there would be minimal database changes from 1.8.2 to 1.8.6, allowing me to reassign databases without too much grief.

4. Upload Moodle 1.8.6 and install it. Not much to say here. Use a reliable FTP client like FileZilla and make sure all the files get uploaded. Or conversely, upload the archive and expand it on the webserver. Once all the files were in place, I proceeded to install Moodle 1.8.6 in its own directory using its own database. I used the same admin username and password as the 1.8.2 installation to eliminate any possible login problems.

Let's catch our breath and look at what I did. I had an existing Moodle 1.8.2 website up and running, installed by Fantastico. Upgrading it to (eventually) 1.9.2 looked near impossible, because of Fantastico's quirky installation methods, so I installed a separate Moodle 1.8.6 website with its own database and root directory. Two Moodle sites side by side.

Now, here's the potentially dangerous part. It's why you have to have a backup of your existing Fantastico-created database. I used phpMyAdmin for that. cpanel also has its own backup apps, but a standard MySQL export is foolproof. It's also a good idea to backup your existing Moodle root directory when doing upgrades, but since I was running two Moodles concurrently, I did not plan to change the existing Moodle 1.8.2 root at all.

5. Edit Moodle 1.8.6's config.php. You want the new, pristine Moodle to use the existing database (mdle1 for me) instead of the nearly empty new database (moodle in my case). Here is where I figured it would be a good idea to have both databases using the same charset. So, I opened the 1.8.6 config.php and changed the configuration to point to the 1.8.2 database and the 1.8.2 /moodledata location. Then I reloaded the 1.8.6 home page, got another advisory about a database server error, reloaded again and logged in as the admin. (Remember, I used the same admin account on both sites!)

6. Update the 1.8.2 database. Version 1.8.6 advised me I had to update the database. I took a deep breath -- this step is a one-way street without a db backup -- and clicked "continue." Eventually, I ended up with a version 1.8.6 site that looked exactly like my 1.8.2 site. I emptied the cache to eliminate some duplicate images, and voila! My upgrade worked!

7. Point users to the correct version. You could do this with a redirect page, or by telling them the new URL. I chose to rename the directories and alter the 1.8.6 config.php accordingly. So, /public_html/moodle became /public_html/moodle182, and /public_html/moodle186 became /public_html/moodle. I changed the 1.8.6 config.php to reflect the changes.

8. Once I am sure everything is working OK, I will delete the moodle182 directory and virtually empty moodle database, since neither is necessary.

I am assuming, though I will wait to find out, that upgrading to 1.9.2 will now be a piece of cake with an "official" Moodle installation.
Average of ratings: Useful (1)
In reply to John Wheaton

Re: Recovering from a Fantastico installation

by Helen Foster -
Picture of Core developers Picture of Documentation writers Picture of Moodle HQ Picture of Particularly helpful Moodlers Picture of Plugin developers Picture of Testers Picture of Translators
Hi John,

Thanks a lot for your detailed write-up approve which will no doubt be of help to others. I've added a link to this discussion on a couple of pages in Moodle Docs - Web Hosts and Integrations - so people can find your write-up easily.
In reply to John Wheaton

Re: Recovering from a Fantastico installation

by Richard Enison -
JW,

I could be mistaken, but as I look at the script you show in your post, I see that all it does is execute an ALTER TABLE query on each table in the database. I could be mistaken, but I am not sure whether that is sufficient for databases using non-latin characters, such as Greek, Arabic, and Chinese; or maybe even latin characters with accents and other diacritical marks, as most European languages use. I would be interested to know if all the text data in your database is in English, or do you have some of those languages represented in it; and if so, did the data itself actually get converted to UTF-8 correctly, or does it print as gibberish or question marks? Because I can recall seeing posts in this forum in the past complaining about that kind of thing, because they didn't use the database migration script when they were in Moodle 1.6 or 1.7.

If not, and if you don't want to run a test of this, perhaps I will. If it doesn't work, what needs to be done is to update the database migration script from 1.6; as I mentioned in a recent thread, this might be necessary because of changes that have been made in Moodle lately, chief among which is the use of xml files instead of sql files to describe the tables. See http://moodle.org/mod/forum/discuss.php?d=106821#p470224.

RLE
In reply to Richard Enison

Re: Recovering from a Fantastico installation

by John Wheaton -
Since my site is still in its infancy, the only content is what I've written, which is in English. It's an ESL site, so I am expecting my students to write only English as well. However, one student logged in using her Chinese name (and not using pinyin, which I had required), and it appears on my screen as ?? marks. I figure she logged in before I did the Moodle upgrade, so as you suggest the data did not get converted to UTF8 along with the tables.

I was in 1.8.2 and upgraded to 1.8.6. Should I run the db migration tool anyway?
In reply to John Wheaton

Re: Recovering from a Fantastico installation

by Richard Enison -
JW,

You could try. But since that tool is only available in Moodle 1.6 and 1.7 (I would avoid 1.7), that will be somewhat difficult. I outlined a procedure for doing so in the post I linked to in my last post in this thread, but in that same post I said it might not work because of the change in Moodle from using sql files to xml files. Let us know if you are able to get it to work. If not, I will try to update the script.

RLE
In reply to Richard Enison

Re: Recovering from a Fantastico installation

by John Wheaton -
Given that it only affects one user at this point, and that I want them to use pinyin anyway, I think I will leave things alone at this point. Everything (except my nanogong uploads) is working fine at this point, so now I just want to develop some content for the site.

If you manage to update the script, let me know and I'll give it a whirl. Right now, I'm not up to hacking code to fix a tiny error.
In reply to Richard Enison

Re: Recovering from a Fantastico installation

by John Wheaton -
FYI, Richard.

One other student registered using Chinese characters and the characters are being displayed correctly, so I am going to forget about updating the existing datum to utf8.
In reply to John Wheaton

Re: Recovering from a Fantastico installation

by belina koel -
Hi, thank you for this, it is very helpful. I installed Moodle with Fantastico and do have these problems. Could you explain where to put this code , in the config php, a new phph file or ??? Thanks.
In reply to belina koel

Re: Recovering from a Fantastico installation

by Richard Enison -
BK,

I fear JW did not see your post. Although his post is less than three months old, he is no longer enrolled in Using Moodle. But if it's okay with you, I will endeavor to answer your question. If it isn't, you may stop reading this post.

It looks like the PHP script in JW's post is a stand-alone script, to be run once against the old Fantastico-created Moodle installation to change the default character set of all the tables in the database to UTF-8. It does not change the data itself, and it does not change the default character set of the database itself. You can do the latter change using phpMyAdmin, or with an ALTER DATABASE query using any MySQL client program. As for the data, this will be a problem only for old text data that is not English. As his experience shows, new data entered after his procedure is executed should display correctly, which is as expected because all the default character sets are correct at that point.

RLE