Local, Dev, Staging, Production WordPress Workflow

Standard

I just wanted to share real quickly (because I’m pretty stoked) that after months (really, years) of development I finally have what I consider a professional workflow for WordPress development.

Below is a graphical representation of what takes place. But it breaks down to this (with Git, but can easily be accomplished with SVN as well):

  1. Pull down the Github repository
  2. Develop locally at local.example.com
  3. Commit changes and push to Github
  4. Push to Beanstalk if you want changes immediately pushed to dev.example.com
  5. Merge master to production and push to Github and Beanstalk
  6. The production branch is automatically deployed to staging
  7. Manually deploy to production from within Beanstalk

Notes:

  • Local and Dev share a database (but don’t have to)
  • Staging and Production share a database (but staging only has read access)

WordPress Workflow

 

You can fork the Denton Bible Church Website even if you just want to use this is a framework for your project.This is built off of Hybrid Enterprise which is a cleaner repository that accomplishes the same thing.

Finally, and sadly, I am still looking for the best multi-environment database solution. Ideally, a fourth environment would be used to make content changes against the latest production branch code and then changes would be selectively deployed to the production database. WordPress 3.6 almost had a great solution.

Settling the WordPress Absolute vs Relative URL Debate

Standard

WordPress is somewhat notorious for using absolute URLs in its linking to images and other posts within content. Many have argued for both sides.

It’s quite simple for me: relative URLs are easier for development, absolute URLs are smarter for live websites.

There’s a compromise to be had.

WordPress should add these shortcodes to core:

  • [home_url]
  • [uploads_directory_url]

This enables the user and the WordPress editor to insert links to other pages and media on the site while maintaining its given site domain and path. Developers would no longer have to find and replace all instances of the home URL when importing a local database to another environment.

When linking to another page on the site, WordPress could insert [home_url]?p=203, maintaining a lifetime of environment changes and domain moves without broken URLs.

Or, when linking to an image: [uploads_directory_url]/2013/01/example.jpg. Actually, I think linking to media needs to be completely rethought (i.e. [media id="100"] would render whatever image path was associated with that media ID. This would allow you to update an image in the media library and have the image update everywhere it exists on your site).

Update: I wrote a proof of concept plugin for media being inserted into posts with shortcodes to ensure portability.

Theme revisions and WordPress cache busting

Standard

When you enqueue CSS or JS files WordPress will append the current WordPress version as a parameter … an attempt at cache busting.

The process by which sites or servers serve content or HTML in such a manner as to minimize or prevent browsers or proxies from serving content from their cache. This forces the user or proxy to fetch a fresh copy for each request. Among other reasons, cache busting is used to provide a more accurate count of the number of requests from users.
- IAB

This type of parameter on your static resources is semi-useful. When you upgrade your version of WordPress returning visitors will be served with a fresh copy of your files. But what about all those changes you made to your style.css in between WordPress upgrades?

I use Beanstalk as my SVN repository host. Their coolest feature is automated and manual deployments. Simply commit your changes locally and watch them deploy to your staging/production server within seconds. No FTPing (and no accidents). Beanstalk puts a single file in the root directory of wherever you’re deploying to called .revision. It contains a single integer which is the latest revision that was deployed. You could manually update a file like this if you don’t use deployments.

So this function below grabs that revision number. You can then place this function in your enqueue call to replace the default WordPress version parameter with the latest SVN revision number … busting caches when they need to be.

WordPress network in multiple environments with a single database

Standard

Problem

I needed a way in my multisite setup to have multiple environments that shared the same database, but used different domains.

  • server1.example.com
  • server2.example.com
  • example.com

… each of those would point to the same database. This is easy to achieve in a standard WordPress install using define( 'WP_HOME', 'http://server1.example.com' ); and define( 'WP_SITEURL', 'http://server1.example.com' );.

When you add multisite to the mix it breaks.

The problem is that the wp_blogs table defines the domains too, so I needed a way to define them in the config file.

Solution

UPDATE: A more complete solution: https://github.com/developdaly/WordPress-Skeleton

Taking @chrisguitarguy‘s advice, I used sunrise.php to intercept the host and spoof it so that WordPress uses domain I customize to load the site content.

A really sweet WordPress development environment

Standard

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:\Windows\System32\drivers\etc (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:\wamp\bin\apache\Apache2.2.17\conf).

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:\wamp\www\example_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:\wamp\www\example_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:\wamp\www\example_com\wp-content\themes
  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.