Firebelly Design

September 18, 2009 by Brandon Weiss

The Problem:

We have an existing WordPress site that needs a bit of a visual refresh. The design changes are large enough that it's not really something I could do quickly on the live site, and I don't want the site to look jacked up for the one or two days that I'm working on it.

The obvious solution is to duplicate the site and database, either on the server or locally, in order to create a development version that I can work on separately from the existing site. This is pretty much the gold standard, but it has the potential to be a huge hassle. For instance, what if the theme has absolute URLs, or all the URLs reference the root, e.g. <img src="/some-image.jpg" />? In theory that should be fine, but what if you're running Apache on OS X. When you put the site in your Sites folder, you'd have to access it at:

http://localhost/~brandon/website/

That forward slash in the URL to that image means that resource is expected at the root, which would be:

http://localhost/some-image.jpg

Which is of course not where the image is. A way around this would be to use virtual hosts, but this just adds yet another step, and one that many developers might not be comfortable with or know how to do.

Then there's also the database. WordPress stores the URL for the home page and the URL for the WordPress installation (often the same thing) in two places in the database, that you have to change when you move the site, and then have to remember to change when you move it back. If you're only making edits to the theme, then that's all you have to do. But what if the changes you're making require you to change WordPress's settings? Or add content? And what if the client needs to be adding content to the live site while you're making these changes? Now you can't just simply overwrite the live database with the development one because you'll overwrite the new content.

The amount of work to make what can be relatively straightforward updates to the site can quickly become huge, possibly even as much work as the updates themselves.

The Crafty Solution:

I can't remember when this was implemented, but as of version 2.8 (or 2.7?), when switching themes, it will actually show you a preview of the theme you clicked on, with the option to activate that theme. It didn't occur to me when I first saw it, but this means that there is some parameter you can add to the query string to render your site with any theme you want, without actually activating that theme.

You can see what I mean if you look at the URL in the status bar when you mouseover the screenshots of the default theme. The URL looks like:

http://your_domain.com/?preview=1&template=default&stylesheet=default&TB_iframe=true

You can just discard the &TB_iframe=true, that just tells WordPress to open the theme preview in the lightbox. Take what's left and open it up in a new tab. Now you're viewing your site, with the default theme, but it isn't activated. FTP into your server, go to the themes directory, and duplicate your custom theme's folder. Rename it to something like theme_name2. Then change the the URL in the tab to:

http://your_domain.com/?preview=1&template=theme_name2&stylesheet=theme_name2

Now you have a copy of your theme that you can make changes to, but no one else can see them. You can even click around in your site without losing the theme, because WordPress automatically appends the query string to all links, rather than overwriting it. Nifty, eh?

Comments