The installation process relies on performing PHP fopen requests on several URLs. These tests assume that the relevent URLs can be read via the webserver.

This is not a valid assumption in all working moodle installations. I have just installed moodle on a web hosting service that requires all executable scripts to be unreadable by the apache process. This arrangement appears to be a security measure implemented using the apache suexec module. The net effect is that install.php can be browsed correctly, but fopen on its url does not work.

It is relatively easy to get around this installation problem by removing the relevent tests from the PHP, since this has no effect on the later operation of the site. However, it does call the logic of doing these tests into question.

Checking that install.php can be read from the site URL is a poor test. For example, it would succeed if the installer specified the URL of the wrong moodle site (e.g. http://moodle.org/). Furthermore, it might fail incorrectly on carefully secured servers. Why not make it clear to the installer that the installation should be conducted via the URL intended for the live system and rely on the apache environment to get the URL right?

The check on admin/site.html might fail for similar reasons, though it serves a different purpose. Here, I would inclined to avoid the whole problem by changing the default location of the moodle admin directory in the distribution. Given that the few installers who need to correct the problem have to change the directory structure of the distribution in any case, it might be better to leave them to edit the config.php file by hand. I would imagine that the attempt to automate this part of the installation process creates more confusion than it avoids.

Felix