Dev, Stage, and Prod: Same .htaccess config

Date: June 21, 2013
By: Dan Letsche
Comments: 3 comments
Permalink: Permalink

A small change to your .htaccess file should allow Pretty URLs to work (without .htaccess modifications) when you move your site from server to server.

In a previous post, I shared my love for code matching through all stages of development. If you're working on an Apache web server with C5 Pretty URLs enabled, the default .htaccess will likely need to change along the way. Here's the default code after a fresh install in my MAMP setup:

# -- concrete5 urls start --
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /concrete5tricks/httpdocs/
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME}/index.html !-f
RewriteCond %{REQUEST_FILENAME}/index.php !-f
RewriteRule . index.php [L]
</IfModule>
# -- concrete5 urls end --

The RewriteBase /concrete5tricks/httpdocs/ is a path specific to my local machine. This is because I make new sites in subdirectories instead of the web root. That path will need to change when I move it to our stage and production web servers. In an ideal world, we wouldn't need this code at all. And luckily (for us and hopefully you), we don't with a small modification to the RewriteRule.

# -- concrete5 urls start --
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME}/index.html !-f
RewriteCond %{REQUEST_FILENAME}/index.php !-f
RewriteRule ^(.*)$ index.php [L]
</IfModule>
# -- concrete5 urls end --

Viola/walah! A RewriteRule that doesn't need a RewriteBase.

A few words of caution

Rewrite rule work is complicated. I took a stab at explaining the details of this code in depth, but realized I'm not really qualified. We stumbled into it on a LemonStand project. It has worked for us in several setups. And since LemonStand is a pretty big eCommerce solution, I have a reasonable amount of confidence their code will work for you, too.

Please let us know if it works (or doesn't work) for you in the comments. And if you can poke holes in this solution or can help improve it, please let us know!

Comments

By hereNT on Jun 22nd, 2013

This is actually one of the reasons that I keep each site stand alone instead of as a subdomain. If live is www.site.com, then local is www.site.local. An entry in the hosts file, and it's no big deal to move between servers.

By jordan on Jun 22nd, 2013

@hereNT, that sounds like a good approach as well. Can you explain in a little more detail how exactly you set that up? (I'm guessing you have the site in a subdomain but then use the hosts file to map "www.site.local" to "localhost:8888/sites/mysubdomain/"? Or is there some other step required?)

However, I think for our specific situation the hosts file approach might not work as well because we also have a staging server that we put sites on for testing, and while those are usually at the top-level of a domain, sometimes subdomains are needed (and we don't want to have to explain to a client how to edit their hosts file).

By hereNT on Jun 24th, 2013

I have a shell script that creates the site, so like:

/websites/scripts/create_both.sh devsitename.werstnet.local

That will create these directories:

/websites/prod/www/devsitename.werstnet.local/html/
and
/websites/prod/logs/devsitename.werstnet.local/html/

It also makes the correct apache config and reboots the server.

The dev site will be the same name on the live server, only there it's in a home directory for the user account. I push and pull to that. When we go live, that's either renamed in the DNS and apache config, or we make a folder like /home/accountname/domains/www.site.com and use a shell script that grabs a particular git tag and pushes it to that folder.

Probably more complicated than most people would set up. For the sites at work, we set up the/home/ whatever stuff on the live site, then make the git repo and check in .gitignore. Then I run my local scripts, and clone into the html folder. Copy in a blank c5 instance and go.

I guess part of the reason I can do this is that I don't use a stand-alone LAMP stack. It's actually running as a full stack on my local machine with similar configuration as the live server. I add in a line somewhere that tells it to read .conf files in /websites/conf/apache/devsitename.werstnet.local.conf

Commenting has been disabled.