Upgrade Your Drupal Skills

We trained 1,000+ Drupal Developers over the last decade.

See Advanced Courses NAH, I know Enough
Oct 13 2014
Oct 13

A whirlwind tour of dozens of useful contributed modules for building Drupal 7 sites.

There are many really useful contributed modules to take your site beyond the basics of Drupal core. There are modules to improve, allow, and/or help with everything from administration to workflow, from paths to views, and beyond.

One factor to consider when choosing contributed modules is the recommendations of other experienced Drupallers. So in the list below I've noted some Drupal-as-a-Service (DaaS) platforms that have included a module in their service, which is essentially groups of experienced Drupallers indicating they find a module useful (and reliable enough) for a very large number of sites. I've also noted when at least some of a module's features are part of core in Drupal 8, which is an indication that very senior indeed Drupallers consider it useful for most sites.

  • (This functionality is part of core in Drupal 8.) indicates some/all of module's functionality is part of core in Drupal 8.
  • (This module is included in Stanford Sites.) indicates module is included in Stanford Sites.
  • (This module is included in Drupal Gardens.) indicates module was included in the late, lamented Drupal Gardens.

A key principle of module usage is to use as many as you need, but no more. Some of the modules (or their submodules) listed below are really useful when you are building or configuring the site, but don't need to be enabled for just visiting it or editing its content and so should normally be disabled on live/production sites.

  • (This module should only be enabled on live/production site if truly required by content editors.) indicates module should only be enabled on live/production site if truly required by content editors.

Essentials

These are modules that I install on essentially every site I build.

Administration menu (drupal.org/project/admin_menu(This module is included in Stanford Sites.) Provides a dropdown menu to most administrative tasks and other common destinations (to users with the proper permissions). (Don't forget to disable the core Toolbar module when using this.) Administration views (drupal.org/project/admin_views) (This functionality is part of core in Drupal 8.) (This module is included in Stanford Sites.) Requires Views, Views Bulk Operations, Chaos Tool Suite, Entity API.
"Replaces administrative overview/listing pages with actual views for superior usability" —in other words, you can customize them! Advanced help (drupal.org/project/advanced_help(This module is included in Stanford Sites.) Displays advanced help and documentation. Many contributed modules' help and documentation are primarily available through this module. (This module should only be enabled on live/production site if truly required by content editors.) Chaos tool suite (drupal.org/project/ctools) (This functionality is part of core in Drupal 8.) (This module is included in Stanford Sites.) (This module is included in Drupal Gardens.) A helper module required by Administration views, Views and a number of other modules. Date (drupal.org/project/date) (This functionality is part of core in Drupal 8.) (This module is included in Stanford Sites.) (This module is included in Drupal Gardens.) Provides "a flexible date/time field type (Date field) and a Date API that other modules can use." Entity API (drupal.org/project/entity(This module is included in Stanford Sites.) (This module is included in Drupal Gardens.) Required by Administration views and Views bulk operations.
Extends the entity API of Drupal core in order to provide a unified way to deal with entities and their properties. Libraries API (drupal.org/project/libraries(This module is included in Stanford Sites.) (This module is included in Drupal Gardens.) Provides a common repository for external (non-Drupal) libraries in sites/all/libraries and sites//libraries for use by contributed modules. Module filter (drupal.org/project/module_filter(This module is included in Stanford Sites.) Tames the modules list page, so you can quickly find the module you are looking for without tons of scrolling or having to rely on the browser's search feature. (This module should only be enabled on live/production site if truly required by content editors.) Pathauto (drupal.org/project/pathauto(This module is included in Stanford Sites.) (This module is included in Drupal Gardens.) Requires 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. Pathologic (drupal.org/project/pathologic(This module is included in Stanford Sites.) A filter that 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. Redirect (drupal.org/project/redirect(This module is included in Stanford Sites.) (This module is included in Drupal Gardens.) Redirects users from one URL to another. When used with Pathauto, "automatically generates path redirects to ensure that URL alias changes do not break existing links." This is considered the best practice for SEO and usability. Token (drupal.org/project/token(This module is included in Stanford Sites.) (This module is included in Drupal Gardens.) The basic token API is now a part of Drupal 7 core, but this module provides a browsable token UI, as well as field & profile tokens that did not make it into core for Drupal 7. Transliteration (drupal.org/project/transliteration(This module is included in Stanford Sites.) Provides a central transliteration service (converting Unicode text to US-ASCII) to other Drupal modules (e.g., Pathauto), and sanitizes file names while uploading. Views (drupal.org/project/views) (This functionality is part of core in Drupal 8.) (This module is included in Stanford Sites.) (This module is included in Drupal Gardens.) Requires Chaos tool suite.
Required by Administration views and Views bulk operations.
Creates customized lists and displays from already entered content. Along with fields, 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, fields & 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.) Submodules include views_ui (This module should only be enabled on live/production site if truly required by content editors.) Views Bulk Operations (drupal.org/project/views_bulk_operations(This module is included in Stanford Sites.) (This module is included in Drupal Gardens.) Requires Views and Entity API.
Required by Administration views.
Exposes new Views style 'Bulk Operations' for selecting multiple nodes and performing actions on them all at once. Wysiwyg (drupal.org/project/wysiwyg) (This functionality is part of core in Drupal 8.) (This module is included in Stanford Sites.) (This module is included in Drupal Gardens.) Requires installation of (non-Drupal) editor libraries.
Allows users to edit contents with rich text editors such as CKeditor (This functionality is part of core in Drupal 8.) and TinyMCE. Permits inclusion of more than one rich text editor in the same site. Wysiwyg filter (drupal.org/project/wysiwyg_filter(This module is included in Stanford Sites.) "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.)

Frequently used

These are modules I install on many sites, but not all of them need the functionality provided.

Fields

Address Field (drupal.org/project/addressfield)"Defines a new field type to store international postal addresses, implementing a subset of the top-level address elements defined in the xNAL standard"Automatic entity label (drupal.org/project/auto_entitylabel) Allows automatic generation of entity label fields, such as node titles. (Replaces Automatic node titles module.) Email field (drupal.org/project/email) (This functionality is part of core in Drupal 8.) (This module is included in Stanford Sites.) Provides a field type for email addresses. Entity Reference (drupal.org/project/entityreference) (This functionality is part of core in Drupal 8.) (This module is included in Stanford Sites.) (This module is included in Drupal Gardens.) Requires Entity API and Chaos tool suite.
Provides a field type that can reference arbitrary entities (nodes, etc.). Can display the field either as a link to the entity or as a rendered entity (for example, it can show either a link to a node or the node itself).Field collection (drupal.org/project/field_collection) (This module is included in Stanford Sites.) (This module is included in Drupal Gardens.)Field Group (drupal.org/project/field_group(This module is included in Stanford Sites.) Link (drupal.org/project/link) (This functionality is part of core in Drupal 8.) (This module is included in Stanford Sites.) (This module is included in Drupal Gardens.) Provides a link field type. This allows association of a link title with a link URL, while permitting either to be optional.Smart trim (drupal.org/project/smart_trim(This module is included in Stanford Sites.)

Views

Better exposed filters (drupal.org/project/better_exposed_filters(This module is included in Stanford Sites.) "[R]eplaces the Views' default single- or multi-select boxes with radio buttons or checkboxes, respectively. Description fields and Select All/None links can be added to exposed filters to make for a better user experience." Calendar (drupal.org/project/calendar(This module is included in Stanford Sites.) Enables displaying views containing date fields in calendar formats. Can display information by day, week, month, or year in either pages or blocks. Date iCal (drupal.org/project/date_ical(This module is included in Stanford Sites.)"provides a plugin for Views to enable exporting your site's calendar as an iCal feed, and a plugin for Feeds to enable importing external iCal feeds into your site's calendar."EVA: Entity Views Attachment (drupal.org/project/eva)"Provides a Views display plugin that allows the output of a View to be attached to the content of any Drupal entity", such as a node, user profile, comment, etc.Views data export (drupal.org/project/views_data_export(This module is included in Stanford Sites.) Provides a way to export data from views to CSV, Microsoft XLS, Microsoft DOC, plain TXT, or XML. Views Datasource () (This module is included in Stanford Sites.)Views field view (http://drupal.org/project/views_field_view(This module is included in Stanford Sites.) Allows users to embed a view as a field in a view. A new field handler is made available, so this can also be used in area (header/footer/empty) handlers as well as rows.Views slideshow (http://drupal.org/project/views_slideshow(This module is included in Stanford Sites.)"Views Slideshow can be used to create a slideshow of any content (not just images) that can appear in a View." 

Blocks

Bean (drupal.org/project/bean(This module is included in Stanford Sites.) Allows the definition of block types (like content types, only for blocks instead of nodes). This has various benefits, including making it easy to add distinct fields to blocks, use WYSIWYG editors for block content, and the like. Block class (drupal.org/project/block_class(This module is included in Stanford Sites.) Lets site builders add CSS classes to any block through the block's configuration interface. This lets you really take advantage of the block-centric responsive design of themes like Open Framework and Stanford Framework. Block title link (drupal.org/project/block_titlelink(This module is included in Stanford Sites.) Allows site builders to turn a block's title into a link.Menu block () (This module is included in Stanford Sites.)

Context

Context (drupal.org/project/context(This module is included in Stanford Sites.)Allows site builders more fine-grained control over what is shown, where it is shown, and how it is shown ("reactions") on any given page based on a much wider and more flexible range of criteria/"conditions" than Drupal core. There is a lot of power in this module: with it you can have the same block show up in the header of one page but in the footer of others or have different themes depending on the path and much, much more. Context accordion (drupal.org/project/context_accordion(This module is included in Stanford Sites.) Requires Context
Improves the user interface (UI) of the Context module by adding a nice javascript accordion effect.Context HTTP headers (drupal.org/project/context_http_headers) (This module is included in Stanford Sites.)Requires Context
"Provides a set of Context reactions that allow you to set HTTP Response Headers for each context on your site. It is a generalized framework for response header handling that allows the sending of any arbitrary header value(s)." You can thank Whitehouse.gov for this one! Context list (drupal.org/project/context_list(This module is included in Stanford Sites.)Requires Context
Improves the administration experience of the Context module by providing "a list of contexts, their conditions and reactions in a simple view … The intention of this module is to provide a means of inspecting all contexts in one easy screen." Context list active (drupal.org/project/context_list_active(This module is included in Stanford Sites.)Requires Context
Like the Context list module, but lists the contexts, conditions, and reactions only for the current page. Context respect (drupal.org/project/context_respect(This module is included in Stanford Sites.)Requires Context
"Extends the Context module by making it respect default block settings. This makes it so you can retain your block visibility when assigning them into various Contexts." Context user agent (drupal.org/project/context_useragent(This module is included in Stanford Sites.)Requires Context
"Adds a new condition to the Context module that allows performing regular expression tests on the useragent string ($_SERVER['HTTP_USER_AGENT']). This allows adding different reactions based on the user's browser, operating system, or other needed contexts that may be found in the useragent string."  Delta (drupal.org/project/delta(This module is included in Stanford Sites.) Requires Context
Allows site builders "to make duplicates of your theme settings for any context on your site. This gives you the ability for alternative layouts as a reaction in Context" Contextual Block Class(es) (drupal.org/project/cbc(This module is included in Stanford Sites.)Requires Context
Allows site builders "to contextualize block classes" 

Appearance/Theme

Colorbox (drupal.org/project/colorbox) (This module is included in Stanford Sites.) (This module is included in Drupal Gardens.)CSS injector (drupal.org/project/css_injector(This module is included in Stanford Sites.)Allows site builders to add new CSS (and override the theme's CSS) without editing (or even access to) the theme's files on the server. Display suite (drupal.org/project/ds(This module is included in Stanford Sites.) "[A]llows you to take full control over how your content is displayed using a drag and drop interface. Arrange your nodes, views, comments, user data etc. the way you want" by defining custom view modes. Site builders can define how one piece of content should be displayed in different places such as teaser lists, search results, the full node, views, etc."JS injector (drupal.org/project/js_injector) (This module is included in Stanford Sites.)Like CSS injector, only for JavaScript (SJ).

Development

Bundle copy (drupal.org/project/bundle_copy(This module is included in Stanford Sites.) Allows administrators to export and import content types and other entity definitions (taxonomy, user, field definitions, field groups). This is great for sharing structures between sites, instead of rebuilding them by hand each time. (Note, it does not import/export the content/data, just the structure/definitions.)Features (drupal.org/project/features) (This module is included in Stanford Sites.)"Enables the capture and management of features in Drupal. A feature is a collection of Drupal entities which taken together satisfy a certain use-case."Strongarm () (This module is included in Stanford Sites.)

Data Import

Feeds (drupal.org/project/feeds(This module is included in Stanford Sites.) "Import or aggregate data as nodes, users, taxonomy terms or simple database records." Feeds JSONPath Parser (drupal.org/project/feeds_jsonpath_parser(This module is included in Stanford Sites.)Feeds Tamper (drupal.org/project/feeds_tamper) (This module is included in Stanford Sites.)Feeds XPath Parser (drupal.org/project/feeds_xpathparser) (This module is included in Stanford Sites.)Path redirect import () (This module is included in Stanford Sites.)

Files and Images

File entity (fieldable files) (drupal.org/project/file_entity(This module is included in Stanford Sites.)"File entity provides interfaces for managing files. It also extends the core file entity, allowing files to be fieldable, grouped into types, viewed (using display modes) and formatted using field formatters."File (Field) Paths (drupal.org/project/filefield_paths(This module is included in Stanford Sites.)Requires Token. 
Adds the ability to use node tokens in destination paths and filenames. FileField Sources (drupal.org/project/filefield_sources) Extends file and image fields to allow referencing existing files, remote files, and server files.Insert (drupal.org/project/insert(This module is included in Stanford Sites.)Adds a button to file and image fields so images and links to files may be inserted inline into general text fields (e.g., the Body field).

Other

Backup and migrate ( drupal.org/project/backup_migrate (This module is included in Stanford Sites.) "Back up and restore your Drupal MySQL database, code, and files or migrate a site between environments. Backup and Migrate supports gzip, bzip and zip compression as well as automatic scheduled backups." [I use this when I can't use shell scripts in the command line on the server.] Better formats (drupal.org/project/better_formats(This module is included in Stanford Sites.) Adds more flexibility and control to Drupal's core text format system. It allows site builders to: set allowed text formats and/or default order of text formats per field; hide format tips and/or hide more format tips link per role; and hide format selection per role per entity. Bibliography module (drupal.org/project/biblio(This module is included in Stanford Sites.) For managing and displaying lists of scholarly publications, including importing from PubMed, BibTex, RIS, MARC, EndNotee and XML and exporting to BibTex, EndNote, and XML. Output styles include AMA, APA, Chicago, CSE, MLA and others. Content Access (drupal.org/project/content_access(This module is included in Stanford Sites.) Allows granular control of access to content by content types and, optionally, specific nodes by role and author, by specificing independent view, edit and delete permissions. Custom breadcrumbs (drupal.org/project/custom_breadcrumbs(This module is included in Stanford Sites.)"Allows you to create and modify your own breadcrumbs based on node type." (Breadcrumbs are that trail of links indicating the way to your current page, usually displayed just above or below the page title.) Diff (drupal.org/project/diff(This module is included in Stanford Sites.) "[A]llows pretty viewing of all added/changed/deleted words between revisions." Drupal Commerce (drupal.org/project/commerce)Flag () (This module is included in Stanford Sites.) (This module is included in Drupal Gardens.)Google analytics (drupal.org/project/google_analytics(This module is included in Stanford Sites.) (This module is included in Drupal Gardens.) "Adds the Google Analytics web statistics tracking system to your website."Inline entity form ()"Provides a widget for inline management (creation, modification, removal) of referenced entities. … Existing entities can also be referenced." This solves the chicken or egg problem for referencing content that hasn't been created yet!Job Scheduler (drupal.org/project/job_scheduler) (This module is included in Stanford Sites.)An API (helper module) "for scheduling tasks once at a predetermined time or periodically at a fixed interval."JW Player() (This module is included in Stanford Sites.) Link checker (drupal.org/project/linkchecker) Periodically checks for broken links in node types, blocks and cck fields and reports the results.Menu position () (This module is included in Stanford Sites.)Metatag () (This module is included in Stanford Sites.) (This module is included in Drupal Gardens.)Mollom () (This module is included in Stanford Sites.) (This module is included in Drupal Gardens.)Node clone () (This module is included in Stanford Sites.)Node convert (drupal.org/project/node_convert(This module is included in Stanford Sites.) (This module should only be enabled on live/production site if truly required by content editors.)Node form columns () (This module is included in Stanford Sites.)Panels ()Relation () (This module is included in Stanford Sites.) Rules (drupal.org/project/rules) (This module is included in Stanford Sites.) Lets you define conditionally executed actions based on occurring events. In other words, add logic/processing without having to code a custom module. Also required/used by many other modules. Services () (This module is included in Stanford Sites.)Site verification () (This module is included in Stanford Sites.) (This module is included in Drupal Gardens.)Taxonomy manager () (This module is included in Stanford Sites.)Universally Unique IDentifier () (This module is included in Stanford Sites.)Webform () (This module is included in Stanford Sites.) (This module is included in Drupal Gardens.)Workbench (drupal.org/project/workbench) (This module is included in Stanford Sites.) Workbench access (drupal.org/project/workbench_access) (This module is included in Stanford Sites.) Workbench moderation (drupal.org/project/workbench_moderation) (This module is included in Stanford Sites.) XML sitemap (drupal.org/project/xmlsitemap) (This module is included in Stanford Sites.) (This module is included in Drupal Gardens.)
May 05 2012
May 05

Or: The What, When, Where, Why, and especially How

Versions of this talk has been presented at:

What are modules?

Drupal is designed to be modular. Instead of always having every possible tool or feature in every site's code, you can just have those you're actually going to use.

Drupal core —what you get when you install Drupal— is like a very basic box of Lego™: a platform and some basic bricks (modules) to get you started. You can do a lot with just those basics, but usually you'll want more.

That's where contributed modules come in. Contributed modules are packages of code that extend or enhance Drupal core to add additional (or alternate) functionality and features. These modules have been "contributed" back to the Drupal community by their authors.

When should you use contributed modules?

"The Drupal Way" can be summed up as both "Don't re-invent the wheel" and "Share and share alike". Although you may be perfectly capable of writing your own custom module to add some feature/functionality to your Drupal site, you should always first check to see if there is an existing module that does (or nearly does) what you want.

Using contributed modules not only saves initial coding time, it also makes it significantly easier for you and, especially, others to maintain the site in the future. Contributed modules also benefit from multiple eyes and multiple users to find problems and improve code.

Where can you find contributed modules?

Contributed modules live on Drupal.org, specifically, at http://drupal.org/project/modules. You can search the module list and filter it by category, Drupal version, and status. You can also sort based on most installed, title, author, last release date, etc.

Why should you choose one module over another?

Choosing which contributed modules to use is an art. There isn't an easy list of objective criteria to be checked off. There are, however, various factors that should be weighed when evaluating modules:

  • Suitability for your purpose
  • Release status
  • Recommendations by experienced Drupallers
  • Usage statistics (http://drupal.org/project/usage/[module_name])
  • Issue queue (not just outstanding issues, but response time, etc.)
  • Development activity
  • Author & maintainers

For more about how to choose modules, see Karen Stevenson's excellent session at DrupalCon Munich 2012 There Might (Not) Be a Module for That.

How do you install modules (step-by-step)?

For both Drupal 6.x and Drupal 7.x, there are just four major steps to adding a contributed module to a Drupal site:

  1. Upload the module code
  2. Enable the module
  3. Set permissions for the module
  4. Configure the module

The four steps in detail

  1. Upload the module code
    • Upload (install) the module's file directory into the sites/all/modules/ directory
    • Preferably, upload as a compressed archive (.zip, .tar.gz) and expand the archive on the server (rather than expanding on your desktop and uploading as a folder with individual files). This is both quicker and avoids potential problems with file permissions or invisible files not making the transition.
  2. Enable the module
    1. Go to the Modules administration page:
      • Drupal 6: Administer->Site building->Modules (/admin/build/modules).
      • Drupal 7: Modules (/admin/modules).
    2. Enable (check) the relevant module and sub-module(s), if any.
    3. Scroll down to the very bottom of the page and click the Save configuration button.
  3. Set permissions for the module
    1. Go to:
      • Drupal 6: Administer->Site building->Modules, then click Administration by Module page in the third paragraph down (/admin/by-module).
      • Drupal 7: Modules (/admin/modules).
    2. Find the relevant module.
    3. If present for that module:
      • Drupal 6: Click Configure permissions
      • Drupal 7: Click Permissions
    4. Set permissions as appropriate.
    5. Scroll down to the bottom of the page and click the Save permissions button.
  4. Configure the module
    1. Go to:
      • Drupal 6: Administer->Site building->Modules, then click Administration by Module page in the third paragraph down (/admin/by-module).
      • Drupal 7: Modules (/admin/modules)
    2. Find the relevant module.
    3. If present for that module:
      • Drupal 6: Click [Module name] settings and, in turn, any other link(s) (besides Configure permissions or Get help)
      • Drupal 7: Click Configure
    4. Configure as appropriate.
    5. Don't forget to Save any configuration changes!

How do you uninstall modules (step-by-step)?

For both Drupal 6.x and Drupal 7.x, there are just three major steps to removing a contributed module from a Drupal site:

  1. Disable the module
  2. Uninstall the module
  3. Delete the module code

The three steps in detail

  1. Disable the module
    1. Go to the Modules administration page:
      • Drupal 6: Administer->Site building->Modules (/admin/build/modules).
      • Drupal 7: Modules (/admin/modules).
    2. Disable (uncheck) the relevant module and sub-module(s), if any.
    3. Scroll down to the very bottom of the page and click the Save configuration button.
  2. Uninstall the module
    1. Return to the Modules administration page:
      • Drupal 6: Administer->Site building->Modules (/admin/build/modules).
      • Drupal 7: Modules (/admin/modules).
    2. Click the Uninstall tab.
    3. Select (check) the relevant module.
    4. Click the Uninstall button. 
    5. When asked "Would you like to continue with uninstalling the above?", confirm by clicking the Uninstall button.
  3. Delete the module code
    • Remove the module's file directory from the sites/all/modules/ directory
Mar 21 2012
Mar 21

(This is the second installment of a multipart series. The first installment was Hiring Drupal professionals, part 1: Know what you need.)

So, you're advertising/searching for the kind of Drupaller you need, now what? How can you know if you've found them?

This can be quite a challenge if you aren't very familiar with Drupal yourself. But the general principles are the same as for hiring any other kind of professional outside your own sphere of expertise. You want to look at their reputation, talk to references, check out their prior work, and watch for warning signs. Of course, there are some Drupal specific details for doing these things, too.

But before you can look at their reputation, prior work, and the like, first you need to know who they are. 

Who are they?

If they are an individual freelancer, do they use their own name in advertisements and on their website? If they use a company name, can you easily find out their real name on their website?

For a company, do they advertise under their company name? Can you easily find out the real names of those working for the company on their website? When checking reputations, you need to consider not only the reputation of the company as a whole, but also the reputation of the individuals associated with the company, especially those running the company and the individuals assigned to your project.

In short, you need to know who you're dealing with, and so should avoid any freelancer or company who is reluctant to let you know.

Who are they online?

If you haven't already found their professional or company website, ask for the URL. Ask if they have LinkedIn profiles, and if so, ask to see it. (If you can't see it without being in their network, ask to be connected, if only temporarily.) Ask if they have a professional Twitter account, and if so, what their Twitter handle/username is.

There are lots of good Drupallers who don't have LinkedIn profiles and/or professional Twitter accounts, but for those who do, checking them can help you confirm a positive impression (or improve a negative impression). 

Note that a pitiful website isn't necessarily a warning sign —the cobbler's children have no shoes and all that— but no website at all is strange for people who build websites for a living.

Who are they to Drupal?

Ask for their Drupal.org user number or a link to their Drupal.org user profile. (For example, my user number is 237528 and my profile can be found at http://drupal.org/user/237528). It is okay if they give you their Drupal.org username instead, though it requires more work on your part. (You can find a user's profile by searching for their username on Drupal.org and then, on the results page, clicking the "Users" link under "Or search for…".)

Not having a lot of activity on their Drupal.org account isn't necessarily a warning sign, but not having a Drupal.org account at all is strange for a professional Drupaller.

Warning signs

  • Advertising semi-anonymously, with only a phone number or first name and phone number. (For example, on Craig's List, stay away from ads that don't include either a company name or an individual freelancer's full name in the ad.)
  • No website. 
  • Website doesn't list any real names.
  • (Drupal specific) Won't tell you Drupal.org user number/profile link
  • (Drupal specific) Doesn't have a Drupal.org account

Now what?

So, you've advertised/searched for the kind of Drupaller you need and you know who the people who've responded are, now what? How can you know if any of these people are who you want? Stay tuned for the next installment in this series! (And I promise there won't be as big a gap between Part 2 and Part 3 as there was between Part 1 and Part 2!)

Jun 19 2011
Jun 19

I've been asked what I meant by "The Drupal Way" in my Drupallets blog post Hiring Drupal professionals, part 1: Know what you need.

In the Drupal community, "Drupal Way" is used in two related, erm, ways. The primary meaning is a general ethos or guiding philosophy, but it also gets used to refer to specific applications of that ethos. In my blog post, I was referencing the general principle, The Drupal Way, as a whole. But google "the drupal way" and you will find lots of hits talking about specific applications of the Drupal way, that is, the Drupal way to do X or the Drupal way to do Y.

The Drupal Way, the ethos, permeates every aspect of Drupal, from coding to content. It is the very essence of the Drupal community. It can be explained many different ways, but I like to boil it down to this:

Don't re-invent the wheel.

Or, put another way:

Share and share alike.

Drupal is not just open source; it is also modular by design. Thus it is not just licensed to share, it is designed to share —easily and flexibly— because by sharing (by not re-inventing the wheel) we all benefit. We can build better, more robust websites more quickly if we take advantage of one another's work than if we do everything ourselves from scratch.

This design and ethos goes beyond the mere existence of contributed modules to add features and functionality. If modules are like Lego bricks, the API(s) are the pegs that let you snap them together firmly to build your creation. Yes, you could lash some bricks together using duct tape, but the result just isn't going to be as good; further, it'll make it harder down the line to make improvements and updates.

Even more fundamental is Drupal's separation of visual appearance (themes) from structure/functionality (core & modules) from site content. Keeping these distinct makes sharing and reusing that much easier. For example, no need to build a whole new site structure and migrate all your content every time you want to totally change the site's visual appearance —just upload a new theme and click a few buttons.

And then there is content. I don't think it is a coincidence that CCK (Content Construction Kit, now in Drupal 7 core as fields) and Views were developed in Drupal. These contributed modules are simply —brilliantly— extensions of The Drupal Way to content. They, and various other Drupal modules as well, make it easy to enter content once but use it many times in many places in many different ways in your site. (For you relational database fans out there: think of a Drupal site as one gorgeous web-enabled relational database for your content. Or, as I heard someone put it: a Drupal site is essentially "things and lists of things". But more on that in another post…)

Finally, it should be noted that The Drupal Way is a guiding ethos, not rigid step-by-step instructions. Not re-inventing the wheel doesn't mean using the exact same wheel for every project. As often as you will hear "There's a module for that…" you will hear "There's different ways you can do that…"

So there you have it: Don't re-invent the wheel. This is the whole Drupal Way. The rest is commentary — and now go learn. (with apologies to Hillel…)

Update: Others' commentary on The Drupal Way

I'll be keeping an ongoing list of other good discussions of The Drupal Way (and/or not re-inventing the wheel). Please post or contact me if you know of any others!

Jun 06 2011
Jun 06

(This is the first installment of a multipart series.)

As a Drupal trainer and consultant, I've been getting a lot of phone calls lately either asking if I have trainees to recommend or else hoping that the "consultant" in my job title is a synonym for developer. (It's not: I'm the kind of consultant who helps you figure out what to do rather than the kind that does it for you.) People are having a really hard time finding experienced Drupallers to hire.

At the same time, I've become aware of more and more Drupal projects that went horribly awry because the freelancer or shop hired, though perfectly good PHP coders, didn't really know or understand Drupal. (In just in the last few months, I've personally had not one but two clients who were site-rescue refugees from the same freelancer!)

Unfortunately, the increasing popularity of Drupal can add up to a double whammy for those trying to hire Drupal help. Not only is there a shortage of experienced Drupallers, but there is an increasing number of inexperienced Drupallers offering their services. And these difficulties are compounded by the fact that many of those seeking to hire, quite naturally, don't know very much about Drupal.

So how do you find good Drupallers so your project actually gets the power, flexibility, and ease of use for content creators/managers that led you chose Drupal in the first place?

The first step is to ask for the right thing. There are different kinds of Drupal professionals and most clients and companies seeking to hire Drupallers don't understand or ask for the kind they need.

Besides end users, there are three broad categories of Drupallers: themers, site builders, and module developers. Of these, only module developers actually need to be PHP ninjas

Themers are responsible for the site's graphic design, which in Drupal is independent from the site structure and content. A Drupal site's entire visual design can be completely changed with literally just a couple mouse clicks. (For a demonstration of the independence of content and theme, visit Drupal Gardens —note how the content remains constant as you change from theme to theme.)

Themers come in two flavors: those who customize existing themes (subthemers) & those who create entirely new themes. Only the latter need significant PHP skills, but even then, graphic design and CSS mastery are much more important. For subthemers, PHP doesn't hurt, but isn't vital; often only custom CSS is needed.

Site builders put together the site's structure —the data types, displays, menus, navigation, entry forms, access control, administration, and other functionality for the site's content.

Site builders have even less need for mad PHP skills. Much more important is information architecture, usability, accessibility, and the like. Very complex, feature-rich Drupal sites can be built using only existing core and contributed modules. Indeed, while having familiarity with PHP can help, you actively do not want someone whose first instinct is to code to solve problems. For Drupal, custom PHP should be the last resort, not the first. Re-coding the wheel defeats the purpose and advantage of using Drupal!

If custom PHP is needed for a site —that is, if there is some functionality needed that can't be achieved using existing contributed modules— then it should go in a custom module, which is where module developers come in.

For module developers, of course, PHP is a must. But to be a good module developer, you also need to have good site building skills; you need to understand and appreciate The Drupal Way and also have mastery not just of PHP, but of the Drupal API (and certain contributed module APIs).

I should clarify that there aren't impenetrable divides between these three broad groups. Many themers are also site builders, many site builders are also at least subthemers, etc. and naturally there are various specializations that overlap or even fall somewhat outside these broad three, such as performance optimizers who get into server configuration, etc.

Unfortunately, clients and companies new to Drupal rarely know much about Drupal beyond that it is a CMS based on PHP and databases. So they understandably, but detrimentally, focus on the PHP bit, advertise for "Drupal developers", and emphasize PHP skills in their criteria.

But in a labor market where any kind of experienced Drupaller is in short supply and where there are more good site builders than good module developers, advertising for module developers (which is effectively what advertising for a "Drupal developer" with PHP skills is) when what you need is a good site builder is not the best recipe for success. Good site builders know when to bring in a themer or module developer, but trying to hire a module developer before you even know if you actually need one just frustrates everyone.

Worse, remember those decent PHP coders who don't really know Drupal? They tend to be attracted to "Drupal developer" positions that emphasize PHP skills, too. And that's how sites end up with custom PHP code that is not only totally unnecessary but located in the wrong place (e.g., hacked core/contributed modules or everything in a single theme page.tpl.php file instead of in a custom module where it belongs) and an unsustainable site that doesn't work properly.

You're much more likely to be successful finding and hiring a good Drupal professional if you know what kind you need and ask for it by name. If you're new to Drupal, start by looking for a "Drupal site builder" and emphasize Drupal knowledge and web best practices, not PHP skills. If you already have a site builder but need a graphics professional for your visual design, look for a "Drupal themer" and emphasize graphic design and CSS skills as well as Drupal theming knowledge. If you already have a site builder but determined that existing modules can't do what you need, then it's time to look for a "Drupal module developer" (not just a "Drupal developer") and emphasize Drupal module development knowledge, especially Drupal core and contributed module APIs and best practices.

So, you're advertising/searching for the kind of Drupaller you need, now what? How can you know if you've found them? See the next installment in this series: Hiring Drupal professionals, part 2: Know who they are

[Added 5 Jun 2012] Especially for larger projects, a more expansive discussion of the different roles involved in creating (Drupal) websites can be found in Randall Knutson's great blog post Why Web Development is Like Building a House over at LevelTen. (Just make sure to translate their use of "Developer" to "Site builder"!)

May 28 2011
May 28

Updated! This is the version that I presented at Drupal Camp Sacramento Area at 10 am on 28 May 2011, updated & expanded from the version I presented at DrupalCamp @ Stanford at 10 am on 2 April 2011.

Session description

More than three score and ten useful contributed modules for building Drupal sites.

There are many really useful contributed modules to take your site beyond the basics of Drupal core. There are modules to improve, allow, and/or help with everything from accessibility to workflow, from images to input formats, and beyond.

This session will be of interest to beginner and intermediate Drupallers, as well as those who manage or hire Drupallers or who are just trying to decide whether to use Drupal.

(This functionality is part of core in Drupal 7.) indicates some or all of the module's functionality is part of core in Drupal 7.

Apr 27 2011
Apr 27

In the LinkedIn group Drupal Community Network, there has been a discussion started by the question: "Drupal for a novice or newcomer? Good Bad , Ugly and why?"

This was my response to that question:

Drupal = good, whether novice or expert. The thing to remember is that novices don't stay novices. Why start with something "easy" just to have to start all over again with something else when you outgrow it? But you can't outgrow Drupal. Drupal will more than keep up with you as your site grows and as your knowledge grows.

A good part of why Drupal is (in)famous for having "a steep learning curve" is because when people hear of all the things Drupal sites can do, they tend to want their Drupal site to do those things, too. And they want to be able to do everything right away — but there is no system in the world that lets you do everything and anything —easily— right away.

Right out of the box, Drupal —even Drupal 6.x— can easily be used for a personal blog or basic news site. Add one of many free themes (just a matter of uploading & expanding a file and then clicking a few buttons), and it becomes an even better looking site. Start with Drupal 7.x (released in January) and it is even easier and nicer right out ofthe box.

But it is unreasonable to expect to be able to create complex sites like Whitehouse.gov or Grammy.com easily as a novice. Of course, if you are building such complex sites, it is easier to build them using Drupal than in anything else I'm aware of (which is more than a good part of why those sites were built with Drupal).

So, yes, Drupal is good —great, even— for a novice or newcomer, whether you're just new to Drupal or new to website building entirely. It is incredibly powerful, but you can start simply and learn as you go along.

As the discussion progressed, and as people shared their own experiences with Drupal and other CMSes, coding was mentioned. I've noticed a lot of discussions of the merits of various CMSes, especially Drupal, tend to get bogged down in discussions of coding, as if being able to code was essential to building websites using Drupal. This is not the case at all! As I noted in the discussion:

I build flexible, complex sites using Drupal 6.x and 7.x without touching any code at all. The few times I have done any coding, it was only in the subtheme. (Most of the time all that is needed for the subtheme is to change the CSS.)

Coding is a last resort in Drupal. "The Drupal Way" mainly comes down to: Don't re-invent the wheel.

So, with regard to coding, that means use existing contributed modules to add functionality. If you do have to create a custom module, do your best to contribute it back to the community -- if you needed that functionality, chances are others want that ability, too. Share and help others, as others are sharing and helping you, so everybody can avoid re-coding the wheel.

(The Drupal Way extends to structuring your site for content, too: sites can be and should be set up so users enter content once, and then it shows up in as many different places as desired, automagically.)

After some more talk of coding (which I contributed to —my bad!), Steve Ringwood made an excellent point:

There is a fair amount of talk of coding here. I like to encourage new folks to look at the "legos". Between content types, views, panels and others (I like the display suite) you can achieve a lot without any coding. I think it valuable to understand what you can do first, before writing code.

The Legos analogy really suits Drupal. In Drupal, just as with Legos, you can build very simple things (CayucosLioness.org) or you can build very complex things (MTV.co.uk). You can use just the original rectangular Lego bricks (Drupal core) or you can add specially shaped Lego parts for added functionality (contributed modules). You can even, if you want, mold your own pieces (custom modules —though I'd say the analogy breaks down a bit here, because it is much easier to write your own modules than mold your own Lego pieces!)

Yet despite the Lego professionals who build incredibly detailed custom models or even the Lego fans who build the large and complex Lego kits of the Taj Mahal, Tower Bridge, and the like, nobody talks about Legos having a "steep learning curve". To the contrary, we tend to think of Legos as a child's toy, suitable for 5 year olds!

Just like Legos, Drupal grows with you. And, like Legos, your imagination is the only limit to what you can build with Drupal —including building simple websites easily.

So let's stop perpetuating this false notion that Drupal has a "steep learning curve". Drupal is Lego. Come play!

About Drupal Sun

Drupal Sun is an Evolving Web project. It allows you to:

  • Do full-text search on all the articles in Drupal Planet (thanks to Apache Solr)
  • Facet based on tags, author, or feed
  • Flip through articles quickly (with j/k or arrow keys) to find what you're interested in
  • View the entire article text inline, or in the context of the site where it was created

See the blog post at Evolving Web

Evolving Web