I love tweaking my workflow. I’m sure I’m not alone in that. When it comes to building things online, I’m always curious whether the way I’m doing things could be improved and better thought out. In the past I’ve shown how to set up a local WordPress development environment on a Mac. That tutorial is still solid, but I’ve made some additions to my setup this week that some of you may find interesting.
I have to credit my inspiration to seeing Ptah Dunbar and Andrew Nacin’s individual setups, very briefly, during their presentations at WordCamp Miami last weekend. They are both very accomplished developers, so of course my eyes are way open when they start navigating their desktops. Elements of their setup that I saw and liked I’ve used here, so thanks guys!
In this tutorial I will show you how to set up WordPress installs using MAMP in your Mac
/Sites directory, how to set up multiple localhost aliases, and briefly talk about the various versions of WordPress I keep on my Macs.
The first thing you will want to do, without a doubt, is use and understand the earlier tutorial explaining local WordPress installation on a Mac. This tutorial will assume that knowledge, as well as in part that very setup. After all, that’s what I started with too.
We want to accomplish a few key things:
- Instead of one local WordPress install at
wp.dev, we want multiple installs. In this case we’re going to set up
- Instead of storing our sites in the MAMP
/htdocsfolder (ugh) we’ll set all of our sites up in the Mac’s
/Sitesdirectory. Seems fitting, right?
- I’ll briefly show how I use SVN and Git in conjunction with my local setup.
Okay? So let’s do it.
Step 1: Add the development folders to Sites
First thing we want to do is add the various folders we will develop with, and set up WordPress within them. So head over to your Sites folder, which should be within your Mac’s home directory (along with Documents, Library, and Music).
There will likely be an
/images folder and
index.html stand-in there. Delete them, we won’t be using those. Now add a few folders of your own. Which folders you add exactly will be up to you. Here’s what I chose to add:
wp.dev: The latest stable version of WordPress. If I need to work out an idea, build a theme, or test something out, here’s where I’ll go.
wp.bleeding: This is for the bleeding edge version of WordPress. Nightly updates go in here, where I can see what’s coming and (hopefully some time, in my case) begin contributing code back to WordPress.
wp.3.0: This is just for WordPress 3.0, a previous version of WordPress. While I’m beginning with just one version back, in time I may add folders for versions going all the way back to the earliest.
bp.dev: I like to keep an eye on BuddyPress development, and prefer an install specifically for testing out new features and themes that use its capabilities. This is for the latest stable version of BuddyPress + WordPress.
gooroo.dev: This one is project specific, for me. GooRoo is the business that WPCandy is a part of, so I use this particular folder to keep a copy of my GooRoo WordPress install, for testing and adding new features. I’ll get more into the unique qualities of this one below.
So that’s it for me. The latest stable version of WordPress, the bleeding edge, old versions, BuddyPress, and project-specific installs. Like I said, what you choose to set up is up to you. Whatever you decide, add a folder for each install you plan on setting up. Then, download the various versions of WordPress you will need and add them to the appropriate folders. Don’t worry about setting each version up, we’ll get to that.
We have our folders in place. But we want to be able to access them using our aliases, and of course connect to MAMP databases. Let’s do those next.
Step 2: Set up localhost aliases to point to Sites folder
This will feel familiar if you’ve gone over the previous tutorial: pull open Terminal, it’s time to edit the hosts file. Tap in:
sudo nano /private/etc/hosts
And hit enter to pull open the hosts file. You may need to type in your Mac password here.
You likely already have added a line to your hosts file in the past, pointing your local IP number to an alias like
wp.dev. That’s what I had previously. Feel free to leave it if you have it, since we’re only going to be augmenting that line with a few more.
At the bottom of the list, make sure these are added:
127.0.0.1 wp.dev 127.0.0.1 wp.bleeding 127.0.0.1 wp.3.0 127.0.0.1 bp.dev 127.0.0.1 gooroo.dev
That last one you can skip, or make project-specific if it fits your needs. Now, what we’ve done is set up various aliases, all pointing to your local machine. This tells our Mac to not try and find a website when we type these into our browser, but to send these requests directly to your local machine. Awesome, right?
Problem is, they are all treated the same right now. We want each alias to go to a different place. So it’s time to dive a wee bit deeper. It’s time to edit our
Excited? Let’s go.
Step 3: Point the various aliases to the correct location
This particular step tripped me up for some time. Well, this step technically didn’t. It was the process of discovering that I needed this step that tripped me up. The steps are actually quite easy once you know them.
On a Mac, the
VirtualHost.conf file determines where your localhost aliases are sent to (among other things that we won’t be digging into here). So we’ll need to edit that file and give it new instructions. Using TextMate (or your text editor of choice) turn on “Show hidden files” and navigate to
Macintosh HD/private/etc/apache2/httpd.conf. Scroll down to around line 465 and look for these lines:
# Virtual hosts #Include /private/etc/apache2/extra/httpd-vhosts.conf
Take the pound sign away from the second line, uncommenting it to look like this:
# Virtual hosts Include /private/etc/apache2/extra/httpd-vhosts.conf
While you’re in that file, do a find on “PHP5”, which should bring you to around line 115 where you’ll see a line that looks like this:
#LoadModule php5_module libexec/apache2/libphp5.so
Go ahead and uncomment that line as well. We want PHP running.
Save and close that file. Now don’t get too excited: all we’ve done is told the computer to listen to our custom virtual hosts, which we’re about to add. Time to open another file.
In the same way, navigate to and open
Macintosh HD/private/etc/apache2/extra/httpd-vhosts.conf. You should see a file around 40 lines long, with a couple of virtual host entries. These are sample entries, so we’ll be replacing the data that’s there with our own and deleting them.
First, let’s be sure we have an elementary understanding of what we’re doing here.
<VirtualHost *:80> ServerAdmin [email protected] DocumentRoot "/usr/docs/dummy-host.example.com" ServerName dummy-host.example.com ServerAlias www.dummy-host.example.com ErrorLog "/private/var/log/apache2/dummy-host.example.com-error_log" CustomLog "/private/var/log/apache2/dummy-host.example.com-access_log" common </VirtualHost>
I won’t claim to understand all of what these lines mean. We’re standing very close to the shore of my understanding; much deeper and I’ll be lost. What I do know is that we will need only the
ServerName lines to achieve what we’re after. The VirtualHost entry for my wp.dev location, for instance, is:
<VirtualHost *:80> DocumentRoot "/Users/ryanlaptop/Sites/wp.dev" ServerName wp.dev </VirtualHost>
So what this is doing is taking the
ServerName and then delivering up the pages found at
DocumentRoot. Cool, right? Now let’s add a few more of those, one for each of our local WordPress installations. Mine now looks like this:
<VirtualHost *:80> DocumentRoot "/Users/ryanlaptop/Sites/wp.dev" ServerName wp.dev </VirtualHost> <VirtualHost *:80> DocumentRoot "/Users/ryanlaptop/Sites/wp.bleeding" ServerName wp.bleeding </VirtualHost> <VirtualHost *:80> DocumentRoot "/Users/ryanlaptop/Sites/wp.3.0" ServerName wp.3.0 </VirtualHost> <VirtualHost *:80> DocumentRoot "/Users/ryanlaptop/Sites/bp.dev" ServerName bp.dev </VirtualHost> <VirtualHost *:80> DocumentRoot "/Users/ryanlaptop/Sites/gooroo.dev" ServerName gooroo.dev </VirtualHost>
One more step complete. If all has gone well up to this point, you should be able to see the effect. Be sure to save this file, then visit System Preferences > Sharing and cycle Web Sharing. What I mean is, turn Web Sharing off and then back on again. This restarts Apache so that your computer will find these changes that you’ve made.
Assuming this has worked for you so far, you should be able to visit wp.dev or wp.bleeding, for instance, and see the correct folder. On to the next step!
Step 4: Connect to MAMP databases
So we have the aliases pointing to our Sites folder, now we just need to connect to our MAMP databases. Since you’re somewhat comfortable with MAMP, I won’t walk you through the process of creating a database within it. But when you are filling out the
config.php files within your new WordPress installs, in your Sites folder, you will want to make one key change. Rather than leaving the hostname to “localhost”, the default, you will want to use:
That will locate and connect to the correct MySQL databases.
Step 5: Step back and consider…
So let’s think about what we have here. We have various WordPress installs, relevant to our workflow, sitting in our Sites directory only a few keystrokes away with our special aliases. What more could we want?
I would recommend taking advantage of your new setup to learn about Subversion. You can use SVN, for instance, to pull down the latest stable, or nightly, versions of WordPress into your various folders. This would be a really quick way to keep everything up to date.
Or, you could do what I did with my project development folder. I set up a private Github repository for just my
/wp-content folder, within
gooroo.dev. So I can do all feature testing and development locally, then push those changes up, and pull them into the GooRoo server seamlessly.
You can obviously use whatever methods you like once you’re to this point, but I would encourage some sort of version control for your work, particularly if you, like me, work on a desktop computer at times and on a laptop at times. Using various version control systems with WordPress is a bit outside of this tutorial, though. Next time.
So it turns out there is one extra step that I overlooked when I put this together. I ran into it this morning when I went to set up a multisite network.
.htaccess rules aren’t enabled by default in the
/Sites folder. So let me save you (and future me) a few minutes and talk you through what you need to do.
There are two files that need to be edited. One is your
httpd.conf file (again) and then another, user-specific
So first open up httpd.conf again (see above for where that file is located) and search for the text “AllowOverride”. This will bring you to a comment block describing “what directives may be placed in
.htaccess files.” This is what you’re after. Change the line
AllowOverride Nonce to
AllowOverride All. Then save and close, we’re done with this one.
Next you’ll be editing your user-specific
.conf file. This will be named differently depending on your setup, but mine was located at:
So pull that one up, and make sure it looks like this:
<Directory "/Users/YOURUSERNAME/Sites/"> Options Indexes MultiViews FollowSymLinks AllowOverride All AuthConfig Order allow,deny Allow from all </Directory>
Save and close that file. Then restart Apache (by turning Web Sharing off and then back on again) and
.htaccess rules should work within your Sites directory.
Now I have a question for you: was this helpful? Have you ever wanted to do these things, or at least know how to do them in case you ever want to? It’s likely a very niche topic to cover, but after the number of hours I spent tracking down solutions at each step here, I thought it only right to share it with others. Hey, maybe it will save a few of you some time!
Oh, and one other question: how many different versions of WordPress do you have installed locally on your machine?