The frustrations of switching content management systems

Recently, I have been hearing over Twitter that one of my contacts has been thinking of moving one of his websites off WordPress onto Expression Engine, a proprietary content management system. I have never tried EE, but have tried a number of the more common open source CMS’s including Textpattern, Movable Type, WordPress and Drupal. They all seem to have their strengths, but a common problem affects all of them: flaky contributed modules and plug-ins and unreliable cross-CMS data transfer programs.

My transfer from Movable Type to WordPress was almost a spur-of-the-moment decision, or at least the decision took a few days, but for the most part I have been happy with WP’s performance. I have had a few gripes, however, most notably that a number of the plug-ins which are advertised as working with my version of WordPress appear not to, and the first thing I checked was whether this was due to my theme not supporting it, but in each case when I switched to the default theme, the plug-in still did not work. This could be down to the fact that you have to edit your theme’s source code to specifically call whichever function these plug-ins provide, but the whole idea of WordPress’s “hooks” is that this is no longer necessary, and in any case, on one occasion I did edit my theme with no effect. The documentation should make it clear whether it is an “activate and go” plug-in or one which requires editing. Bad plugins are a feature of open-source platforms, of course; anyone can develop them, regardless of their skill and understanding, and they develop them for their own needs rather than anyone else’s, and sometimes they drop support for them when they can no longer fit it into their schedules. However, there are also strong modules maintained by teams who do the job well.

I have already written about Movable Type’s lack of a blogroll facility, which was one of the biggest factors in motivating me to move this blog from it to WordPress. A bigger gripe is its limited export format, which was probably pioneering when it was invented and an improvement on what Blogger had to offer (basically, you had to use a publishing template which meant your actual blog couldn’t be displayed), but is now somewhat limited, failing to export your category hierarchy. (I only found this out when I was trying to get WordPress to display my categories in a hierarchy, and it stubbornly refused; I had to reinstate the hierarchy manually.)

Six Apart, the company behind MT and TypePad, do not have much motivation to improve the export functionality on MT or TypePad, its MT-like hosted package, as it means people will not be using a Six Apart product. So, your exports are limited to producing a plain-text dump of your whole blog. They have not got around to exporting individual categories, or years, or anything less than the whole site. Even though internet services have improved and bandwidth increased, this can still cause headaches such as interrupted exports (some web hosts have a time limit on scripts, which used to persistently cause errors when I tried to rebuild my old MT blog). Depressingly, the open-source competition is no better. WordPress’s export functionality also exports your whole blog, nothing less, in an RSS-based format, which at least saves your category hierarchy (and your blogroll; MT can’t do that, because it doesn’t have a blogroll feature).

The worst platform for flaky import functionality of the platforms I’ve tried, however, has to be Drupal. Drupal has no such functionality of its own; this has been left to third-party module writers, something I hope seriously changes when Drupal 7 is released as it is a major weakness. The MT import module advertised for Drupal 6 simply does not work; it has not been updated properly for version 6, and produces errors. When I did the changes myself to get rid of these errors, the plugin did nothing. I managed to import content from my MT export file only by setting up a Drupal 5 website, but when I upgraded the site to Drupal 6, it would not let me edit the entries as they had been assigned the “blog” content type rather than “story”, and the blog module had not been enabled (I deliberately did not enable it, as its functionality is rather limited). However, this could be solved with a SQL command by using the database control section of your host’s control panel. I had a lot of trouble getting the WordPress import functionality to work also, and finally managed it only by installing the development version of the module. This should really make people considering moving any website to Drupal (as opposed to setting up a new Drupal website) question whether it is worth it, particularly if they are coming from MT.

I also gave TextPattern a try, because it has the capacity to import an MT blog not only from the text dump, but also straight from the database. I tried running that on my site A Qt Blog, which is what I intend to migrate (probably to Drupal now). It did import my entries, and although it imported my categories as well, it didn’t categorise any of the posts. It also imported every single person who has ever commented on any of the blogs on my MT installation (mostly the old version of this blog) and gave them a user account, even if they had never commented on A Qt Blog. I decided then that TextPattern was not for me.

Different CMS’s have different strengths. If you want a straightforward personal blog, choose WordPress. If you absolutely have to run more than one blog off the same database and administration panel, choose Movable Type. Drupal is best for when you have more than one content stream: it allows you to create different content types and category hierarchies within the same website, and devise ways of ordering and displaying the content. It is easily the most flexible of the three, but it has a definite learning curve and requires some planning; you can’t just set up your site and run, as you can (after a fashion) with WordPress. Drupal also has the benefit of a lot of printed documentation, much of it very recent: Using Drupal by Angela Byron et al, published by O’Reilly, and Front End Drupal by Hogbin & Käfer. While looking for documentation on WordPress, much of what I found was out of date and below my skill set, or about specific technical subjects such as developing plugins. It does have very comprehensive online documentation, however.

As for Expression Engine, the full package costs $99 ($249 if you are using it for profit), not including a year’s updates, the forum module and the capability and licence to run multiple sites. Whether you can justify that is your decision, but it seems expensive when most of the competition is free. It might do to enquire as to whether you can easily transfer data off the system (even the method for transferring your content onto it seems complicated). If you choose Drupal, I suggest getting an extended version with commonly-used modules bundled (such as Acquia Drupal). I really recommend asking around, as you may well know someone who can both design a website and set up a CMS well. Setting up with all of these systems “can be done”, and the transfer of data is generally something which only has to be done once, and is then over with. However, it does not make it any less frustrating, and transition tools are a major weakness in all of the major open-source CMSs and improving them should be an urgent priority.

Possibly Related Posts:


Share

You may also like...