Learning more about Drupal 6

It’s another slow work day, so I invested some time in learning about Drupal 6. Now that I’m familiar with Drupal’s structure, I’m tempted to move my blog to it. The wordpress_import module successfully imported my existing blog posts and comments. In order to make it work, I needed to delete all the spam comments and increase my PHP execution limits to 4 minutes and 256 MB RAM.

I remember how I migrated all of my posts from Emacs Planner into WordPress by generating and slurping in the RSS feed. I’m using a similar process now using WordPress’ XML Export format. I don’t even need to break it into smaller RSS feeds for memory usage.

I’m currently prototyping things through Drupal’s web-based interface. It’s easier to explore, but it also makes me slightly nervous because my changes haven’t been checked into my git repository. I use a custom module instead of making types through CCK, though, as I find it easier to hack PHP than figure that out. ;)

So what is it like now?

Screenshot of Drupal site

The key piece I’m working on is a way to keep track of recent and upcoming presentations, conferences, and other events. I’d like to eventually tie that into a content management system that will make it easy for me to plan future talks, too. I wonder if I can use this to learn about Twitter and Facebook integration as well… =)

We’re still on Drupal 5 at work, but it’s fun experimenting with Drupal 6 and wrapping my mind around the differences. I’m looking forward to learning more about tasks in installation profiles, theming, and other good things.

Always learning!

  • Not that I have much experience in either, but I feel more inclined to create a custom module then mess with CCK.

    My reasoning is for the sake of keeping it in version control. Although the CCK has import/export functionality via the Content Copy module (much better then copying SQL changes to production), I still like version control.

  • The CCK date field and calendar module make it very easy to keep track of events. Check out the sample chapter for Using Drupal (the O’Reilly book written by the Lullabots) which shows how to do an events site with CCK and Views.


    • In the past, I’ve found it difficult to modify a CCK type with my own functionality. It could just be that I need to learn a lot more about it, and the sample chapter (+ other resources) will help. In the meantime, it’s relatively easy to create my own module, hook into event and calendar, and go from there. I should make it more configurable so that I can swap in a CCK-defined node type if I need even more flexibility. Hmm… =)

  • In this respect at least, I’m glad that I am a less fluent programmer than I would otherwise like to be: there is far less temptation to roll my own solutions to problems in Drupal. CCK gives you so much for free that even if it is initially quicker to define your own content types in a custom module, you’ll probably find you’re missing out on functionality down the track.

    Views integration is the obvious thing you can point to here (it comes out of the box with CCK field types, but requires a non-trivial amount of work to add to your own modules), but there are a lot of other modules I use all the time that are CCK-friendly, and talk to each other. The combination of CCK, imagefield, imagecache, lightbox2, and views is a really common design pattern I’ve been using for my clients. For me, I’d probably just use the GIMP, upload module, and inline image elements in the body field of a node to get images scaled appropriately and online, but that’s obviously not good enough for non-technical clients. The above combination means that my clients can just plug in their digital cameras and start uploading. Images are scaled and otherwise manipulated appropriately for their context, you can have any number of gallery-type views, some gee-whiz JavaScript display effects, and often the only theming you’ll need to do is a bit of CSS.

    I’m as uncomfortable as anybody about throwing MVC out the window and mixing data, schema, behaviour, and presentation in the same bucket (your Drupal database), but for many projects losing clean version control is a small price to pay for pulling together world-class functionality on an economy-class budget in days or weeks rather than months.