March 29 2010

Tracking and Staging Wordpress Changes

by Brian Dunagan

Making template/theme changes to a live blog is a bit frustrating. While mucking around with CSS or a theme header, I occasionally render this blog completely illegible or obviously broken, then I scramble to revert my changes, hoping I remember the original code correctly. Editing is a pain without source control or a staging process and very different from app development. Too different. So, I figured out how to track all my Wordpress changes with git and stage them on a subdomain on DreamHost.

Tracking Changes

I’m using git and GitHub, but any scm would be fine. I’ll run through the steps here. (Keep in mind I use Wordpress’s update system for version and plugin updates; I just want to track my own changes.)

1. Removed unused themes and plugins to reduce installation size to 25MB (du -h)
2. Created a private repo on GitHub
3. Setup git in blog's root directory on DreamHost:

   git init
   # Didn't bother ignoring any files.
   git add .
   git commit -m "current state of blog"
   git remote add origin git@github.com:username/myblog.git
   git push origin master

4. Edited the CSS file using Wordpress's editor then listed the changes (git status) and diff'd the changed file using git (git diff style.css)
5. Decided my edits didn't look good on the live blog and reverted them (git checkout style.css or git reset HEAD --hard)
6. Ran mysqldump then gzip on the blog db and added it to git also
7. Updated .htaccess to hide the new .git directory (DreamHost): RedirectMatch 403 /\..*$ </ol> Seeing the changed files in git is fantastic, and at this point, I wonder how I got by for so long without versioning my Wordpress changes. But tracking changes isn't enough. Staging Changes Now, I can easily revert horrible template changes, but anyone hitting the blog during that time will still see it. It reminds me of how the early Facebook team used to directly edit the HTML on the production site when they were adding features. Debugging changes on a live site is annoying and unnecessary. Instead, just use a subdomain. Here are my steps:
   1. Created a subdomain on DreamHost for the staging area and assigned it a private IP/enabled SSL (I require SSL for administration)
   2. Pulled the current repo in that new subdomain's root directory on DreamHost:

      git init
      git remote add origin git@github.com:username/myblog.git
      git pull origin master

   3. Pointed this instance of Wordpress to the new subdomain by adding WP_HOME and WP_SITEURL in /wp-config.php according to Wordpress's "Changing The Site URL" page (I want to use the same database so I didn't change those entries)
   4. Waited a couple hours while the DNS changes propagated for the new subdomain
   5. Logged into Wordpress on the subdomain and changed a couple lines of CSS
   6. Checked out the result on the subdomain and committed it to GitHub
   7. Pushed the commit to GitHub and pulled it down in the live blog
   8. Verified the change on the live blog </ol> Staging changes is so much more comforting. Before, I wondered how many visitors hit my site mid-change (which sometimes took hours) and left annoyed. At least now I can think, "Actually, I designed it that way intentionally..."