.htaccess for apache 2.2 doesn't work on apache 2.4 vagrant development box

Question

The .htaccess file below works fine for various hosted websites, all on apache 2.2, but the test environment and new websites on cloud servers are running on apache 2.4.

The problem is that access to a php file no longer works unless the full filename including .php is added e.g. www.example.com/about.php rather than www.example.com/about

Any help with the below much appreciated - ideally with a .htaccess that works with both 2.2 and 2.4 apache.

Options -Indexes +multiviews
RewriteEngine On
RewriteBase /

ErrorDocument 404 /404.php
#ErrorDocument 500 /500.php

# Add www.
RewriteCond %{HTTP_HOST} !^www\.
#RewriteRule ^(.*)$ http://www.%{HTTP_HOST}/$1 [R=301,L]

# Remove .php
#RewriteCond %{THE_REQUEST} ^GET\ (.*)\.php\ HTTP
#RewriteRule (.*)\.php$ $1 [R=301]

# remove index
RewriteRule (.*)/index$ $1/ [R=301]

# remove slash if not directory
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} /$
RewriteRule (.*)/ $1 [R=301]

# add .php to access file, but don't redirect
RewriteCond %{REQUEST_FILENAME}.php -f
RewriteCond %{REQUEST_URI} !/$
RewriteRule (.*) $1\.php [L]

---edit---

Below is the apache 2.4 000-default.conf which is used for the VirtualHost

php_value auto_prepend_file /vagrant/www/fixdocroot.php

<VirtualHost *:80>
   ServerName dev.dev
   ServerAlias *.dev
   UseCanonicalName Off

   VirtualDocumentRoot "/vagrant/www/%-2+/public_html"

   <Directory /vagrant/www>
       AllowOverride All
       Require all granted
   </Directory>
</VirtualHost>

---further edit --- Apache error log is as follows:

[Mon Jan 11 09:26:35.751982 2016] [core:notice] [pid 1812] AH00094: Command line: '/usr/sbin/apache2'
[Mon Jan 11 09:44:22.816423 2016] [:error] [pid 1892] [client 192.168.33.1:49762] PHP Deprecated:  Automatically populating $HTTP_RAW_POST_DATA is deprecated and will be removed in a future version. To avoid this warning set 'always_populate_raw_post_data' to '-1' in php.ini and use the php://input stream instead. in Unknown on line 0, referer: http://speechlink-primary.dev/infant/assessment/start/15
[client 192.168.33.1:49804] AH00687: Negotiation: discovered file(s) matching request: /vagrant/www/domainname/public_html/page-name (None could be negotiated).

Answer 1

There are a few things that can wrong when upgrading from apache 2.2 to 2.4

Forgetting to enable modules

Sometimes, you can forget to enable the used modules on your new server, this is solved easily by running the apache command a2enmod <module>, you are using the module rewrite in you .htaccess and this can be activated by a2enmod rewrite.

The configuration parameters you have used are renamed

In apache 2.4, there are some changes in the names of configuration parameters.

According to the apache update notes, the following things are changed:

AllowOverride now defaults to None.

See @Gal's answer for more information about this change.

PhP may not be installed/enabled at the new server

While I doubt this may be the case, I included it, since this may be a problem for other people.

Check if php is properly installed by making a phpinfo() file, this file contains <?PHP phpinfo() and should be giving a proper php info out when run.

Php can be activated on apache with: a2enmod php5 or a2enmod php7

RewriteRule logging

If the rewrite rules keep failing, a quick test may be enabling the rewrite rule logs, these can be enabled using the default apache "LogLevel", to prevent making our whole apache emit debug messages, while still getting debug messages from the rewrite modules, you need to prefix the latter using its name. For example:

LogLevel alert rewrite:trace3

This will turn on the rewrite level debug messages to trace3, you can go up to lvl trace8.

The debug messages of the rewrite module can be read as follows:

[rewrite:trace2][rid#7f9c446360a0/initial] init rewrite engine with requested uri / - This means that the rewrite engine has started for a url

[rewrite:trace3][rid#7f9c446360a0/initial] applying pattern '^.*$' to uri '/' - This means that a RewriteRule has worked

[rewrite:trace4][rid#7f9c446360a0/initial] RewriteCond: input='/' pattern='^/?projects/old-projects/' => not-matched - This means that a RewriteCond hasn't matched.

[rewrite:trace4][rid#7f9c446360a0/initial] RewriteCond: input='/' pattern='^/?' => matched - This means that a RewriteCond has matched.

[rewrite:trace2][rid#7f9c446360a0/initial] rewrite '/' -> '/index.html' - A RewriteRule has internally/externally redirected you to another page

The best way to read the debug log files is by using a text editor that doesn't wrap the lines, for example less -R on linux or Notepad on Windows.

Answer 2

The first line of the .htaccess file seems to be the problem:

Options -Indexes +multiviews

From the Apache documentation:

The effect of MultiViews is as follows: if the server receives a request for /some/dir/foo, if /some/dir has MultiViews enabled, and /some/dir/foo does not exist, then the server reads the directory looking for files named foo.*, and effectively fakes up a type map which names all those files, assigning them the same media types and content-encodings it would have if the client had asked for one of them by name. It then chooses the best match to the client's requirements.

I believe this is interfering with the RewriteRules - in my testing on an Apache 2.4 vagrant box, removing the +multiviews from that line seems to have solved the problem.