I love WordPress. It’s a truly slick application, and I find myself using it increasingly for mediumweight projects. Like many coders, I’d really rather be paid to write a framework than to use one. Part of the skill of development, though, is to know when to work with an existing tool, and save your client infrastructure costs.
That said, WordPress does betray its roots as a run-in-place product. As Sebastian Bergmann has noted, its database is very tightly coupled with its code logic. It doesn’t lend itself well some development best practices. In particular it’s hard to unit test and to install across multiple servers.
At minimum I like to develop on a local machine before installing a working system into a production environment. At best, I would add a staging server and a continuous integration environment to this model.
To that end I’ve been playing with tools that might form the basis of an install, snapshot and test framework, and creating some quick and dirty scripts to handle some basic jobs. One of these is snapshotting. Ideally, moving content between development and production servers would simply work because content and configuration would be separated. Here in the real world, WordPress stores its URL in its options table (option name: siteurl). Worse, it adds the site URL to page and post content — even if you use the link to existing content option when creating a link. This means that content beds in to a particular domain and that moving it to a new server for development or testing results in broken links and compromised functionality.
At this point in an earlier version of this post I presented a dirty little shell script which could snapshot a WordPress instance in such a way that it could be loaded into a new server context from the commandline, or from a Phing build file. I reckoned without some weirdness, however. It seems that in some instances the site URL is embedded in serialised strings. Serialisation will break if you naively change chunks of it. So it’s back to the drawing board for my crude commandline script.
In fact, there’s is a nice little tool that will get the job done in a browser context — the snappily named Search Replace DB. I am looking to build a commandline tool though that can be run from Phing and ultimately as part of a continuous integration platform such as Jenkins. The code in Search Replace DB is released under the WTFPL licence — so I can freely adapt the very useful central routine for my own purposes and save myself a bunch of discovery.
I’ve also got my eye on the luscious-looking wp-cli — a tool which allows you to perform many common WordPress tasks from the commandline. It looks like it’s hightly extensible it might be the best starting point for any new functions.
So the objective. For a single site install, via a Phing interface:
- Snapshot blog state (database, uploads etc)
- Restore blog state (find/changing siteurl along the way)
- Load themes and plugins for development and testing
- Update the WordPress version
- Run unit tests
- Run Selenium tests
I’ll bet that there’s something along these lines already out there.. if you know about it, then leave a message! In the meantime, I’ll be working to cobble something together myself. I’ll make it available if it’s halfway decent.
