Essentials

These contributed modules should be installed in every site.

Content Construction Kit, aka CCK, aka Content (http://drupal.org/project/cck)

Allows administrators to add custom fields to content types. Included field types are text, number, node reference, and user reference.

Views (http://drupal.org/project/views)

Creates customized lists and displays from already entered content. Along with CCK, this is the heart of adding content once but being free to display it multiple places and multiple ways. (For those familiar with relational databases, CCK & Views let you use the power of relational databases to wrangle your content, while still keeping content adding and editing as simple as word processing and online shopping.)

Semantic Views (http://drupal.org/project/semanticviews)

Requires Views.
Permits UI management of HTML markup used to display views, which in turn allows use of semantically meaningful markup. For example, it lets you use <h2> instead of <div> for the titles of content pages listed in a view, and just in general cleans up the <div>-soup (and class attribute overload) normally created by most Views output styles. Semantic markup is absolutely necessary for accessibility. People using screen-readers cannot see that this <div> has larger text than that <div> —indeed, their screen-readers usually don't even tell them that the content is in different <div>s. For a visual demonstration of the problem, see This is your family on "Style: Unformatted" and This is your family on "Style: Semantic Views". As an added benefit, the HTML markup is much more concise and intelligible with Semantic Views, too.

Poormanscron (http://drupal.org/project/poormanscron)

Makes sure cron.php is run regularly, which is necessary to take care of various background maintenance tasks.

Date (http://drupal.org/project/date)

Requires CCK. Recommends jQuery UI for popup calendars and time entry widgets.
Defines CCK date/time fields and widgets. What makes this module essential is that it also provides a Date API submodule that provides superior date & time handling than in Drupal core.

Module Grants (http://drupal.org/project/module_grants)

Enables access control for unpublished content and allows modules that operate on access grants to work together in the expected way.

These optional core modules should be enabled in every site.

Update status (update)

Checks the status of available updates for Drupal and your installed modules and themes. Enabled by default (unless deselected during installation).

Menu (menu)

Allows administrators to customize site navigation menus. Enabled by default.

Path (path)

Allows users to rename URLs. Human-friendly URLs (e.g.,"about" rather than "node/72") are important for accessibility, usability, and SEO.

Modules to improve accessibility & usability; Or, Modules to keep users happy

Accessibility (& usability)

Out of the box, Drupal 6.x is relatively good with regard to accessibility, but there is room for improvement. Contributed modules are a bit more of a mixed bag. These modules are good (indeed, vital) for making various aspects of Drupal more accessible —and more accessible usually means more useable in general, too.

Semantic Views (http://drupal.org/project/semanticviews)

Requires Views.
Permits UI management of HTML markup used to display views, which in turn allows use of semantically meaningful markup. For example, it lets you use <h2> instead of <div> for the titles of content pages listed in a view, and just in general cleans up the <div>-soup (and class attribute overload) normally created by most Views output styles. Semantic markup is absolutely necessary for accessibility. People using screen-readers cannot see that this <div> has larger text than that <div> —indeed, their screen-readers usually don't even tell them that the content is in different <div>s. For a visual demonstration of the problem, see This is your family on "Style: Unformatted" and This is your family on "Style: Semantic Views". As an added benefit, the HTML markup is much more concise and intelligible with Semantic Views, too.

User interface enhancements

Vertical Tabs (http://drupal.org/project/vertical_tabs)

Provides vertical tabs for supported forms such as the node edit page.

Taxonomy Super Select (http://drupal.org/project/taxonomy_super_select)

Requires Taxonomy
Changes the default taxonomy select box into checkbox or radio buttons.

Excerpt (http://drupal.org/project/excerpt)

In the node edit form, displays the teaser as a separate field from the Body field and makes it easier for the teaser to be something other than truncated body text.

User experience improvements

Better Formats (http://drupal.org/project/better_formats)

Enhances the core input format system by managing input format defaults and settings. This allows automatic selection of, for example, Full HTML for use by trusted content contributors, instead of such contributors having to manually select Full HTML for each general text field.

Wysiwyg (http://drupal.org/project/wysiwyg)

Requires installation of (non-Drupal) editor libraries.
Allows users to edit contents with rich text editors such as CKeditor and TinyMCE. Permits inclusion of more than one rich text editor in the same site.

Modules to keep site and content administrators happy

Administration menu (http://drupal.org/project/admin_menu)

Provides a dropdown menu to most administrative tasks and other common destinations (to users with the proper permissions).

Advanced Help (http://drupal.org/project/advanced_help)

Allows advanced help and documentation. Many contributed modules' help and documentation are primarily available through this module.

Views Bulk Operations (http://drupal.org/project/views_bulk_operations)

Requires Views.
Exposes new Views style 'Bulk Operations' for selecting multiple nodes and performing actions on them.

Poormanscron (http://drupal.org/project/poormanscron)

Makes sure cron.php is run regularly, which is necessary to take care of various background maintenance tasks.

Modules to keep site builders and developers happy

Features (http://drupal.org/project/features)

Provides feature management for Drupal. Features provides a UI and API for taking different site building components from modules with exportables (CCK, Views, etc.) and bundling them together in a single feature module.

Strongarm (http://drupal.org/project/strongarm)

Requires Chaos tool suite.
Gives site builders a way to automatically override the default settings that Drupal core and contributed modules ship with.

Chaos tool suite (http://drupal.org/project/ctools)

A library of helpful tools by Merlin of Chaos, for use by other modules.

Drupal for Firebug (http://drupal.org/project/drupalforfirebug)

Requires Firefox plugins Firebug and Drupal for Firebug.
Extends the Firefox Firebug module to provide Drupal specific debugging and status messages.

Devel (http://drupal.org/project/devel)

Requires Menu.
Various blocks, pages, and functions for developers.

Drush (http://drupal.org/project/drush)

Not a module, but makes site developers & upgraders very happy. (Stanford users: Drush is installed system-wide on corn.stanford.edu.) Provides "a command line shell and scripting interface for Drupal, a veritable Swiss Army knife designed to make life easier for those of us who spend some of our working hours hacking away at the command prompt."

SimpleTest (http://drupal.org/project/simpletest)

Provides a framework for unit and functional testing.

Security Review (http://drupal.org/project/security_review)

Provides site security and configuration review assistance. (Stanford users: Note that Security Review does not take into account AFS-specific file protection, and so may flag as insecure files that are actually properly protected under AFS.)

Hacked! (http://drupal.org/project/hacked)

"Scans the currently installed Drupal, contributed modules and themes … and determines if they have been changed." In other words, helps you figure out where exactly the previous site developer** changed code they shouldn't have. (**You & I, of course, have never hacked core, cough, cough…)

Modules for access control & publishing

Module Grants (http://drupal.org/project/module_grants)

Enables access control for unpublished content and allows modules that operate on access grants to work together in the expected way.

Rules (http://drupal.org/project/rules)

Lets you define conditionally executed actions based on occurring events. List of additional modules that provide actions for Rules: http://groups.drupal.org/rules/rules-modules

Workflow (http://drupal.org/project/workflow)

Allows the creation and assignment of arbitrary "workflow states" to node types. Optionally allows content access control based on these states and roles.

Organic groups, aka OG (http://drupal.org/project/og)

Enable users (or site builders) to create and manage groups (or semi-independent site sections). Groups may be private, public, or include a mixture of the two. List of (many, many) related modules: http://drupal.org/project/modules?filters=tid%3A90&solrsort=sis_project_release_usage%20desc

Taxonomy Access Control (http://drupal.org/project/taxonomy_access)

Requires Taxonomy.
"Access control for user roles based on taxonomy categories (vocabulary, terms)."

Content Access (http://drupal.org/project/content_access)

"This module allows you to manage permissions for content types by role and author. It allows you to specifiy custom view, edit and delete permissions for each content type. Optionally you can enable per content access settings, so you can customize the access for each content node."

Shibboleth authentication (http://drupal.org/project/shib_auth)

"Provides user authentication with Shibboleth (both v1.3 and v2.0) as well as some authorisation features (automatic role assignment based on Shibboleth attributes)." At Stanford, can be used to log in with SUNet IDs at least on non-AFS sites. At Davis, may be useable to log in with CAS authentication.

Stanford specific: WebAuth Module for Drupal, aka WMD (https://wmd.stanford.edu/)

Allows users to login and automatically create accounts using their SUNet IDs, via Stanford's WebAuth authentication. Includes optional access control by role per node.

Modules for revision control

Revisioning (http://drupal.org/project/revisioning)

Requires Module Grants.
Allows the creation and modification of content while the current revision remains unchanged and publicly visible until the changes have been reviewed by a moderator.

Diff (http://drupal.org/project/diff)

Highlights differences between node revisions.

Modules for uploading & including images & documents

For images and (links to) files in their own fields

FileField (http://drupal.org/project/filefield)

Requires CCK.
Defines a file field type for CCK and enables uploading files.

ImageField (http://drupal.org/project/imagefield)

Requires CCK, FileField.
Defines an image field type for CCK and improves uploading images.

For images and (links to) files in general text fields (e.g., Body)

WYSIWYG Filter (http://drupal.org/project/wysiwyg_filter)*

"Provides an input filter that allows site administrators to configure which HTML elements, attributes and style properties are allowed" (based on whitelists). This lets administrators permit content editors to include images in general text fields without giving them access to Full HTML. (Allowing Full HTML is a security risk and just generally a Bad Idea.)

IMCE (http://drupal.org/project/imce)

Provides an image/file uploader and browser supporting personal directories and user quota.

IMCE Wysiwyg bridge, aka IMCE Wysiwyg API bridge (http://drupal.org/project/imce_wysiwyg)

Requires IMCE, Wysiwyg.
Makes IMCE available as plugin for rich text editors integrated via Wysiwyg.

IMCE Mkdir (http://drupal.org/project/imce_mkdir)

Requires IMCE.
Allows users to manage directories in IMCE

For using both approaches together

Insert (http://drupal.org/project/insert)*

 

Adds a button to FileField and ImageField widgets so images and links to files may be inserted into general text fields. When used with ImageField and ImageCache, images may be inserted into text areas with a specific ImageCache preset.

FileField Sources (http://drupal.org/project/filefield_sources)

Requires CCK, FileField.
Extends FileField to allow referencing existing files, remote files, and server files.

For additional image and file assistance

ImageCache (http://drupal.org/project/imagecache)

Requires ImageAPI.
Provides dynamic image manipulator and cache. Allows automatic generation (and re-generation) of thumbnails and the like.

ImageAPI (http://drupal.org/project/imageapi/)

Provides an image API supporting multiple toolkits.

Transliteration (http://drupal.org/project/transliteration)

Converts non-latin text to US-ASCII and sanitizes file names.

Modules providing Tokens

Token (http://drupal.org/project/token)

Provides a shared API for replacement of textual placeholders with actual data.

FileField Paths (http://drupal.org/project/filefield_paths)

RequiresCCK, Token, FileField.
Adds node tokens to FileField.

ImageField Tokens (http://drupal.org/project/imagefield_tokens)

Requires CCK, Token, FileField, FileField Paths, ImageField.
Adds node tokens to ImageField's ALT and Title text fields.

Modules for URLs, aliases, paths, and links

Pathauto (http://drupal.org/project/pathauto)

Requires Path, Token.
Provides a mechanism for modules to automatically generate URL aliases for the content they manage. Human-friendly URLs (e.g.,"about" rather than "node/72") are important for accessibility, usability, and SEO.

Path redirect (http://drupal.org/project/path_redirect)

Redirects users from one URL to another. When used with Pathauto, provides a new "Update Action" for when URL aliases change (e.g., when a node's title is changed). This is the recommended update action and is considered the best practice for SEO and usability.

Elements (http://drupal.org/project/elements)

Provides a library of Form API elements for use by other modules. For example, it improves Path redirect's administration screen with checkboxes, a select-all checkbox, and bulk operations.

Global Redirect (http://drupal.org/project/globalredirect)

Searches for an alias of the current URL and 301 redirects if found. Stops duplicate content arising when Path module is enabled.

Link checker (http://drupal.org/project/linkchecker)

Periodically checks for broken links in node types, blocks and cck fields and reports the results.

Pathologic (http://drupal.org/project/pathologic)

Requires Filter.
Helps avoid broken links and incorrect paths in general text fields (e.g., Body, etc.). These tend to arise when full URLs ("http://sample.edu/about") or relative path URLs ("about") are used in general text fields instead of absolute path URLs ("/about") for internal content.

Linkit (http://drupal.org/project/linkit)

Needs Pathologic and Wysiwyg or CKEditor.
"Linkit provides an easy interface for internal linking" in general text fields (e.g., Body, etc.).

Linkit Picker (http://drupal.org/project/linkit_picker)

Requires Linkit, Views.
Extends Linkit with views listing existing internal content for selection (like Node Picker had).

Modules for dates & events

Date (http://drupal.org/project/date)

Requires CCK. Recommends jQuery UI for popup calendars and time entry widgets.
Defines CCK date/time fields and widgets. What makes this module essential is that it also provides a Date API submodule that provides superior date & time handling than in Drupal core.

jQuery UI (http://drupal.org/project/jquery_ui)

Requires installation of (non-Drupal specific) jQuery UI library
Provides the (non-Drupal) jQuery UI plug-in to other Drupal modules.

Calendar (http://drupal.org/project/calendar)

Requires Views, CCK, Date.
Enables displaying views containing dates as Calendars.

Modules to enhance CCK

All these modules require CCK.

Additional field types

Date (http://drupal.org/project/date)

Recommends jQuery UI for popup calendars and time entry widgets.
Defines CCK date/time fields and widgets. What makes this module essential is that it also provides a Date API submodule that provides superior date & time handling than in Drupal core.

FileField (http://drupal.org/project/filefield)

Defines a file field type for CCK and enables uploading files.

ImageField (http://drupal.org/project/imagefield)

Requires FileField.
Defines an image field type for CCK and improves uploading images.

Link (http://drupal.org/project/link)

Defines link field types. These allow association of a link title with a link URL, while permitting either to be optional.

Email Field (http://drupal.org/project/email)

Defines an email field type for CCK

Phone (CCK) (http://drupal.org/project/phone)

Allows administrators to define a CCK field type for phone numbers.

Viewfield (http://drupal.org/project/viewfield)

Defines a field type that displays the contents of a view in a node.

Additional field widgets

Multiselect (http://drupal.org/project/multiselect)

Defines a CCK multiple selection field widget, to allow easier multi-selection for users. [Accessibility still needs to be evaluated (e.g, by John Foliot of SOAP).]

Autocomplete Widgets (http://drupal.org/project/autocomplete_widgets)

Provides autocomplete widgets for CCK text and number fields.

Modules to enhance Views

All these modules require Views.

Views Bulk Operations (http://drupal.org/project/views_bulk_operations)

Exposes new Views style 'Bulk Operations' for selecting multiple nodes and performing actions on them.

Three different approaches to displaying views with/in individual nodes:

Views attach (http://drupal.org/project/views_attach)

Provides new Views display types that can be attached to nodes or users.

Viewfield (http://drupal.org/project/viewfield)

Requires CCK.
Defines a field type that displays the contents of a view in a node.

Insert View (http://drupal.org/project/insert_view)

Currently only a dev version available.
Input filter which allows to embed views in general text (e.g., Body, etc.).

Modules for references/citations

Bibliography Module, aka Drupal Scholar (http://drupal.org/project/biblio)

Requires Taxonomy
Allows users to manage and display lists of scholarly publications. Includes import from and export to various standard bibliographic programs and formats. It is integrated with Taxonomy, but, unfortunately, not CCK —even so, the advantages usually outweight the disadvantages for bibliographic content.

Footnotes (http://drupal.org/project/footnotes)

Add automatically numbered footnotes to your posts. Independent of Bibliography, but works well with it.

Major modules for which a quick summary can't do justice

Organic groups, aka OG (http://drupal.org/project/og)

Enable users (or site builders) to create and manage groups (or semi-independent site sections). Groups may be private, public, or include a mixture of the two. List of (many, many) related modules: http://drupal.org/project/modules?filters=tid%3A90&solrsort=sis_project_release_usage%20desc

Panels (http://drupal.org/project/panels)

Requires Chaos tool suite.
"Allows a site administrator to create customized layouts for multiple uses" from within Drupal, using a drag and drop interface.

Panels Everywhere (http://drupal.org/project/panels_everywhere)

Requires Chaos tool suite.
An "advanced method to [replace] Drupal's … blocks system and instead use the … Panels Layout system to control how your pages look."

Miscellaneous

Chaos tool suite (http://drupal.org/project/ctools)

A library of helpful tools by Merlin of Chaos, for use by other modules.

Google Analytics (http://drupal.org/project/google_analytics)

Requires a Google Analytics account.
Adds Google Analytics javascript tracking code to your site's pages.

Feeds (http://drupal.org/project/feeds)

Requires Chaos tool suite.
Aggregates RSS/Atom/RDF feeds, imports CSV files and more. If there is content outside of your site that you'd like to either import into or display on your site, take a look at Feeds.

Storm (http://drupal.org/project/storm)

"Offers a hierarchy of content types to help with project management. Organizations, Teams, People, Projects, Tasks, Tickets, Timetrackings, Notes, Knowledgebase, Invoices, and Expenses."

Webform (http://drupal.org/project/webform)

Enables the creation of forms and questionnaires.

Flag (http://drupal.org/project/flag)

Create customized flags that users can set on content.

Printer, e-mail and PDF versions (http://drupal.org/project/print)

Adds a printer-friendly version link to content and administrative pages. Creates a printer-friendly version of content with more than just formatting differences. For example, it automatically creates footnotes for links indicating the URL.

Custom Breadcrumbs (http://drupal.org/project/custom_breadcrumbs)

Allows administrators to define custom breadcrumb trails for each node type.

Submitted By (http://drupal.org/project/submitted_by)

Requires Token.
Customize the Submitted by username on date text on a per-nodetype basis.

Modules to keep techie nerds happy

BUEditor (http://drupal.org/project/bueditor)

A plain textarea editor aiming to facilitate code writing.

GeSHi Filter for syntax highlighting (http://drupal.org/project/geshifilter)

Requires installation of (non-Drupal specific) GeSHi library.
Provides a filter to highlight source code using the GeSHi library (Generic Syntax Highlighter)

University-specific contributed modules & themes

UC Davis

(CAS login required for some of these pages.)

UCD Drupal Theme (http://drupal.ucdavis.edu/ucd_theme)

A Drupal version of the UC Davis web design.

Stanford University

(SUNet ID login required for some of these pages.)

Reverse Proxy (https://techcommons.stanford.edu/node/231)

Provides URL rewrites for integrating Drupal with Stanford's Virtual Host Service, aka "Vanity URLs" (http://vanityurl.stanford.edu/). Only works for sites in AFS space.

WebAuth Module for Drupal, aka WMD (https://wmd.stanford.edu/)

Allows users to login and automatically create accounts using their SUNet IDs, via Stanford's WebAuth authentication. Includes optional access control by role per node

Stanford Modern Drupal Theme (https://www.stanford.edu/services/web/design/templates/modern/app_skins.html)

A Drupal version of "Stanford’s current home site design (as of August 2008) for use by University schools, academic departments, research centers, administrative units, and other official groups and programs. … provided to help promote a common look and feel across the institution’s web presence and to aid Stanford web professionals with the design process."

Contributed modules to replace optional core modules

• Use Rules instead of Trigger (trigger)
• Use FileField and/or IMCE instead of Upload (upload)
• Use Feeds instead of Aggregator (aggregator)
• Use Webform instead of Poll (poll)

Modules to avoid

CAPTCHAs

CAPTCHA (http://drupal.org/project/captcha), ReCAPTCHA (http://drupal.org/project/recaptcha), and any other flavor of CAPTCHA module including those that ask questions instead of using images/sounds.

CAPTCHAs of all kinds are inherently inaccessible to various groups of people, and, further, discourage participation even by those who have no disabilities or limitations. [Note that modules that merely hide CAPTCHAs from sighted users, like BOTCHA (http://drupal.org/project/botcha), are still a problem and should be avoided.]

When posting is restricted to known authenticated users, you shouldn't need anything at all.

Otherwise, if actually having spam problems, consider Akismet (http://akismet.com/)—via the AntiSpam module (http://drupal.org/project/antispam)—or Mollom (http://drupal.org/project/mollom) or a similar service. (Mollom still involves CATCHPAs, unfortunately, but only if it can't make a determination based on text analysis and/or user reputation. In practice, though, most legitimate users never see the CATCHPA with Mollom.)

Any modules where you enter PHP

Content Templates, aka Contemplate (http://drupal.org/project/contemplate) While very useful for site developers seeking more control over content presentation, these templates use PHP code and so increase the difficulty level for future administrators. When this level of control really is needed, a better approach is to make use of custom theming (subthemes) and/or modules.

Same goes for any other module or submodule (or option within a module) that involves entering PHP code through the Drupal interface. If you truly need to use PHP, then you truly need to either create/edit a subtheme or else write a custom module.

Yes, this means you should always leave the optional core module PHP filter disabled! (In any case, allowing users to use PHP is even more of a security risk than allowing them to use Full HTML. Just Don't Do It.)

Some resources

• Sacramento Area Drupal User Group: http://groups.drupal.org/sacramento-area
• UC Davis Drupal resources: http://drupal.ucdavis.edu
• Stanford Drupal resources: http://drupal.stanford.edu
• Drupal contributed modules sorted by site usage stats: http://drupal.org/project/usage
• Drupallets blog: http://sharonkrossa.com/drupallets
  (where this document and other helpful Drupal ramblings have a permanent home)