Tag Archives: version control

Using a hosts file for easy management of dev, staging, and production WordPress sites

· 8 Replies

This recent article at Smashing Magazine discussed trends and challenges in deploying WordPress sites. The biggest issue cited by the article and the lengthy comments that follow is the issue of the database: because WordPress stores strings in the database that contain the site domain (including configuration options and asset paths), it’s hard to migrate content and config between dev, staging, and production environments. A bunch of possible solutions were offered up, including interconnectit/Search-Replace-DB, which I use fairly often and really like.

I was surprised, however, that no one talked about my preferred strategy, which is, in a way, the simplest: Dev, staging, and production should all have the same domain names. When you remove the need to change the domain, you make it much easier to deploy specific pieces of content, spin up new instances, etc.

Since all versions of a site have the same domain name – say, booneisthebomb.com – I use my local hosts file (/etc/hosts on *nix systems) to switch between instances. So I may have the following lines in /etc/hosts:

[code]
# Local development
# 127.0.0.1 booneisthebomb.com

# Staging site
# 123.456.789.0 booneisthebomb.com
[/code]

With these two lines commented out, going to booneisthebomb.com in a browser will use DNS for the lookup, which is to say it’ll go to the production site. Uncommenting one of the lines allows me to work on the local or staging site.

The biggest pitfall of this technique is that now there is no obvious way to tell your environments apart (and you definitely don’t want to mistake your production site for a dev site). My solution for this is to drop this file into wp-content/mu-plugins/. Then, in my environment file (which contains env-specific config, such as database connection info), I put a line like this:

[code language=”php”]
define( ‘ENV_TYPE’, ‘staging’ );
[/code]

Now, when I load up the staging site, it shows booneisthebomb.com in the URL bar, and the following box appears at the bottom of every page:

env-type-flag

WordPress developers: Write to the filesystem the right way

· Leave a reply

Many WordPress plugins and themes need to write to the filesystem, to cache data, create a debug log, download libraries that for one reason or another aren’t distributed with the main package, etc. And many of these plugins do it wrong, by writing (or attempting to write) to their own plugin/theme directories. This is a bad idea for a couple of reasons:

  • If you use version control to deploy/manage a site, you probably have configured your repo to ignore the content of dynamic directories like wp-content/uploads. Obviously, you don’t want to ignore plugin and theme directories. When Git etc detects your newly created files, it wreaks all sorts of havoc with workflow and, depending on the content of the files and the carelessness of the deployment manager, poses the risk of losing user content or endangering sensitive data.
  • Some people have their file permissions set very conservatively, so that the webserver user doesn’t have write access to wp-content/plugins or wp-content/themes. So plugins that attempt to write to those directories often break altogether.

The good news is that every properly-configured WordPress installation will have at least one location where the webserver can write, and which is highly likely to be ignored by all version control setups: the upload directory wp-content/uploads. The situation is more complicated on Multisite, where each site has its own subdirectory of wp-content/blogs.dir. Happily, there’s an easy way to concatenate an upload path that’ll work across installations:

[code language=”php”]
$uploads = wp_upload_dir();
$my_upload_dir = $uploads[‘basedir’] . ‘/yourplugindir’;
[/code]

WordPress has a very slick filesystem class that’ll help you if you really do need to write to a plugin or theme directory. But 99% of the time, you don’t. Please keep your stuff out of the codebase.

Musings on Git and Github

· 2 Replies

About a year and a half ago, I started moving all my personal and professional software development to Git and Github. Here are a few thoughts on what it’s meant for me as a developer.

Originally, the primary impetus for the change was that, as version control software, Git is so much better than Subversion. But in the last few months, the value of Github (the site, as opposed to Git the software) has become increasingly evident and important. As developers (in the WordPress world, especially) have taken more and more to Git, and as folks in general have become more familiar with Github, the value of Github’s social model to my work has increased by a huge amount. Between private and public repositories, client work and open source projects, I collaborate with dozens more people today than I did at this time last year. Some of this collaboration is planned ahead of time, and so maybe isn’t so notable. But increasingly, it’s unexpected and unsolicited – forked repos, pull requests, bug reports and patches.

Probably many of these changes are incidental, and are unrelated to version control at all. But I like to think that the mechanisms of Git – cheap branching, sophisticated merging – and the design of Github – activity streams, easy forking – have played a role. Using Github has changed, and continues to change, my development practices, by making me think more about audience and reuse (notions that are familiar to teachers of writing), encouraging the “release early and often” mantra (since all my stuff is public anyway more or less as soon as I write it), and orienting me toward collaboration by default, rather than solo coding. All these changes are highly laudable, leading to better product, and making my work more fun.

If you are an open-source developer, working in locked-up or practically invisible repositories (or, heaven forbid, not under version control at all), do yourself a favor and get acquainted with Git and Github. The benefits are potentially transformative to the way you approach your work.