Subversion for a Casual WordPress User…Promises and Challenges

There are a couple of things that have made WordPress such a popular blogging platform. Being Open Source, WordPress source code is available for developers to customize and extend. In the process, new bugs and security holes are discovered, and new requirements are considered. In return, WordPress code gets frequently updated to meet changing needs. WordPress also provides a level of abstraction for the casual user that is not found in any other blogging platform. Without writing a line code, the casual user can experiment with thousands of themes and plugins that provide added functionality to WordPress.

The downside is that the code for WordPress, as well as its themes and plugins is never static. WordPress code gets updated several times each year. Themes usually get updated less often. But some plugins can get updated every week!

The WordPress Dashboard informs the user when a new WordPress update is available. It also informs the user if new theme and plugin updates are available. The most convenient option is to configure file permissions and file group ownership such that the “Update” links can be clicked from within the Dashboard. This requires FTP credentials and the updates are downloaded and installed in the background. However, this is sometimes not possible on some servers that are keen on security (PHP Safe mode restrictions).

In addition, updating via FTP, whether through the Dashboard or through a client like Filezilla can be fairly slow. Especially when it comes to updating WordPress code. This means your site will be offline for some time. Updating WordPress code manually through an FTP client requires deleting specific old files, and there is always the danger of deleting the wrong files, which can brick your blog. Updating/Installing plugins via FTP is fast and easy. But suppose if all twenty of your plugins got outdated. This means you would have to download the latest version of each of them to your Desktop, unzip them and upload them. This can be fairly time consuming.

Now imagine the rigmarole if you are entrusted with updating several WordPress blogs.

For the casual user, the lure of using Subversion is being able to update WordPress using a single command. A Subversion update only adds and overwrites pertinent files, and therefore takes the fraction of time an FTP update does (around 15 seconds). In addition, a Subversion update automatically takes care of deleting unnecessary files in a less error prone way. But there are five issues when it comes to switching to Subversion.

Firstly, Subversion can only be used on a WordPress blog that was installed via Subversion. Switching your existing blog to Subversion is not easy. And it can get more difficult if your blog was installed into the root directory of your server, instead of a sub-folder. In that case, you may as well back up each and everything and do a fresh WordPress install using Subversion.

An FTP view of a Subversion WordPress Installation. Notice the .svn folder. .svn folders can be found in each and every file folder of the Subversion WordPress Installation. These folders contain .svn files which store version information about the WordPress files. An FTP WordPress Installation, or a WordPress theme or plugin installed via FTP does not contain .svn folders or files.

Secondly, updating themes and plugins via Subversion requires command-line acrobatics, for each and every theme and plugin, and in the end, may be more time-consuming than installing them via FTP (these are the additional themes and plugins that are not bundled with WordPress).

Thirdly, Subversion requires that you correctly enter the version number of the latest version you wish to update to. The process is far from automated, and Subversion cannot automatically find the latest stable release. It can however, automatically find the latest bleeding edge/nightly build/trunk version, which hints that Subversion still is a developer tool. The casual WordPress user is highly discouraged from using such untested versions.

Fourthly, using Subversion to update WordPress plugins and themes requires that they be typed into command-line in a special format. For example, the plugin “All In One SEO Pack” must be typed in as “all-in-one-seo-pack.” Thankfully, WordPress plugin pages now feature a direct link to the plugin’s Subversion repository, where such information can be found. This is a fairly recent development, and it indicates the growing importance Subversion is playing at WordPress.

Fifthly, Updating WordPress and updating the themes and plugins are separate processes. So a complete Subversion update consists of three separate processes. Of course, there are those who have tweaked things to create a unified update process. But this is beyond the scope of the casual user.

I have observed that most WordPress users are implementing a hybrid solution when it comes to Subversion. They have switched WordPress to Subversion and use it to update WordPress. However, plugins and themes are still updated via FTP or the Dashboard. The beauty of Subversion is that it allows such coexistence.

There are of course, tools such as the Open Source Tortoise SVN, that add an attractive Graphical User Interface to Subversion. Tortoise creates a local repository of WordPress and its themes and plugins on the user’s hard drive. This repository is updated to latest stable releases in the Subversion online repository, and this “updated” local repository is synched with the user’s online WordPress installation but this repository has to be manually synched with the user’s online WordPress installation outside Tortoise SVN, preferably through FTP or command line. Recently WordPress’s Matt Mullenweg made a donation to Tortoise SVN, indicating its growing importance as a preferred SVN client for WordPress for developers committing changes to WordPress code. There are proprietary SVN clients available as well, that are more advanced than Tortoise SVN.

The issue with most SVN clients is that things can become tacky when it comes to handling multiple WordPress installations. In such a case, the user would be expected to build a local repository for each and every WordPress site that he or she has (or maintains). This means updates can be done only from the computer where the repositories were installed. And again, installing a new plugin on a whim may still be easier via FTP, than through the client interface. Assuming your FTP client remembers your credentials, installing a new plugin traditionally is only a matter of clicking (and this remains one of the feature attractions of WordPress).

The Ideal Subversion Client Updating Client; A Tentative Wish list for a Casual WordPress User

Given that SVN clients may ultimately emerge as the key to managing WordPress updates, there are some things I would expect from an ideal Subversion client Updating client.

1. An ideal Subversion client will not install local repositories on a user’s hard-drive. Local repositories are a vestige of developers, who needed them to commit changes to the source code. Instead, the Subversion client will automatically install/update to the user’s web server from WordPress Subversion repositories. It will be somewhat like giving a Graphical User Interface to the command-line acrobatics presently used (which unlike SVN clients, do not create local repositories on user hard drives).
2. Upon being pointed to a user’s WordPress installation, an ideal Subversion client will be able to automatically detect all versions of WordPress, plugins and themes used.
3. Upon being pointed to a user’s WordPress installation, an ideal Subversion client will be able to convert the WordPress installation to a Subversion WordPress installation. It will also be able to convert themes and plugins installed via FTP/Dashboard to Subversion.
4. Upon being pointed to a user’s WordPress installation, an ideal Subversion client will automatically check what stable versions are available for WordPress, as well as its themes and plugins. Updates should be offered through a Graphical User Interface, that only involves clicking, and no typing.
5. An ideal Subversion client will allow a unified update process for WordPress as well as its themes and plugins at the same time.
6. An ideal Subversion client will allow easy installation of new themes and plugins. This will require some kind of interface with the WordPress themes and plugins directory.
7. Upon being pointed to another WordPress installation, an ideal Subversion client will be able to repeat all of the above successfully.

I know this is too much to hope for, and too soon. But from the perspective of a casual WordPress user, this is the need of the hour.