Check for Apache mod_rewrite

[totten]

If you try to use Drupal without mod_rewrite, the site will nominally display, but you won't be able to login or do anything substantive. We should either:

• Auto-enable it (amp config)
• Test for mod_rewrite and warn if disabled (amp test)

[totten]

I took a stab to see if auto-enabling could be done simply, e.g. by including this in ~/.amp/apache.d:

<IfModule !rewrite_module>
  LoadModule rewrite_module modules/mod_rewrite.so
</IfModule>

Unfortunately, this doesn't work in Debian/Ubuntu. They use this non-portable statement:

LoadModule rewrite_module /usr/lib/apache2/modules/mod_rewrite.so

The best bet is probably to search for a few commands (apachectl, apache2ctl, a2enmod) and run something like:

apache2ctl -t -D DUMP_MODULES

[openbrian]

Yeah, i was just burned by this. How about a phpinfo() type of approach? Or maybe this: http://php.net/manual/en/function.apache-get-modules.php.

Please advise and i'll work on it.

For posterity: One result of this is that Drupal login fails.

[totten]

That function is probably a little sensitive to operating environment -- e.g. on MAMP 3.x, confirmed to work with mod_php5 but not work on php-cli. (Haven't tested fastcgi/fpm - but guessing they wouldn't work.)

Maybe one could some kind of patch to the canary app (amp test; TestCommand, canary.php) which runs in httpd to make it report a warning if it's not available.

[openbrian]

I agree this must be a check/warning. Enabling mod_rewrite on debian/ubuntu would require "sudo a2enmod rewrite".

New idea. Do you want amp to be opinionated like this and require rewrite be enabled? Or would you rather make this a config:set parameter?

[totten]

I'd vote for fairly opinionated -- although I agree it may be a little too tight to require mod_rewrite per se.

If we were really pushing it, I'd prefer to have a behavioral test which is independent of the httpd type. The behavioral test basically checks: "Does httpd correctly pass requests to the PHP front-controller? If not, display common tips for fixing that."

To do a behavioral test, we could update the canary app to include its own .htaccess (with a rewrite rule) -- when running amp test, the request would no longer bet for http://localhost:7979/canary.php -- it would be http://localhost:7979/canary/clean/url/example