We have some modifications to WordPress’s .htaccess file which another app to run in the same directory (see below). As you can see, we insert a few RewriteCond that tell WP rewrites to ignore specific requests to our other app’s controllers.
We just added one more rule (it’s commented below), and it works exactly as expected on two local development environments (one MAMP the other XAMP). BUt when we push it to our production server, the new rule doesn’t seem to have any effect. Instead of being able to navigate to files in the new directory (/app/resumes/stamped/123.pdf), we see the WordPress “Well this is embarrassing” message, indicating that the request is still being routed through WordPress.
mod_rewrite is definitely working and AllowOverride All
is set in production. What else can we check to get this to work in production?
For me the strangest part is that the OTHER RewriteCond
DO work, so I’m really puzzled about why just this one new line should behave so differently in the production environment.
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
###This is the new rule
RewriteCond %{REQUEST_URI} !/app/resumes/stamped/
RewriteCond %{REQUEST_URI} !^/admin
RewriteCond %{REQUEST_URI} !^/pages
RewriteCond %{REQUEST_URI} !^/tests
RewriteCond %{REQUEST_URI} !^/users
RewriteCond %{REQUEST_URI} !^/css/
RewriteCond %{REQUEST_URI} !^/js/
RewriteCond %{REQUEST_URI} !^/img/
RewriteRule . /index.php [L]
</IfModule>
# END WordPress
Update
This is what lives in the .htaccess in /app
RewriteEngine on
RewriteBase /app/
#This is new too
RewriteCond %{REQUEST_URI} ^/resumes/stamped/
RewriteRule (.*) webroot/$1 [L]
Update 2
We just learned that requests sent WITH the username/password authorization (I’m using Chromes’s REST extension to add the necessary headers manually) required by the /stamped directory’s .htaccess file DO succeed. In other words, it basically IS working but we can’t tell because we’re expecting it to prompt for the username / password since it does this on all the other servers. So the real question is why does the authorization prompt (or lack thereof) land us on WordPress’s 404 page on this server?
Update 3
This is the htaccess file in …/stamped
AuthType Basic
AuthName "restricted area"
AuthUserFile /home/username/public_html/.htpasswd
require valid-user
The path to the .htpasswd file differs from dev to production, of course.
There is an issue on Apache servers with DirectAdmin, PHP-FPM and FastCGI that manifests in weird .htaccess behavior. I once spent an evening trying to figure it out: Only .php files loop with .htaccess redirect The above might or might not apply to you, but if everything’s ok on a local server but not on a production server, I’d look for the problem there.