CMS Choices – May 29, 2009
I've not been happy with any of the choices that are available for content management, but lately I've been warming to Drupal. Each system has its downfalls, and upgrades seem to be pretty bad on all of the ones I've used extensively (webgui, drupal, joomla).
I haven't tried to do major upgrades on newer versions of webgui, and its probably gotten better (it couldn't have gotten worse) than the 6.x versions.
Joomla looks to be just about impossible to upgrade ever, with all of the routinely used, third party modules that all conflict with each other.
I had been happy with drupal, though I regularly get contacted by my drupal customers when they break something during the upgrades, and the problems are generally regarding someone forgetting one of the many required, but non-intuitive steps to get the upgrade to work successfully. And in all cases (until the other day) I was able to successfully fix the problem that the user had, relatively quickly, and got him going on his way again, with another tool in his bag for how to avoid the problem next time.
But... my most recent issue with the upgrade has to do (apparently) with the path module, which appears to be a relatively supported module (I am all for plugins, and think it is a great way to incrementally expand and improve functionality and not bloat the core code for those who don't need it, but it also makes things quite confusing, and makes the upgrading fails in all sorts of mysterious ways.
The upgrade caused various SQL statements to be printed into the apache logs, and by searching on google for the error messages found various users with the same problems, and the developers generally saying, "this isn't a problem - it works for thousands of other users, not our fault", which is a swell attitude to have towards your users. We tried to upgrade from drupal 5 to 6 a number of times (the user had originally forgotten to upgrade to the latest 5.x before upgrading to 6.x (he actually wasn't sure if he was on 5 or 6, so that is why he just grabbed the latest version and tried to upgrade). He also never puts the site into maintenance mode, and never backs up the database first, so the developers would probably just say it is his own fault, but in credit to the developers, he generally doesn't have problems, so hasn't been taught that either of those two steps are necessary. I restored his database to the automatic backup from the night before, and restored his files from the manual backup from some time ago; discovered that he was running something less than 5.18, and downloaded 5.18, and successfully upgraded to that version.
However, the goal was 6.x, and that upgrade failed a number of times. It seems that lots of people who get the url_alias table error regarding the missing language column don't put the site into maintenance mode, so we did that, but got the exact same error. The next step is to try to disable the path module during the upgrade, and see if that fixes it.
Which perhaps, disabling modules is the correct way to upgrade, but then you have to remember which modules were activated, and go through and re-enable (and upgrade) them one by one.
It is far better than phpBB's "plugin" support, which they call "mods", more rightly called "hacks", since you are modifying core code in each case, which is an incredible pain during upgrades. But, we comment in the source code for each change, and keep phpbb's code under our own source control, so we can have a shot at upgrading appropriately.
Obviously, I vastly favor LifeType's model of plugins, where "installation" is defined by copying the plugin's directory to the "plugins" folder, and clicking on a link. And un-installation (at least in the crude sense) is deleting the files. (LifeType does need to add a step where it can remove stuff from the database as needed). And I suppose LifeType's model of requiring you to remove the plugins directory, upgrading the core, and then getting the latest versions of the plugins is similar to drupal's, but it skips the step of having to disable the plugins in the GUI, so it is easier to manage, but just renaming directories in an FTP client. (I also don't find the auto-searching for plugins very helpful, since it is occasionally nice to rename a directory "module.old" rather than having to copy it outside the directory tree somewhere, in the hopes that drupal won't automatically find and install two versions of a plugin accidentally.)
But, enough with the ranting - I've been writing a drupal plugin recently, and outside of the disable, uninstall, install procedure you need to do when changing database stuff, it hasn't been that bad. I do wish the drupal enforced more hierarchy on the plugins, from a URL standpoint, so when weird things happen when visiting a certain URL you could tell which module was actually causing the problem. I guess LifeType has a similar problem, but the plugin writers are better about using good (identifiable) URLs than the Drupal module writers are. And once LifeType takes over the world, they'll be plenty of bad plugin writers to do bad things with the code just like the rest of the content management systems. Hopefully, by then, we'll have figured out ways to make the bad programmers behave.