This recent article at Smashing Magazine discussed trends and challenges in deploying WordPress sites. The biggest issue cited by the article and the lengthy comments that follow is the issue of the database: because WordPress stores strings in the database that contain the site domain (including configuration options and asset paths), it’s hard to migrate content and config between dev, staging, and production environments. A bunch of possible solutions were offered up, including interconnectit/Search-Replace-DB, which I use fairly often and really like.
I was surprised, however, that no one talked about my preferred strategy, which is, in a way, the simplest: Dev, staging, and production should all have the same domain names. When you remove the need to change the domain, you make it much easier to deploy specific pieces of content, spin up new instances, etc.
Since all versions of a site have the same domain name – say, booneisthebomb.com – I use my local hosts file (/etc/hosts on *nix systems) to switch between instances. So I may have the following lines in /etc/hosts:
[code]
# Local development
# 127.0.0.1 booneisthebomb.com
# Staging site
# 123.456.789.0 booneisthebomb.com
[/code]
With these two lines commented out, going to booneisthebomb.com in a browser will use DNS for the lookup, which is to say it’ll go to the production site. Uncommenting one of the lines allows me to work on the local or staging site.
The biggest pitfall of this technique is that now there is no obvious way to tell your environments apart (and you definitely don’t want to mistake your production site for a dev site). My solution for this is to drop this file into wp-content/mu-plugins/. Then, in my environment file (which contains env-specific config, such as database connection info), I put a line like this:
[code language=”php”]
define( ‘ENV_TYPE’, ‘staging’ );
[/code]
Now, when I load up the staging site, it shows booneisthebomb.com in the URL bar, and the following box appears at the bottom of every page:
Nice! I often do the same thing, with a different process. This is a nice Firefox addon that can help you manage multiple hosts file. https://addons.mozilla.org/en-us/firefox/addon/change-hosts/
i use the same technique for my personal dev environment.. but the problems still remain when you want to set up a dev or staging for ‘early access’ or review for clients or product manager while keeping the production intact.. for a non techie, you are not going to tell them to change the hosts file.. that said I still can’t avoid the searchandreplace script (which i found very useful indeed).. thoughts?
yeah for sure simplicity is always the best path imo if you are using a mac theres a handy little app called gas mask that lets you swap out host files through the menu bar.
1. how do you manage DB changes.. say you made some changes to the site… which needed DB updates as well. moving them to staging and production is a pain right now for me.
2. my production is getting constant posts. how to avoid any conflict when deploying staging onto production without loosing any data?
Hi, Boone!
Setting up a new development environment and haven’t quite gotten this working.
In the env.php file in my local instance, I have this:
define( ‘ENV_TYPE’, ‘local’ );
In my /env-type-flag.php/ file in my local instance, I have this:
if ( defined( ‘ENV_TYPE’ ) && ‘local’ !== ENV_TYPE ) {
Unfortunately, this is not inserting the new ID/styling into the interface when I’ve changed my hosts file to see the local instance. (I have made configuration changes to the local instance, so I do know I’m looking at it.)
Any feedback welcome. And Happy New Year!
-Jay
Hi Jay – Happy new year to you too!
The first thing that pops to mind, given your comment about “/env-type-flag.php”, is to check whether this file is in the right place. It should be in
wp-content/mu-plugins– that way, WordPress’ll be sure to load it at the correct time.You can verify that the file itself is being loaded by putting some simple testing code right after the opening
<?php. Something like:die( 'working' );Hi,
I am trying to use the tweak described here. it really looks simple. I put the following line in my dev machine’s hosts file as described:
localhost/wp_ofekdigitali http://www.ofekdigitali.co.il
localhost/wp_ofekdigitali ofekdigitali.co.il
and this works fine. when I open the http://www.ofekdigitali.co.il I reach the local dev site. however, when I try to have the wp admin page and I open http://www.ofekdigitali.co.il/wp-login.php I reach the production site.
I have tried all kind of changes into hosts file but nothing worked. I still prefer this method over the search&replace one.
can anybody let me know what I missed.
thanks,
Danny
Hi Danny – It’s possible that your browser or OS is caching the host information. (Firefox is especially bad about this.) Try restarting your browser, doing a hard refresh (Shift + refresh), clearing your browser cache, or perhaps using an Incognito window.