Categories
WordPress

A really sweet WordPress development environment

I’m always trying to figure out a more efficient way to do development. I’ve tried more than a dozen different applications to develop in: Notepad, Notepad++, Dreamweaver, FrontPage, Aptana, and so on.

Whichever application you end up using it still only solves some of the problems. So this post will divulge my development environment for some projects. This isn’t the ‘end all, be all’ and it will evolve, but its evolved to this point over years and years and I finally have something I really enjoy.

Most of the content in this tutorial is applicable to any operating system, but it is written for Windows users and some parts will need to be amended for Mac users.

Table of Contents

Local Environment

I used to hate local development. It makes sharing your work so much more difficult, configuring a local server isn’t always easy, and there’s so many things to change once you move to production. Not anymore.

Install Apache, MySQL, and PHP

First of all, for any local development you’ll need WAMP, XAMPP, or MAMP. These set up an environment that allows you to run a website on your machine. I use WAMP on a Windows machine. All of these programs will install Apache, MySQL, and PHP along with some helper applications like phpMyAdmin.

Choose which one you like the most and install.

Configure MySQL

After you’ve installed your server environment you need to create a database for your WordPress site.

Open phpMyAdmin or another bundled database application. From the homepage of phpMyAdmin you’ll be able to easily type the name of a new database and save it.

Configure Apache

There are two steps to allowing your computer to act as the server for a website using a real domain. Our intention is to setup example.com to run off of the local computer (rather than from the internet).

Use your real domain

One of the most annoying things about local development is that most tutorials have you setup http://localyourdomin/
. That means when its time for production you have to find and replace all occurrences of that in your database and files. Lots of room for error there. So let’s just use your real domain: http://example.com (obviously, replace all instances of example.com with your domain).

1. Edit your HOSTS file

In Windows, use Notepad to open C:WindowsSystem32driversetc (be sure to “Run as administrator”) .

Add to the bottom of the file:

# 127.0.0.1 example.com #local
# 123.4.5.6 example.com #production
  • The # (pound sign) denotes a comment. So everything following the pound sign is ignored. So this example won’t change anything once you add it to the file.
  • 127.0.0.1 is the IP address of your machine. Replace 123.4.5.6 with the IP address of your remote server (the one your website is hosted on).
  • #localand #production are just comments to signify which server goes where.

Now, if you un-comment the local server when you try going to example.com your browser will look to your local machine.

NOTE: You can get browser extensions to quickly switch between hosts. Since I do most of my development in Firefox I use HostAdmin.

2. Edit Apache’s httpd.conf

Your computer now knows that example.com is hosted on your machine, but your server needs to know where your local website is located.

Open up httpd.conf (varies depending on which software you installed, but in WAMP its in C:wampbinapacheApache2.2.17conf).

Add to the bottom of the file:

<VirtualHost 127.0.0.1>
 ServerName example.com
 DocumentRoot "C:/wamp/www/example_com"
 ServerAdmin [email protected]

<Directory C:/wamp/www/example_com>
 Order Allow,Deny
 Allow from all
 </Directory>
 </VirtualHost>

Save.

Install WordPress

Download the latest version of WordPress, unzip it, and put its contents intoC:wampwwwexample_com.

Go to example.com and you should see the WordPress installation screen. Follow the wizard. The database name is the one you created earlier. The username (by default) is “root” and the password is blank (null).

Code Editor

You may use Notepad to do all of your development. Pat yourself on the back; you’re hardcore. You’re also missing out.

Finding the right software is hard. Some are ugly, featureless, slow, or dead. A couple years ago I found Aptana. Its an IDE, which basically means that it does way more than edit files.

What does an IDE (and specifically Aptana) offer?

  • Remote FTP/SFTP file editing. Upload/download of files.
  • Code completion: PHP, CSS, HTML and more.
  • Real-time error/warning checking against W3C standards.
  • Local projects

After you install Aptana you can create a project.

  1. Go to “New” → “Project…”
  2. Name your project (maybe example.com)
  3. Uncheck “Use default location”.
  4. Browse to and choose C:wampwwwexample_com
  5. Click Finish

Your project now contains all WordPress core files, themes, and plugins. Use the project explorer to view all of your files

You can also use Aptana to connect to FTP and remotely edit files. A better method may be to edit locally and use Aptana’s synchronization features to push the files live after you’ve tested locally.

Source Control

At this point you don’t need to go any further unless you’re interested in using source control. Everything we’ve done so far is good enough for a local environment and/or remote editing. But you can make things even beefier with source control…

Source control can be confusing and I’m not going to explain everything here. Instead I’m just going to layout how to use various tools to interact with SVN.

For those a little unfamiliar though, here’s some benefits of source control:

  • History of changes
  • Backup of code
  • Teams can work on the same code simultaneously

I use a few different repository systems, but my favorite is Beanstalk. A single feature makes Beanstalk amazing: deployment. More on this in a bit.

SVN setup

Repository structure is important to get right. There’s lots of ways to do it and you probably will need to tailor it to your project’s needs. But imagine you’re developing several themes and plugins. This is the organization I’m using for just that:


/
    /themes/
        /my-theme/
            /branches/
            /tags/
            /trunk/
                index.php
                style.css
    /plugins/
        /my-plugin/
            /branches/
            /tags/
            /trunk/
                my-plugin.php

This organization allows you to add multiple themes and plugins and keep them each separate from each other and allows you to tag a new version of the theme/plugin.

Create that structure in Beanstalk or whichever solution you’re using. Add a theme or plugin directory and put some files in its trunk directory.

Checkout locally

Now we want to checkout our theme/plugin locally and have it sit right inside the local WordPress installation we already setup.

  1. Install TortoiseSVN
    1. This allows you to do SVN actions within the Windows file system
  2. You’ll need to restart after you install. So tweet this post so you know how to get back to it 😉
  3. Navigate to C:wampwwwexample_comwp-contentthemes
  4. Add a new directory with the name of your theme, my-theme
  5. Right click my-themeand choose “SVN Checkout…”
  6. Enter the URL of your repository
  7. Make sure your Checkout directory is the one you right clicked on
  8. Click OK

You’ll probably have to enter your SVN credentials as well.

Now you can login to your local WordPress and your theme/plugin will be visible (assuming you have the necessary files).

You can edit files and view the changes locally, then once you’re satisfied with your work you can commit it to the repository.

Deployment

Here’s the fun part (and we’re almost finished). Like I said at the start, it annoys me to have to manually upload and overwrite files via FTP. Its just an extra step and more room for error.

Deployment works like file syncing. Beanstalk keeps a revision record and puts it on each of your servers. This file tells it which other files you’ve made changes to, added, or deleted. Then it scours your server and syncs the files by making it identical to latest revision in your repository.

Using Beanstalk you can automatically deploy all commits to your remote server. I don’t suggest doing this exactly.

Staging server

Use Beanstalk to setup an automatic deployment every time you commit to your staging server. Pushing all of your commits to a staging server makes your latest revisions remotely accessible. This is handy for showing clients or for non-developers to see a working example (i.e. quality assurance, marketing, etc.). Its also a good idea to keep the staging server environment identical (or very similar) to what you’ll be pushing it to on production.

Production server

Finally this is your 100% publicly accessible live website. I use Beanstalk to manually deploy to this environment. Automatic deployment to production may work for you (especially on smaller, less critical sites) but you’ll need to be ready to roll back in the event of any problems.

After staging looks and works perfectly then I use a few clicks of the mouse inside of Beanstalk to manually deploy the latest version. Within seconds I’m confident that all production files are up to date.

Roll back

In the case that something goes horribly wrong, just manually deploy the previous revision. Its so easy!

Show Me Yours

I’d love to know how you have your environments setup. I’m willing and ready to improve mine. Streamlining the process just means I can spend more time paying attention to better code.

Leave a Reply

Your email address will not be published. Required fields are marked *