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)