If you are new to drupal, then this list is for you. These are some of the best of the best drupal modules. Everything from standard framework modules, to location and mapping is covered. Note that if you've been emersed in drupal for some time, than this will be "old news".

The Big Three

"The big three" are important enough that they deserve a category of their own. Most drupal modules worth using have integrated with one of these three. Their importance simply can't be stressed enough.

• Content Construction Kit (CCK) - Part of drupal 7; still a contrib in drupal 6. Allows you to define new content types (e.g. blog entry, event, or employee record...) and add "fields" to them. A field could be plain text, an image, a flash video, or whatever. You can also adjust how these fields display in the live view. No drupal install should be without this module.
• Views - Broadly speaking, this module empowers non programmers to build dynamic streams of content displaying any number of fields. The content may come from nodes (a.k.a. content types and fields), users, system log entries, etc. You can display this stream in any number of formats including RSS feeds, tables, or just the vanilla view for a content type. You can also create pages or blocks -- its very tightly interwoven with drupal. Nearly every drupal module worth using is integrated with this module. Extremely powerful when used in combination with CCK.
• Panels -
  
  I believe Panels + CCK & Views is a hint at what drupal will look like 3 years into the future. I had to change my pants after the first time I witnessed it. At a very simple level, you could think of it as a layout manager. Create a 1,2,3 column layout. Or a 3 column layout with a full width footer and header, and plop pieces of content in them -- say a view, a block, or a node. That description, however does not do it justice. Since version 3, its positioned itself as a replacement for drupal core's clunky block system. It can now override a node page, and can be used to place content all over the place. It also introduced a concept of contexts, selections rules, and relationships. These are concepts that deserve a series of blog posts, but lets just say its solving some of the weirdest, mind numbing, bug creating problems found in advanced websites. Ironically, I used to hate this module, but after version 3 I will defend its awesomeness to the death!

One of the first lessons they teach you at the School of Drupal Arts, Arcane Sciences and Sorcery is that a tpl.php can have dynamically generated wildcards or "suggestions". You can see this every day drupal themes: you can simply use the "node.tpl.php" file if you want only one style for a node. Where as if you want different styles for three node types: blog, story & page, you create the following files:

• node-page.tpl.php
• node-story.tpl.php
• node-blog.tpl.php

Obviously, this pattern exists far beyond nodes. For page.tpl.php, user/register can have its own tpl.php file:

• page-user-register.tpl.php

Where as user/1/edit will be (yes -- these suggestions will remove numbers... i think... i was hung over that day in class):

• page-user-edit.tpl.php

This may be fine and dandy if your agenda is either to build a simple drupal theme with a few exceptions, or to build manly Texas sized drupal themes with enough tpl.php files, and duplicate html code to choke a donkey.

Old Switchy McTipplefep's trick is for anyone who:

• wants 3 styles that are shared by 20 blocks
• wants 4 possible layouts for dozens of pages in a site
• has 12 node types, but wants them to share 3 styles

The magic happens in your theme's $theme_name . '_preprocess_' . $theme function. Below are examples for how a theme named "example" would do it.

function example_preprocess_node(&$vars) {
  $node = $vars['node'];
 // only switch for story type
  switch($node->type) {
    case 'story':
      $vars['template_files'][] = 'node-batman';
      break;
  }
}

function example_preprocess_block(&$vars) {
  // sure why not -- we'll pass our node.tpl.php file to our block
  // That's how tpl pimpin works sometimes
  $vars['template_files'][] = 'node-batman';
}

*well, probably anything that uses drupal.behaviors...

Today, I was doing a few experiments on how to get several giant CCK node forms to load and submit via ajax from a single custom page.When this technique actually worked on the first try, my exact words were "no f#cking s#it..." I'm sure I'm not the first to figure this trick out, but I have had a hard time finding people who've described it. Perhaps everyone besides me figured it out ages ago -- though if that's true, I don't want to know what horrible things have driven some of you to use your current techniques.

This technique seems especially ideal for integrating any existing drupal form (especially giant CCK forms with sortable, multiple value, file fields), and the results into some highly customized drupal based web gizmo. *IT REQUIRES NO PHP* beyond whatever calls you may have to make to get dependent JavaScript files available to your requesting page. This pattern will mostly degrade to drupal's default behavior if JavaScript isn't present.

The stupid simple strategy

We use javascript to take what we want from drupal's default behavior, and throw away everything else.

Below, is all you need to submit a giant CCK form and have it successfully post:

//node form just happens to be the ID shared by every node form
//replace #node-form with any form ID and the results are the same
$('#node-form').submit( function() {
  $.post($(this).attr('action'), $(this).serialize(), function(response) {
  // ...
  }
  // return false prevents the form from submitting regularly ... noob...
  return false;
});

Even though the user will not be redirected or see any results of this $_POST, jquery will still follow the default redirect to node/$node->nid or return the original form with validation errors -- this is actually a good thing.

$('#node-form').submit( function() {
  $.post($(this).attr('action'), $(this).serialize(), function(response) {
   // why not, lets replace our logo with the resulting node
    $('#logo').replace($(response).find(.'node');
  }
  return false;
});

There's a few downsides I see to this technique: for one generating entire pages is totally unnecessarily; since we are simply taking contents of $(.node) from the result's full document object, why load the entire page? The answer is: the page already exists, and its one less menu_callback, loading, or godforbid form behavior altering trick that will cause bugs down the road. Its easy, it works, and all but the minority of websites would need to worry about the performance implications.

Another downside is that since we are using jQuery, we are depending on classes and ids that may eventually change. I think this is a real risk, but i think the risk can mostly be avoided by making intelligent decisions about what selectors you use. Besides, the maintenance hassle is probably still less compared to many of the alternatives.

Below is a working example: load a node "edit" tab, submit, and refresh the node all via ajax.

The code snippet is cute as a button, though its handling of validation is sort of half-assed. Note that the vast majority of code is devoted to simply throwing around the response data, the jquery itself is elementary.

The mere words "multistep form" once gave me a feeling of dread. There are several techniques (arguably hacks) that enable multistep forms in drupal 6. However, if you've ever used them, you'll know that they are a not techniques for the faint of heart.

While Merlinofchaos's multistep form wizard is not for the faint of heart either, I will say I found programming the forms to be fun. The setup takes a bit of focus, but after that, writing the steps is almost too easy.

Chaos Tool's wizard.inc is distinct:

1. See that stepper and buttons in the above image? You never will need to micromanage what step your form is on using the wizard. If you set up the form, it figures that sort of stuff out for you. Since it knows about stuff like "$step", its perfectly happy to figure out whether it should display a next, back, or finish button. I like code that works for me.
2. Every step in a form is a distinct form_id, that has its own #submit, #validate, and(god knows what else can be done with it via form api). Within the steps, you should never need to think any harder than you would writing a simple form with a message, and an email address. Proof can be found below in the actual form arrays, and the submit functions.
3. There are thousands of ways you can mess up a multistep form -- in a sense, the wizard lets you make your biggest mistakes in one $form_info array, while keeping the majority of the code (the formapi arrays, and form processing/validation functions) in small, easy to understand units that anyone with even intermediate formapi knowledge could work with.
4. This wizard DOES power a number of complicated multistep forms that you may use every day - the multistep forms in panels in particular. In a way, its just the most recent chapter of Earl Miles vs. Drupal's formapi -- a saga that has gone on since version 4.7. [come to think of it, i think lullabot needs to make a feature film about that epic story]

Interested? Start Here

Here's a Live Demo of the Wombat Deployment tool I wrote that uses the wizard. Only impressive in how easily it was written, and how easily i could write a 3rd, 4th, 5th, or 20 steps following the same pattern [ the subject of future posts are hinted in a rogue modal.inc file in the download.]

To get started building multistep forms, follows these steps.

1. Download Chaos Tools
2. Advanced Help. If you start futzing with this, you'll want the docs merlinofchaos wrote on the wizard. They are available through this module only.
3. My example module, the wombat tool to rule them all!
4. check back in a few for all the corrections

The full code, and detailed doc on the $form_info array will only be made available to freaks who click the "read more" link.

Content type madness is a common disease that effects drupal sites of all sizes. It is most frequently seen in drupal 5 and 6 sites, as result of content construction kit.

It is a serious, chronic disease that can result in long term damage to a site's agility, usability , and information architecture.

Common symptoms of content type madness include:

1. More than 11 content type*
2. Dubious distinctions between content types [e.g. press release, vs. annoucement, vs. news item, vs. alert]
3. No use of drupal taxonomies
4. Overuse of views
5. Users of site reporting feelings of malaise, and depression after working with content on the site.

Frequent complications of content type madness include:

1. Improperly set content defaults, ranging from internationalization, to comment settings, to publishing workflow, to user permissions.
2. Presentation inconsistency due to the proliferation of node-[type].tpl.php files.
3. Switch statements that exceed 200 lines in the hook_preprocess_node(&$vars) function in the template.php file.

Treatment Options:

Treatment of content type madness is usually difficult,  time consuming, and often requires the services of drupal specialists. In severe cases, treatment requires a total redesign and refresh of content. If you have never attempted to treat content type madness, BACK UP THE DATABASE BEFORE YOU TRY.

Highlight: WYSIWYG API Gets Top Spot With 97% Growth (Feb 8th - March 29th)

Ever wondered which modules' userbase was growing fastest?

With a bit of simpleXML, 2 hours of boredom, and drupal.org's usage charts, I can provide an answer. Personally I thought the results were rather interesting.

This list only includes projects that got 6000 downloads or more last week. I picked 6000, because otherwise, ubercart wouldn't show up.

The phpdocs put it kind of weirdly:

PHP 5 comes with a complete reflection API that adds the ability to reverse-engineer classes, interfaces, functions and methods as well as extensions.

I prefer the notorious c.h.x.'s definition

chx: it's like this insane cool weaponset of PHP which is like totally unknown :)

Reflection is a very powerful too that lets you understand the code running in your enviroment. This is particularly important for drupal development, as so much of drupal is based on functions that call functions (e.g. hooks).

The point of this tutorial is to show you how much ass reflection can kick, in so little code. The following page finds out every menu item that calls a function hidden away in a remote file, and gives you the location of the callback function: filepath, and line number and all. Note that the vast majority of code is merely used to output the test table. Obviously, this example merely scratches the surface of useful things you could do with this api.

While building a product comparison website, I ran into a situation that required a view to sort using one of 2 possible price totals depending on a users profile: lets say "red state", "blue state". The goal was to open up the product comparison tables (order, fields, field names, and filtering questions and all), as well as the underlying data to this companies' staff, so a homebrew wasn't an option (which it shouldn't be, almost 99% of the time).

Luckily, there were only two possible prices for those products, so all I had to do was create two CCK *decimal* fields [ this is important, because text, and integer fields don't properly store or sort decimal points for prices ]. Then, on hook_cron, or a node submit, I updated the two totals based on other itemized fields.

However, how would the view know which column to sort products by based on a flag stored in the users session? There's about 5 ways to do that, so I went with the 1 minute solution:

Set up two sorts in a single view, and implement hook_views_query_alter(&$view, &$query)

Discussion

In theory, you could write a custom algorithm that built its own sort queries based on a criteria using this method. You could also probably alter filters, or fields. However, this isn't the only way to have accomplished this -- but its the easiest for me to stomach. Never use this method when existing views features, or view arguments, or even other views hooks may be the proper hammer for this nail.

If I learned anything, its that views a complex beast; flexible like F-22 -- an amazing piece of technology that offers tremendous freedom -- but often that freedom will cause you to crash in the ground if you don't think about what you are doing carefully.

During the drupal.org redesign process, I noticed that Mark Boulton was using blueprint. I decided to give it a spin, and used it on a drupal site for a surgeon who specializes in sports medicine. (heavy use of imagecache, nodequeue, views, books, and nicemenus). Since that project, my stance on blueprint is this:you'll take my CSS framework from cold dead hands.

Is there a drupal theme?

Yes, and its very well made. Offers nothing except a basic grid layout that supports1,2,3 columns, a strong typographical foundation, and the conversions of various drupal elements to the blueprint styles. My "starter theme" of choice. In my humble opinion, the revolutionary advances in drupal 6 make big, bulky starter themes unnecessary.

Blueprint crash course

You don't need to know a whole lot to use blueprint. Everything you absolutely need to know is in the below code example. (with notes below)

• 1. .container sets width to 950px, and centers the content with auto margins on the side. All grid elements must be within ".container".
• 2. .clearfix - this does the same thing as having br class="clear" below the floating elements. See the oddly named br element that doesn't need to be there.
• 2. .span-[x] The width of the column in the grid. Numbers range from 1 to 24. A full row must add up to 24, and can also include prepend-[x], or .append-[x], which share the exact same widths, only add margins, either before or after the column. The final column always needs the class "last" so that it doesn't add its 10px right margin.

And that's really all there is too it. Of course, there are many more features, that let you get perfectly centered borders that don't cause the elements to overflow, some nice typography classes, and other useful stuff that nearly any website needs. I found the best way to learn the framework was to just look at what's going on on the example pages, with firebug. Its all quite self-explanatory.

How Do You Teach Drupal Without Inducing Confusion/Boredom Triggered Comas? Here's a rule that has never let me down:

Never interact with the drupal site in any way during a lesson

The person you teach needs to click on every menu link, fill out every form, and as they learn, its your job to start taking off the training wheels. At first, you'll have to point them to where to go to add a new taxonomy term, but make it a point to later ask them to add a taxonomy term, and see if they remember how to find it.

This "hack" works well for two reasons:

1) It prevents you from going into conceptual monologues

When I'm at the helm, clicking around, and "explaining concepts", its almost impossible for me to avoid inflicting a salvo of turd bombs on my hapless student. For a moment, read this: (if reading this text doesn't make you want leave this article, there's something wrong with you)

In Drupal, a node is a grouping of data, which we call fields. A node is different from a user, and block, because its content, which leverages drupal's rich nodeapi. On this page you can add, edit, and manage node types using these tabs. By clicking "edit" I can edit node settings, like whether I want comments to be threaded, or flat. Isn't that exciting? By clicking "manage", I can add new fields to my node, which can be of many types including, text, number, decimal, computed. These fields have rich set of options, including setting the maximum length, making the field required, and even entering in custom validation code for node form submits.

Not only is this a terrible way to teach, best case is that your student is completely lost (probably on something as simple as the difference between nodes, and node types, the fact that a "field" is a specific CCK concept, and not a form element), but most likely, they are not paying attention anymore. Monologues + projectors = brain death.

Let your students direct what you are teaching them

Don't teach them about blocks. Teach them how to put that new announcement in the right sidebar. Don't teach them about views.Teach them how to edit their press release page so that it only shows titles, and dates, and a "short blurb" field. As they gain more understanding, you'll find they naturally gravitate towards more advanced concepts. Best of all, you don't have to waste time talking about boring things that they don't need to know, or blabbering about stuff that they already understand.

2) The student is always on the spot (meaning, paying attention)

Nearly everyone has a tendency to worry about asking "stupid questions" (they are never stupid questions). If a student actually has to do all tasks required to teach something themselves, they won't be able to hide the fact that they missed a critical concept. You'll know fairly quickly if you need to do a better job of explaining the admin menu and how it fits together, and the pattern it follows. You also will probably find out that they still have conceptual issues that need to be cleared up between the very similar taxonomy, block, and menu pages. You see, every little task becomes A TEST. Testing is about taking off the training wheels. Even when they *fail*, the very fact that their brain had to struggle before hand means they'll have learned something. Its uncommon for someone to fail tests like "go to the block admin page" more than 2 twice. Eventually, they'll know where to look even when they've never seen it, and you are just now introducing the concept. Just keep testing them. After all, its really a test of your teaching skills, no?

While this makes teaching and learning more challenging, they learn dramatically faster then the monologue projector methods, or constant email support alternatives. .

*There's no exceptions to anything I write, FYI. If there were a lot of variables, a situations where these rules didn't work, I'd cover them one by one. Because Drupal Planet readers love long winded tracts that refuse to take sides.