In my post Register_Globals Off and PHP4, I went through the steps I took to achieve setting register_globals = OFF in my server. I was quite excited with my success and everything seemed to work just fine. Obviously, 24 hours later, the problems started to surface.

Now, I’m still quite happy with the whole php.ini and symlink procedure, but the same way I wrote a post on the coolness of the process, I think it will be good to share the bad experiences, in case I can prevent or at least, warn, other people in the same situation.

So far, the most important “bad” consequence of symlinking the php.ini file in all the folders in the server has been its interaction with how Moodle handles the uploaded assignments of students.

When tutors went to grade their students uploades tasks, they found that most uploaded .odt, .doc, .ods, .xls, .pdf, … documents had been replaced by php.ini. And the original exercises seemed to have disappeared overnight.

Moodle uses the following folder system:
http://domain-name/moodle-installation/file.php/7/moddata/assignment/19/6/exercise

where, in this example,

• 7 is the course number
• 19 is the assignment number
• 6 would be the student’s number

And what Moodle does is once a student has uploaded an exercise, it will display the most recent file in that folder. As you can see in the following image, although the task of the student was uploaded on the 27th of September 2007, it is showing the task as php.ini (which was really created on the date of my previous post, January 17th):

To see and correct the problem, you must access the folder:
/moodle-installation/uploaddata/7/moddata/assignment/19/6/

As you can see in the next image (the images are linked to their full sizes so you can see them better):

in the folder for this student, for this particular assignment and course, besides the original file the student uploaded in September, there is the php.ini symlink (Filezilla identifies it as a folder).

As the php.ini symlink, saying that register_globals should be off, is only strictly needed in the folders where php scripts are executed from, it is not really necessary to have the symlink there. So you can “just” erase it. If you are using FileZilla, you might have the program ignore your request and complain that:

550 Can’t change directory to php.ini: Not a directory

Well, I knew that… Solution I have found: create a folder, move the php.ini symlink to that folder, and erase the folder with the php.ini inside. It seems to work. For completeness I will add that the FileZilla “Not a directory” complain, showed up both in a FileZilla run in Linux and in a Virtual Machine Windows XP Installation. It did not complain, however, in a FileZilla in a laptop running Windows XP.

Once the php.ini symlink is erased, Moodle will display the correct uploaded task again.

This process if you have loads of students/assignments, can be a bit of a pain. Obviously, a script could be written to erase the php.ini symlink from the assignment folders, or even better, the initial symlink script could be modified to exclude the Moodle folders where you don’t want the symlink created. Without either of these scripts, though

1. it would be better to run symlink, before any students enroll in the courses
2. if you have a server with a Moodle installation and want to install a 2nd one… I would be weary of running symlink again without some solution…

No, I do not have that solution, but if anybody does, I’m all ears. And if anybody finds him or herself in a similar situation, or has other problems with Moodle, do share your experiences with me! I might be able to help or learn from you

Related post(s)

• Inodes 28 weeks later… (2)
• The return of the inodes – tell me your package and I’ll tell you your inodes (6)
• Hostgator: pros and cons of their web hosting offer (17)
• Register_Globals Off and PHP4 (1)

So I learnt…

1. to set the register_globals off, one must place a “php.ini” file with the line register_globals = OFF in every folder of the server (thank you bergmann at the joomla forum!)
2. but this php.ini cannot just contain the register_globals line. The Computer guys at the University of Washington explain it really well in Using a php.ini File, basically saying: if the directory that calls a PHP script contains a php.ini file, that is the one (and only) from where the PHP configuration settings will be read, so you must first obtain the Web server’s php.ini file and add your own particular settings.
3. now, I don’t know about other Hosting services, but you cannot access the php.ini file in Hostgator through ftp directly. ronniead in a brilliant step by step post in an aMember Professional forum, explains how to use a script to both copy the original php.ini file of the Web server and add the extra user settings. This “Creating a custom php.ini file” script from B&T’s Tips & Scripts is easy to download and use, following ronniead instructions. Only one catch.. it did not work for me.
4. a bit more research and I found out that the function which appears in the script from B&T’s Tips & Scripts: file_put_contents() works with PHP5 but not with PHP4 which is what I have. Some googling for “file_put_contents() for PHP4″ brings up quite a few implementations of the PHP5 file_put_contents() function for PHP4. The one I settled for can be found in Stoyan Stefanov’s blog phpied.com (thanks Stoyan!)
5. So a bit of messing around with both the script and Stoyan’s implementation and I finally got the script to create a custom php.ini file for PHP4 working. And here comes the moment to give back to society.
6. You can either copy and paste the following code in a text editor, and then save as php_ini.php, or download the script from here: php_ini_PHP4.txt (right-click, Save Link As… and as it’s in .txt format, once downloaded, change the ending to .php).


<?php
// Put all the php.ini parameters you want to change below. One per line.
// Follow the example format $parm[] = "parameter = value";
$parm[] = "register_globals = Off";
$parm[] = "session.use_trans_sid = 0 ";

// full unix path - location of the default php.ini file at your host
// you can determine the location of the default file using phpinfo()
$defaultPath = '/usr/local/lib/php.ini';

// full unix path - location where you want your custom php.ini file
// if you don't know the full unix path, uncomment the next line and run the script
// echo getcwd() . "\n";
// you will see the full path (and probably an error message)
$customPath = "/home/user/public_html/php.ini";

// nothing should change below this line.
if (file_exists($defaultPath)) {
$contents = file_get_contents($defaultPath);
$contents .= "\n\n; USER MODIFIED PARAMETERS FOLLOW\n\n";
foreach ($parm as $value) $contents .= $value . " \n";

// code added for the script to work with PHP4
if (!function_exists('file_put_contents')) {
function file_put_contents($customPath,$contents) {
$f = @fopen($customPath, 'w');
if (!$f) {
return false;
} else {
$bytes = fwrite($f, $contents);
fclose($f);
return $bytes;
}
}
}
// end of added code for script to work with PHP4

if (file_put_contents($customPath,$contents)) {
if (chmod($customPath,0600)) $message = "The php.ini file has been modified and copied";
else $message = "Processing error - php.ini chmod failed";
} else {
$message = "Processing error - php.ini write failed";
}
} else {
$message = "Processing error - php.ini file not found";

}
echo $message;
?>


So there it is, the script to create the custom php.ini file for PHP4. Let me know how it goes!

Related post(s)

• Inodes 28 weeks later… (2)
• The return of the inodes – tell me your package and I’ll tell you your inodes (6)
• The attack of the inodes – how to find out your number (11)
• Hostgator: pros and cons of their web hosting offer (17)
• php.ini, symlink and moodle: I’m calling it the php.ini fiasco (0)