Tagged : drupal

in blogging, tools

Moved from Drupal to WordPress, and the top ten reasons you might want to do the same

Drupal vs WordPress
If you’ve followed my previous posts here, you know that I’m a big fan of the Drupal content management system (CMS). Drupal is powerful, well architected and easy-to-extend. So, what’s not to like? Well, the complexity for one.

Don’t get me wrong, I’m not trying to rag on the drop. I still appreciate what Drupal brings to the table for large, complex or community-oriented projects. But it’s waaay overkill for a simple blog site. Maybe even a simple web site.

That’s no big revelation, and most ardent Drupal supporters will readily admit this. In fact, I knew it myself when I began using Drupal 4.7 back in 2006. But back then I felt there were no interesting alternatives.

On of the alternatives I looked at back then was WordPress, which must have been in version 2.0 at the time. When comparing it and Drupal, I recall really liking the architecture of Drupal, and the ease with which it could be extended through modules. WordPress on the other hand, didn’t seem to have a coherent architecture. WordPress seemed simpler, yes, but it was on the other side of that “simplicity line” which felt limited in capability and constraining.

Fast forward three years. With a number of Drupal sites and some additional years of blogging under my belt (yes, I know… not enough posting!) I took a fresh look at WordPress to see if it could help simplify things. I was pleasantly surprised; WordPress had matured well over the years. The administrative interface in particular was a sight for sore eyes, as anyone who has ever administered a Drupal sight can attest.

So what the heck, I undertook the process of migrating this blog from Drupal to WordPress a couple of weeks ago, and with great success. This blog is now powered by WordPress (initially 2.8) and the following are the top ten reasons I’ll benefit from the move:

  1. Updates — ­­­­ Updating from one version of Drupal to the next is a pain in the butt. You need to log into your account via ssh, download (or upload) the files, move stuff around to make sure you’re not clobbering customizations, modules or themes, unzip, then update via the web. I had develop a streamlined way of organizing my Drupal files using symlinks to make this all easier, but it’s still a pain. With WordPress you click an “update” link in the admin dashboard and you’re done.
  2. Administration — Speaking of the admin dashboard, administration of a simple WordPress site is a dream compared to doing the same in Drupal. The admin interface is very clean and everything seems to be only one click away. The post listing is very clean and bulk actions are easily applied to multiple posts found via search. Your admin console is also nicely tied in to wordpress.org, allowing you to review wordpress news and updates, and browse for new plugins and themes without leaving the comfort of your site. It sounds like much of this is new with 2.7.
  3. Spam control — Spam has been a major pain point with every Drupal site I’ve ever administered. WordPress’ anti-spam system, Akismet, has a Drupal module associated with it, but it never seems to work — the spam just gets right through. There is an analogous system to Akismet called Mollom that is written by Dries — the creator of Drupal — and others, but it also leaves a lot to be desired in the spam-blocking department. And both of these have very clunky admin tools — reviewing flagged spam just seems slower, harder, and more painful using either of these solutions for Drupal when compared to WordPress paired with the native Akismet. But so far WordPress and Akismet have been dead accurate for me, with no spam getting through and no obvious false positives to date.
  4. Tags and categories — Yes, Drupal’s Taxonomy system is much more powerful than WordPress’ tags and categories, but it exacts a heavy price. Taxonomy is much harder to deal with and manage than the native WordPress tools.
  5. Plugins — Plugins in the WordPress world are much easier to use because the WordPress Plugin Directory is fully integrated into your sites admin console. Click “Add New” from the Plugins menu, search or browse for what you want, and there is a single button install that allows you to easily try new modules. With Drupal you’re sshing into your host, downloading, installing, enabing, etc. and updates are just as painful.
  6. Themes –  Above applies to themes as well. Plus there are FAR more free/cheap and good looking themes available for WordPress than Drupal.
  7. Notification — One problem I’ve had with Drupal sites is getting an email notification when a new post is made. This requires a module and none of the ones available is very good. This is built in to WordPress right out of the box.
  8. File editor — I can list reasons why you wouldn’t want to use this (e.g. source control) but the WordPress admin console has a built in file editor that lets you make quick changes to things like CSS files or plugin files. I’ve used it several times and it can save a lot of time.
  9. Installation — Not quite an ongoing benefit, but worth commenting on. WordPress installation is drop-dead easy. Drupal is trying to get there and has made leaps and bounds over the past couple of years, but WordPress installation is far ahead.
  10. Community — The WordPress community is very large and it’s pretty easy to find help and how-to information. This is a bit of a mixed bag though, because while the WordPress community is way larger than the Drupal community it is also not quite as technical since the bar is a bit higher to get going with the latter.  As a result, the signal-to-noise ratio can be a bit lower in the WordPress community and you have to wade through more fluff to find what you’re looking for.

I still maintain a number of Drupal-based sites for work and personal interests, and still think it’s a great tool. But for me the recent advances in WordPress make it an easy decision to use it for my personal sites.

Anyone else make or considering making a move in one direction or the other?

in Uncategorized

how to modify a drupal theme the right way, or why sub-themes in drupal 6 rock

sub-theme_branching Situation: You found a great new theme for your Drupal-based blog or Web site. You give it a whirl and it looks awesome, but it needs a few tweaks before it really becomes your own. Since the tweaks you’ve got in mind are so minor, you open up the style.css in vim, pull up Firebug, and start hacking in your edits.

Problem: The main problem with this method comes later, when you want to upgrade to a newer version of the theme.  That’s what happened to me today. I was poking around my site and noticed that a newer version of the Nitobe theme was just released. It was a beta at the time I installed and customized it, so while nothing was broken I decided to go ahead and update it. While identifying and migrating my minor css changes over to the new style sheet wouldn’t really present much of a problem–Beyond Compare makes pretty quick work of diffs and merges for me–it did seem terribly inefficient.

Solution: If you’re fortunate enough to be on Drupal 6 or later, sub-themes solve this problem handily.

My quest for "a better way" led me to the Drupal 6 Theme Guide, where I read up on sub-themes, a new feature in Drupal 6 that makes it very easy to extend existing themes without mucking up the original code.

To create a sub-theme, you simple create a new folder in your themes directory. In the folder you create a .info file containing basic info about your sub-theme, plus information for any additional styles sheets you want to define. Here’s my subtheme.info: 

name = sam.charrington.com
description = A customized Nitobe subtheme for sam.charrington.com.
screenshot = screenshot.png
base theme = nitobe
core = 6.x
stylesheets[screen][] = my_styles.css

That last bit, about the style sheets, is the key. Because Drupal adds your sub-theme’s style sheets last, you get to take advantage of the cascade and override any styles you want to tweak. Just copy the target selectors from the original .css file into a new "override" file that you put in the sub-theme directory and make your edits there.

The end result is, ideally, a clean and easy separation between your style updates and the original theme. I say ideally because in my case I needed to make one other change so that Nitobe’s rotating header images would pick up from a directory in my sub theme. Details and patch here, for the interested.

in site updates

Site maintenance

More Drupal tweaking today:
 
  • I installed the service_links module to make it easier for visitors to bookmark articles on the site. I also installed the trackback and tinymce modules, which make it easier to do some backend stuff.
in Uncategorized

Post from Word 2007

Yeah, I should be working but something reminded me that Word 2007 had a built-in blog editor and I just had to try it. I've inserted a picture and some categories into this post; let's see how Word does. (I'm using the MetaWebLog API).

 

EDIT: No categories, no image. I'll have to play around with this some more later to see what I can get working. I also need to try some more elaborate formatting to see for myself how good/bad the resulting HTML is. P.S.: here is the picture:

in Uncategorized

Easy upgrade to Drupal 5.1 if not for Flexinode

I started messing around with Drupal this evening, and as usual it managed to consume my night too, keeping me up way too late. Most of the time was spent looking into what it might take to migrate my work site from 4.7 to 5.1. Using a local copy of the database, I installed the 5.1 files and ran the update script. I was pleasantly surprised with how easy it was to upgrade the core components and database. But I'm not nearly done… The site makes heavy use of the flexinode module to create custom content types. Unfortunately, flexinode isn't yet supported in 5.x. If converting the flexinode-based content can be done easily, I'd just assume migrate everything over to CCK. I'm beginning to fear it won't be too easy though. I haven't looked into which of the other modules the site uses have been ported to 5.1, but flexinode is by far the most important. If I can get that figured out, I'm as good as done. I also noticed that my theme for this site doesn't render correctly in IE(7).
It looks like this: when it should look like this: . I hope it's an easy fix. Easy or hard, I'm not doing it tonight!