Some comments I received for my post about coming to terms with Drupal requested a list of Modules that I trust. I considered several approaches, including starting a database of modules with my reviews. I decided against that--I would hate to sound authoritative on which Drupal modules are good and which are bad because I haven't used so many of them, so I'm just going to discuss my experience with some common modules and hope that it helps. This is absolutely just my subjective opinion having run these modules for over a year on Observer.com and Politicker.com. I will vouch for these modules to the extent they will only ruin your life if you use them badly. Of course, your mileage may vary wildly, and if you're running or starting a site of any scale, please don't just take my word for it.

Token, Pathauto, Devel

This is my very short list of modules I install no matter what the circumstances. Token and Pathauto are usually first. I was initially surprised that path aliasing wasn't a native facility within Drupal, but these modules are ubiquitous. Token is mostly a utility module, so really I'm just talking about Pathauto here. Must install, must use. Usability win, SEO win, cloaking Drupal win (if you care about that). Devel makes short work of Drupal introspection, and is very important if you're going to need to optimize custom code. Make sure you keep Devel turned off if it's installed on a production server. Token and Pathauto do very well on my high volume sites.

Views

In Drupal 6, there's no reason not to use Views. I've heard lots of complaints from professional developers that Views is just a shortcut for amateurs and hobbyists. But Views writes SQL that's as succinct as any developer could manage and you get so much from it for free. I've used this on almost every Drupal site I've done, past a certain point of complexity. This site, for instance, does not have Views installed yet.

I trust Views on my high volume sites. I've heard plenty of moaning about Views's performance under heavy traffic, but I don't think there's a ton of merit to this. Because Views feels free, it's hard to recognize when you're using too many of them on one page. If you wrote thirty SQL queries that each returned lots of data and ran them all on one page, it'd be your fault. But somehow because Views is writing the SQL queries, it's Views's fault? Views is only guilty because it's doing what it's told. In this sense, it's best to really understand what Views is doing behind the scenes to get the most use out of it. That said, I've had more than one experience of looking at the SQL generated by Views and thinking, "ah, yes, that's how I'd do it if I took the time to get it right." Views can take the time, 'cause it's a computer program, damn it. I value my time more than I value processor time, so long as my sites respond rapidly at all traffic volumes, which they do since we cache aggressively, which we'd have to do even if we didn't use views, which would cost us a ton of time, which, I made clear, I value deeply. Ergo, I use Views.

CCK

CCK is as big a time saver as Views. I mostly trust it on Observer and Politicker, but it can be limiting in representing data exactly the way we want, and there are some kludges lurking below--shared fields are kind of scary as currently implemented. I've suffered the pain of sharing a previously unshared field and having the whole site go to hell (rest assured, I back up religiously). My understanding is that CCK will gain power and flexibility with "Fields in Core" in Drupal 7, and the move to materialized views (little v views, as in SQL views, as in *not* the Drupal module) should make it much more scalable.

In any event, just like Views (this time the Drupal module) takes away the burden of writing SQL queries, CCK takes away the burden of designing your data architecture. In this sense, it's best to approach CCK as a database design tool. In the new version of Observer.com (launching soon on Drupal 6), I've configured each content type to have a shell module which uses the simple hook_upgrade functions to alter CCK--kind of like a Ruby on Rails migration script. To me, that solves a major issue I've had with CCK--moving control of the fields in each content type out of the admin interface and into source code means that I get push CCK through the same version control pipeline as everything else.

In one key way, CCK is the safest bet of all: It's going to be in core.

Image

I like image.module, and am using it on the new Observer.com in place of Image Field and File Field, with which I've had several issues. Images will still be attached to nodes, of course, just via a CCK node reference field instead of by these special field types. Abstracting images in this way means that they can carry more data around with them. For many sites, an image is just an image, but for a media site, they need copyright and license data, photographer credit, and captions. They can be attached to multiple articles and slide shows, and the editor has a strong incentive to find the image already in the system rather than upload a new one--it's much easier. At present, there are probably hundreds of identical images of Michael Bloomberg in the system.

I should say--I've used image attach and image gallery (delivered with the image module) on other sites, though I can't vouch for their stability under traffic pressure. I probably wouldn't use them on any giant site--not because I don't trust them but because the requirements are usually much more obnoxious than these modules could have forseen. We used to use Image Assist on Politicker.com, but it baffled reporters and editors and was error prone. It's well worth a look if you need inline images and don't want to teach <img> tags, but it's worth mentioning here that we're mostly abandoning WYSIWYG in favor of teaching basic HTML to writers and editors.

Service Links, Tagadelic, Login Toboggan, Mollom

I find what Service Links does to be in poor taste, but it's a necessary evil. Since it's already done here, I don't have to get social networking mess on my hands. Tagadelic is great for building a bloggy looking tag cloud, in fact, it's only a matter of days before I break down and install it on this site. Login Toboggan is like a multi-vitamin for the user registration process; the whole "click a link in your email" thing is kind of a deal breaker on sites like mine, where users don't really need to register. And Mollom (Drupal Module) is like a multi-vitamin for comment moderation. We use it on Observer.com as well, and it scales great--one post got 5,000 comments in the course of a couple hours, and Mollom didn't blink.

Some Specialty Tools: Twistage, Bronto, Nodeshare

We use Twistage to handle video and Bronto to handle email, especially bulk email. We contributed a module to integrate with Twistage, and have written one for Bronto but haven't put it in CVS because bronto.module conflicts (namespace-wise) with a pre-existing module that covers a very different use case for Bronto. We will, I promise. Side note that should turn into its own blog post someday: On big sites, it's rarely worth running your own email server or video transcoder unless you are an email or video provider yourself. You really need an economy of scale (or an utter lack of it) to get that right.

Node Share is a low level API for sending nodes of arbitrary types between Drupal sites--we use it to push data from PolitickerNY.com to Observer.com. The staff of PolitickerNY.com used to be the city and state reporters for The Observer, now they publish on PolitickerNY.com and their content syndicates automatically to Observer.com even though the content types are very different. We also use it to push nodes around the Politicker network. It's not something you should investigate unless you need syndication and are capable of understanding the API and writing some hook functions for it.

Organic Groups

Organic Groups is one righteous module. You can do some really cool networking stuff with it without doing any real work! I haven't used it on my big sites, but the couple times I've used it elsewhere, it's worked great. A drawback to using Organic Groups on a massive site is that you can't cache so aggressively because generally you want authenticated users, but that'd be the same for any social network. We'd have to use memcache much more heavily.

Other Modules

If your favorite module isn't listed here, it just means I haven't used it enough to write about it. But I'll share an algorithm for deciding whether to use a module or roll your own:

1. The obvious: Is your version of Drupal supported? If no, stop here.
2. Read the documentation of the module.
3. Read the issue queue. If you have to patch the module, do you think the patch will get in? If a module is critical to your project, consider offering your help.
4. Gauge the reputation of the module in the community. A good way to do this is to simply poll other Drupal users on IRC. Another good way is to enlist the services of a company like Lullabot or Acquia.
5. If the prior three tests don't do it for you, you need to read the source code. If you understand exactly what the module does, it won't matter what anyone else says.
6. Unit tests specific to your site will help you quickly determine if a new module will break your system, and benchmarks will determine how much it will slow it down.

Hope this is of some use to somebody, and that the people who asked for it come back and find it.