1.8 'The rewrite test failed' error. - Resolved

During the set-up of version 1.8.4, in the requirements check, I receive the error:

The rewrite test failed and the most likely cause is that AllowOverride is not set to All for Elgg's directory. This prevents Apache from processing the .htaccess file which contains the rewrite rules.

A less likely cause is Apache is configured with an alias for your Elgg directory and you need to set the RewriteBase in your .htaccess. There are further instructions in the .htaccess file in your Elgg directory.

The same page also says that "Your server's PHP satisfies all of Elgg's requirements.".

In my Apache's httpd.conf, I have "AllowOverride All". Moreover, when I run the http://localhost:8080/ModRewriteTest/testing.php I get "mod_rewrite works". So, I conclude (rightly or wrongly) that I must have no problems with the rewrite.

As for RewriteBase, I should have no problems because I have elgg installed at the root of Apache (hence no subdomain). Yet, after the failure, I also changed it to "RewriteBase /" in .htaccess but it did not improve the situation.

I have:

Apache 2.2.10 on Windows Vista

PHP 5.2.17 (with safe_mode = Off) This is the VC6 x86 Thread Safe version.

MySQL 5.5.21

Elgg 1.8.4

I have tried to skip this requirement step by manipulating the URL to database check. This seems to have worked for some people as reported in the previous tech support notes. For me after "create admin account" step, I have received unrecoverable fatal error. Hence I decided that I have to be sure that the requirements step to work before I can investigate other causes.

I have looked around. Checked the config files over and over. Tried out the rewriteTest PHP program but to no avail. I must have done something wrong but just can not find it. I wonder if the real problem is something else than the reported one?

I appreciate any help on this...

Best Regards.

  • Where is the AllowOverride directive? It needs to be under a <Directory> section. What OS are you using and how did you install Apache?

  • Hello Brett,

    Thanks for your kind followup.

    - I have specified AllowOverride directive in Apache's httpd.conf in 3 places. I give them below in the stated order. If not propoerly set, would the modRewriteTest not fail?

    - My installation is on Microsoft Windows Vista Home Premium with Service Pack 2.

    - I am not sure what you mean by "how Apache was installed" but the Apache installation on this PC is relatively old. I had installed it to be used with previous Elgg installations (1.2, 1.5 & 1.7.x). BTW, I have deleted previous elgg mysql databases on this PC.

    - To be sure, during the requirements check ğhase I have disabled the firewall and virus checker.

    The order of the AllowOverride directives in httpd.conf is (BTW my elgg 1.8.4 directory is just below the Apache's htdocs directory):

    <Directory />
        Options FollowSymLinks
        AllowOverride All
        Order deny,allow
        Deny from all

    <Directory "C:/Program Files/Apache Software Foundation/Apache2.2/htdocs">

        # Possible values for the Options directive are "None", "All",
        # or any combination of:
        #   Indexes Includes FollowSymLinks SymLinksifOwnerMatch ExecCGI MultiViews
        # Note that "MultiViews" must be named *explicitly* --- "Options All"
        # doesn't give it to you.
        # The Options directive is both complicated and important.  Please see
        # http://httpd.apache.org/docs/2.2/mod/core.html#options
        # for more information.
        Options Indexes FollowSymLinks

        # AllowOverride controls what directives may be placed in .htaccess files.
        # It can be "All", "None", or any combination of the keywords:
        #   Options FileInfo AuthConfig Limit
        AllowOverride All

        # Controls who can get stuff from this server.
        Order allow,deny
        Allow from all


    <Directory "C:/Program Files/Apache Software Foundation/Apache2.2/cgi-bin">
        AllowOverride All
        Options None
        Order allow,deny
        Allow from all

    Thanks again for your kind followup!


  • I'm confused about where 1.8.4 actually is. You said in the first post it's in Apache's root, but you mention that means it has "no domain." Do you mean "no subdirectory?" In the post above, you mention that it's "just below the Apache's htdocs directory." Do you have something like C:\apache\htdocs\elgg-1.8.4?

    If so, the RewriteBase would be /elgg-1.8.4/

  • Hello Brett, thank you again for your follow-up.I really appreciate it.

    Sorry for my misunderstanding. Indeed my elgg is installed at:

    C:\Program Files\Apache Software Foundation\Apache2.2\htdocs\elgg-1.8.4

    and now I have changed in .htaccess the RewriteBase to:

    RewriteBase /elgg-1.8.4/

    I have restarted the Apache server, but got exactly the same error in the requirements check.

    As I could not think of anything else, I also tried out...

    RewriteBase /htdocs/elgg-1.8.4/ but got the same error.

    Best Regards.

  • I have installed elgg 1.7.1 and it installs and works without any problems (quick test).

    Could the problem be with 1.8.x versions or some dependency introduced on 1.8.4 that I am overlooking?

    Best Regards.

  • Hello,

    I have also tried out elgg 1.7.15 and and 1.8.3. Problem only occurs with 18.x versions.

    1.7.15 installs and works without any problems (quick test). I have noticed that in this version, I do not even have to set RewriteBase directory!

    1.8.3 gives the same error as 1.8.4. No matter what I do. Moreover the very original 1.9.x version gives exactly the same error.

    Could the problem be with 1.8.x versions or some dependency introduced on 1.8.x that I am overlooking? 

    Best Regards.

  • Elgg 1.8 is the only version of Elgg that actually performs the test. The test relies upon having curl installed or allow_url_fopen set to true. Can you confirm you have one or both of these?

  • In php.ini allow_url_fopen was set correctly but my PHP installation did not have curl installed.

    I am sorry for taking your time. Somehow I missed that curl was a requirement.

    Brett, thanks for your great help! I really appreciate it. THANK YOU.

  • The installer checks if curl exists and tries to fall back to native PHP methods. If it didn't work correctly with your installation it indicates a bug. Can you confirm that it DOES work as expected when curl is enabled?

  • I can confirm that, once curl is installed with PHP, the installation successfully passes the requirements check.

    Best Regards.

    note: without curl, when it failed, it took longer than 30 secs to execute the requirements check stage. I needed to increase max_execution_time = 180 in php.ini to get the results. After the installation of curl, the check was much faster (and displayed that all passed).