Unfortunately, after the upgrade, every other form submission on the backend was giving me blank pages and error messages, and I determined that my outdated theme was likely to blame. What’s more, I had foolishly made several customizations to the theme’s CSS, which of course would not be preserved when I upgraded it. Since I always thought that theme was a bit dull, anyway, I figured it would be as good a time as any to search around for a new one. As a side note, the new theme browser/installer in 2.8 made this task incredibly easier than it had been before.

So now we’re rolling along error-free with a new theme and all my customizations safely stashed in the Custom User CSS plugin. I’m still not totally satisfied with this theme (especially the weird fadey drop-down menus) and will probably change it again in the future, but that’s life. On the positive side, the main content area is now just wide enough to squeak a 640-pixel-wide image into.

One of the non-CSS customizations I had made to my old theme was to add several lines of PHP that would prevent my content from being “texturized” – straight quotes replaced with smart quotes, doubled hyphens replaced with real dashes, etc. When I enabled the new theme and the texturization returned, I was surprised to notice that the one thing about it that really annoyed me had apparently been fixed: Straight quotes inside <code> blocks are no longer converted into smart quotes. I’m not sure if this is a fix on the part of the theme or WordPress 2.8 (I don’t see anything in the changelog about it), but either way I’m happy enough to leave the feature turned on.

The one thing that really impressed me about 2.8 is the new syntax-highlighting, line-numbering, generally awesome-looking code editor. This is the first time I’ve seen anything like this, though in retrospect it seems like an obvious idea: If we can already do WYSIWYG editing for normal content, why not apply some nice formatting and colors to code-editing as well? If you’re curious to see what this looks like, the WordPress 2.8 release announcement has a slick video overview that touches on the code editor and various other new features (I recommend watching it, if only to witness the incredibly high production values for it being an announcement of a point release).

Now, to be fair, Drupal and WordPress are in two completely different categories, at least to start out with. WordPress is advertised and works best as a blogging system, and you have to do some hacking to expand its functionality beyond that. Drupal is a sort of uber-extensible CMS framework that does almost nothing useful out of the box, and you have to do some hacking to transform it into a blogging system or an online store or whatever else you want.

Nevertheless, in the few weeks I’ve been using WordPress, I’ve noticed a few things that really impressed me, and made me wish I had the same features in Drupal. This is not to detract from Drupal’s sheer power as a do-anything CMS, but I have often found it lacking in usability (and apparently I’m not alone). At any rate, here are some of those nifty features:

• Fully-integrated WYSIWYG editing out of the box. This is really something that’s important to get right if your content is being edited by “regular people”, and it’s also an area where Drupal falls flat on its face. By default, Drupal just gives you a plaintext input box and expects you to start typing HTML into it. You can download modules that plug in various generic WYSIWYG editors, but installation is awkward and integration is lacking.
• Integrated one-click plugin installation and updating. To install a WordPress plugin, all you have to do is find it with the integrated plugin browser, and click the Install button. The plugin is automagically transferred to your server and unpacked, and it’s just one more click to activate it. Upgrading a plugin to a new version is similarly a one-click process. With Drupal, it’s all manual: Download the module tarball from the Drupal web site, unpack it, FTP into your server, transfer the files over, and activate the module. And you have to do this every time a new version of the module comes out. Gets kind of irritating when you have more than a dozen modules installed, which is probably the minimum number you need to do anything useful in the first place. Sadly, this rigamarole is necessary for WordPress themes as well, but that’s apparently being worked on, and you only really install themes once.
• Built-in editors for everything. Want to tweak your theme’s stylesheet? Don’t waste time SSHing into your server, just hit the Editor link and you’re already there. Anything you could want to change on the server is available through the web interface. Admittedly, fewer things in Drupal actually require you to edit files on the server, but I’m surprised they haven’t done something like this already, since the coding effort required is small.
• Decent image handling out of the box. I say “decent” because the way WordPress does it is far from perfect, but at least you can upload media files to a designated directory on the server, and insert them inline into your content with only minor fiddling, all without installing any plugins. Drupal doesn’t provide anything like this unless you install half a dozen modules, none of which are quite able to cooperate perfectly, and all of which are guaranteed to require several hours of tedious and/or non-intuitive configuration. Which brings me to my final point about WordPress…
• Most things are obvious, intuitive, and painless. It’s hard to explain this one since it’s more of a feeling than anything else, but it pervades the entire WordPress core. When I want to do something with this web site, I log in and “just do it”. The entire interface is so slick and easy-to-use that I never stop for a moment and wonder why I’m doing something the way I’m doing it. It all just makes sense. And it’s all buttery-smooth thanks to the pervasive AJAX effects and excellent use of color and typography on the backend (in fact, I find myself wishing I had a front-end theme that captured the feel of the admin interface!). Of course, part of this comes from the fact that WordPress is laser-focused on providing a great blogging platform, thereby achieving a level of coherence and integrated features that Drupal, which tries to be all things to all people, could never match. Still, it makes Drupal look positively clunky by comparison. To this day, whenever I log into the CSH web site with a task to do, I experience a brief moment of confusion as I wonder whether the module I’m looking for decided to vomit its settings page into ”Content management”, “Site building”, or “Site configuration” (or maybe it’s a secondary tab in a sub-page of one of those categories…).

Well, that’s enough of me ragging on Drupal. As I said before, it’s really an amazingly powerful framework, and for things much more complex than a personal blog, it’s still my CMS of choice. I just think that, in terms of usability, it could do worse than to take a few cues from WordPress. (Incidentally, I’ve discovered a number of WordPress annoyances as well in the past few weeks, but those will have to wait for another day.)