Wordpress Rewrite Rules cause 404 for all existing files
I've configured a LAMP setup on Ubuntu 20.04 using the Linode guide, then upgraded that to https and HTTP2 using Linode's guide here:
https://www.linode.com/docs/guides/how-to-configure-http-2-on-apache/
I've installed wordpress and thought I had everything working, but when I enabled wordpress' rewrite rules, all physical files on the server return 404.
Here are the rules:
RewriteEngine On
RewriteRule ^index.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
With these enabled, even a request for something like mysite.com/style.css returns a 404 (a request that has nothing to do with wordpress).
If I comment out the "RewriteEngine On" line, all the physical files are accessible again, but of course then wp is broken.
It seems clear the rules are redirecting everything to index.php despite the conditions to exclude files and directories.
Luckily this is a test server so my main site is live and unaffected, but I can't upgrade my live site until I figure this out. Please help!
4 Replies
Does it do the same if you add the RewriteBase and escape the dot in the second rewriterule?
Reference
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
Are there other rewrite rules in either the htaccess or web config? Have you tried setting the RewriteLog and RewriteLogLevel in the apache conf to troubleshoot the rewrites (not just assume what seems clear?)
Looks like this was caused because the rewrite rules were not in a <directory> block limiting their scope to /var/www/mysite.com</directory>
I had assumed setting the DocumentRoot in the VH block did the same thing. Sheesh, this was a tough one!
