I'm down to the last item on my to-do list for this round of website improvements: come up with a better taxonomy, and a sidebar menu to navigate it. Coming up with the taxonomy was easy enough (I'm lying), the menu not so much.

The beginnings of my new taxonomy menu.

In theory, it seemed easy enough: create the taxonomy, install Taxonomy Menu, and hey presto! And it almost was that easy, except...

Taxonomy Menu doesn't display the category description at the top of the page, the way the default taxonomy listings do. I intend to put real content in the descriptions, so that's something I would need to change. And it doesn't do breadcrumbs: if you navigate to a child term the breadcrumb will still say "Home", the parent terms will not be listed. Okay, so neither of these things are showstoppers, and I could live without them...but why?

The saga continues below the fold.

Email notifications of new comments and content changes have become de rigueur for social websites. If you've commented on a blog or participated in a discussion forum you've likely noticed the checkbox "Notify me of replies to this topic" or the like. This simple yet immensely useful feature helps build community and drive conversation by enabling near-real-time notification of new dialog. Dries wants it. And I want it.

Because this feature is so ubiquitous I assumed there would be a solid Drupal module available that I could plug-and-play. I was wrong on two counts: there are not one but several modules, and none of them do quite what I want. The problem, or the opportunity as the case may be, is that these modules are trying to build frameworks and be all things to all people. Although I wouldn't have guessed it, this turns out to be a surprisingly difficult problem space, and while modules like Notifications and Subscriptions have made great strides their user experience is still clumsy and complicated. Notifications probably has the best architectural solution, and the broadest feature set. But these frameworks are too intrusive, are not intuitive, and have far too many switches to flip. They distract from the content, rather than complement it.

All I want is a simple comment notification via email, which narrowed the field down to Comment Notify, Comment Subscribe, and Watcher. After trying them all I decided to go with Watcher because what it does it does well, and what it does is provide a slick AJAX-y widget that enables one-click subscription to a post, without having to leave one of those stupid "subscribe" comments. It also provides a nice view of all of your current subscriptions, with an easy one-click disable or unsubscribe.

The Watcher code is clean and easy to understand, which is good because I wasn't happy with the default presentation. I applied this patch to move the widget down into the node links, enable the link text to be modified, and changed the image (that eye is just...creepy). I also created a helper module that provides the expected "Notify me..." checkboxes on the node and comment authoring forms. Finally, I commented out the menu items for the "Settings" and "Help" tabs on the user profile page, which I felt added more confusion than value.

I should mention that notifications are only available to registered users. Watcher supports notifications for anonymous users, but doesn't require any confirmation from the email address before it starts sending emails, leaving it wide open for abuse. I've created a feature request and perhaps proper email confirmation will make it into a future version.

It took a heck of a lot of more time and effort than I anticipated, mostly spent evaluating all the different solutions, but I'm happy with the result. There is a lot of brainpower working in this space now; I look forward to watching the solutions evolve (and with any luck, seeing one of them move into the core). In particular, I would love to see a slick implementation of Notifications; if you find one leave me a comment and let me know.

Now that Premake 4.0 is out the door, I am taking a pass through my website backlog before beginning a crash course in Mac OS X programming. I thought I might get a jump start on the latter by configuring Xcode — "Apple's premiere development environment for Mac OS X" — for Drupal development, and ramp up on this new-to-me IDE while working on the familiar Drupal codebase. I'm glad I did, for it all turned out rather well.

PHP isn't a complicated development environment. There is no concept of targets or compiling, so it is really just a matter of configuring the project browser and text editor.

I'm running Xcode 3.1, which came as part of the iPhone dev kit. As such, these instructions are likely to be specific to Xcode 3.0 or later (if someone tries it with 2.x let me know how it works out, and if you needed to change anything).

The first step is to register the Drupal file extensions, such as .module and .install, as PHP file types. This will enable Xcode to provide the proper syntax coloring (and possibly other language specific features; I'm still figuring that part out).

I've done the legwork on this one and, after a bit of poking around in the Xcode internals, put together a Drupal specification file. Download drupal.pbfilespec and place it in ~/Library/Application Support/Developer/Shared/Xcode/Specifications. This is a standard OS X property list, which you can view or modify with the Property List Editor. Depending on your codebase, you may want to add more file extensions, such as .test. One curious caveat: if you change this file you will need to not only restart Xcode, but also recreate any existing projects in order to pick up the changes. Fortunately, creating the project is simple and quick, as you'll see below.

Update: Added a drupal 7 version of the scripts. Works the same, but uses a different set of patterns to pull the database connection information out of the new settings.php format.

Update: Improved the list of skipped tables, and added support for prefixes.

About a year or so ago I wrote a set of backup and restore scripts for Drupal, running on MySQL. They have seen a lot of use since, with a few tweaks here and there, and I've come to rely on them heavily. I can't imagine developing without them.

Here is my backup script, and my restore script. Skip over the code for some additional explanation and usage hints.

The default Drupal login box is...well...big.

I wanted something less obtrusive, with a smaller footprint, so I put together a simple custom module to do just that. At some point I may try to package it up as an official Drupal module, but for now you can get it from the link at the end of this article. You can see the module in action right here on this site.

For anonymous users (Drupal's term for visitors who are not logged into the site), I provide links to create a new account, or to login with an existing account. These links just point to the standard Drupal screens (/user/register and /user, respectively); I don't touch the Drupal authentication system in any way.

Once you are logged in, I say hello (I'm a friendly fellow after all) and provide a link to the user's profile page.

I think this approach is just as functional as the out-of-the-box Drupal experience, but nicer looking and less obtrusive. Of course, I'd appreciate comments on making it better still.

Here's the link to the module. Just unpack in your module directory and enable as you'd expect. Feel free to edit to suit.

This article explains how to create a logical hierarchy of pages in Drupal, reflected in the navigation breadcrumb, which allows users to easily find their way around your site.

By default, Drupal displays only article teasers on the front page. This article describes how to create a custom view to display the full node text instead.

While Drupal has fully integrated RSS feeds, I prefer using Google's FeedBurner service for its additional features and services. This article discusses how to connect the two (it's easy).

Drupal has taken RSS integration to heart, providing feeds for every category, every view, forum containers—just about every list of any kind has an associated RSS feed.

Power users may appreciate this granularity but I find the multitude of feeds confusing. When a user clicks an RSS icon on a view—one they perhaps arrived at via a Google search—do they understand that they are subscribing to just that view and not the full site? I'm not convinced.

For this site I want to expose only the main feed, the one corresponding to the front page. Feeds for the article categories, tags, views, and anything else should be replaced with the main feed.

Read on to see how its done.

Google Analytics is a free website traffic analyzer. You feed it data by embedding a small bit of Javascript into all of your website pages; information about each hit is fed back to Google, where it is packaged up into a dizzying array of statistics and reports. This article describes how to integrate it with your Drupal site to help monitor your traffic and generate more.