.htaccess modification works locally but not on production

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.

Read More

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.

Related posts

Leave a Reply

1 comment

  1. 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.