As many of bloggers are no doubt aware, a major update to WordPress was released this week. I like many others, eagerly upgraded my installation to take advantage of many new long-awaited features (particularly on the admin/management end). However for many, upgrading WP means downloading the latest .zip archive, unpacking on one’s local disk, then uploading the entire contents of the unpacked archive (see the irony here?) through an [S]FTP client, wondering why so many micro-tiny files would take soooo long to transfer (it’s easily explainable, but that’s for another discussion). During this protracted upload, one’s WP installation can become instantly unstable as files are being upgraded in place, creating a real-time oil-and-water mix of two different versions.
So what do I do? Well, obviously not the above. With shell access to my hosting account (for Windows users, think DOS command prompt), up until a few months ago, I would get the new version as usual, only I’d upload the .zip file (or in my case, the .tar.gz “tarball”), unpack it on the server, and replace the installation in a couple of seconds; the time to upload (which would be vastly shorter because it would be a compressed, continuous file) would have no bearing on the “out of sync” problem above, because I’d unpack the files in a few seconds. This is a tried-and-true workflow that nobody could argue with in terms of simplicity and speed.
However, there is an even more elegant method that I started utilizing as soon as I found out WP supported a version control utility called Subversion. Version control is used in the software industry to track changes on various files so one can roll back to a previous version. People do this all the time with, say, a document in Word by saving multiple copies, but imagine 50 developers all making changes simultaneously to a source tree of hundreds of files. You have to be able to track changes so that you can fix what breaks while not discarding what got better. Anyway, I don’t want to get overly technical, but I wanted to give a slightly better understanding of what Subversion is more than the simple statements in the video. Speaking of which, here it is:
Cool, eh? It’s important to know that the above was recorded in absolute real-time, no edits, and that it was really, truly my live system. Aside from the file and database backups before recording, you saw my real, unadulterated upgrade process (while I wasn’t worried having done this many times, the fact that it was done on a Sunday afternoon when traffic was low wasn’t an accident, either ). Once your svn tree is in place, tracking updates large and small really is that easy. There are no big installation files to download or upload (the `svn’ client gets the individual files it needs, but it’s a fast server-to-server transfer) and unlike dropping a new installation on top of the old one, the old, deprecated files are cleaned away. Note that this is the workflow for an existing subversion WP repository; how to convert a “standard” (ie, uploaded) WP install to a subversion-enabled one is the topic for a future post (if there’s interest).
Anyway, I this helped, or at least inspired you to look into checking with your hosting provider to enable shell access if you have it. Please, please, give me feedback on this because I have lots of ideas on similar videos on WP ginsu outside of the web dashboard, most notably using MySQL queries (the database that powers 99% of WP instances) and the like. I admit command-line management isn’t for everyone, but for those willing to start adding to their toolkit, it opens up a limitless world of possibilities.
P.S. I didn’t make this clear, but this was created mainly for friends and readers in the med blogging world who are not necessarily highly technical. If you stumbled upon here from a search or tech-related link, this was not intended to be 100% comprehensive on anything. Condescending comments by tech trolls about how “retardedly simple” this is have already been removed and will not be tolerated.