Archive for May, 2009

Drupal CMS Alignment with Best Practices

One of the things I fear when working with a developer is that they will claim to be as someone around here did to be a “code monkey.” Good Web site development and campaign delivery is not about creating code. It is about utilizing best practices to provide the best user experience. Those who solely want to work on the code level often miss the forest through the trees

Each CMS must be configured to align with marketing, user interface and other best practices. The following provides for common best practices that should be noted for attention with the Drupal CMS configuration. These items are included in this document to confirm the configuration as the technical defaults are often focused on specific functionality rather than such general best practices

Start Here

A great list of best practices in an easy to read format is available here: Rather than recreate those items, just start and there and then come back to this document for more.

Installation Package

The Drupal core package for download from has the most basic set of core files and modules. This is always supplemented with additional modules. Use of the Acquia Drupal package distribution from can provide a simplified install with a large number of the modules that would have to otherwise be individually installed. This provides the entire core Drupal functions with added services from Acquia. The services from Acquia may not be desired and can be easily disabled.

Module Configurations

The following settings, configurations and modules should be installed and activated.

Configuration Options

The following basic configurations options should be set:

  • PING – Activate ping with a long list of ping servers..
  • User Administration – Any agency account management team Role should have the ability to add and configure users to be authors.
  • File Quota – Set the file size and upload quotas to at least 50 MB or unlimited for all users. The default of around 8 MB is almost always inadequate.
  • Full HTML – Set FULL HTML as the default input format.
  • File attachments – Activate file attachment capability for all users.
  • Video – Activate the video module for the easy inclusion of YouTube and other videos.


Modules provide functionality beyond the Drupal “Core.” It is the underlying philosophy of the Drupal CMS that any installation will contain a variety of these modules to provide services beyond the basic items built-into the CMS. The main issue when selecting these modules is that they are maintained by individuals often with no real development plan. They may break, be withdrawn or be incompatible with future versions of the Drupal core.

Even so, be sure to check the Drupal module availability prior to developing custom code.

The following are a variety of helpful modules that appear to be well maintained and respected by the Drupal community. This list has been determined based upon Drupal community recommendations and other base level best practice requirements.

Basic Modules

The following modules should e downloaded and installed for all sites. They provide base level functions that should be expected for delivery on all sites.

Basic Drupal Module Configuration


This provides a method for an editing review with a draft of content. This way someone can make changes and hold then for review or come back later and complete edits and then publish.

To turn this on:

Place a check box in the “Allow drafts when editing” box


This provides for a custom page to be displayed when Web server or browser error occurs. This is important otherwise a blank page is displayed with very little wrapper display.

To turn this on:

Design page nodes or HTML files to display for 403 and 404 errors and place these details in the settings.

Page Title

On content creation pages, gives you the chance to specify the page title rather than defaulting to the content’s title.

To turn this on:

Active – simply use area in form to set the page title.

Additional Modules

The following are common modules that provide some frequently required functionality.


User1 should not be used for development, maintenance or other tasks. Set it aside for very restrictive use.

Layout and Development

Never alter the Drupal core. Instead adapt an existing module or create required customizations as a module. These methods will isolate customizations from the core and other modules so that the core may be updated without impact on custom development’

Use the Content Construction Kit and the Views module. You can bypass this kit and module, but future development and adjustments are easier if they are utilized.[1]

Use the From API. Define the forms in php syntax and let Drupal create the html. This will let other modules adapt the form and enables programmatic submission.[2]

With the Form API make sure to check text only fields with check_plain(). This will check the fields for malicious content such as scripts, HTML and so on.[3]

To tackle Drupal development is strong in HTML, CSS, JavaScript and jQuery[4]

For a normal (single site) installation, you should put all non-core modules or themes in the sites/all/modules or sites/all/themes folders. For a multi-site installation, put modules or themes in sites/all that you wish to have available for all sites.


The following is a good resource for Drupal scalability – Most of these tips come from this page.

Choose modules carefully and deactivate them when they are not required. This would apply mainly to modules that assist in development. Deactivate these following the development cycle and reactivate when adjustments are required.[5]

CCK is a critical module but can slow down high-traffic sites. Consider its impact on such models. [6]

A theme is not just the look and feel. It is the data architecture and should be created with performance as a key concern,[7]

MySQL should be tuned for performance for any size site. See this page for four tips to follow :[8]

Use database, member and caching systems for files. The Cache Router module at is recommended.[9]

Follow at least the basic guidelines for shared server and mySQL optimization as found on

Drupal Site for Best Practices

The Drupal site itself has a whole section on best practices. This is of course a great resource and no one should start developing in Drupal without reading these areas targeted to the deep developer audience.






Other Best Practices Sources

The following are some of the solid best practices locations I have found for Drupal. The information in this document is heavily drawn from these sites.


· – Great great easy to read bullet list – start here.












Best Practice: Constant Contact List Segmentation

Constant Contact provides methods to segment lists when they are collected from different data collection forms. This is conducted by using a different list name for each data collection form. The following practices can help with this segmentation

  • Import any external lists to a new list for each. Do not import these to lists used with data collection forms. If this import contains data from multiple external lists then use a column (custom data filed) for details on the original source list.
  • Create a general list for use with the main subscription form on the Web site. Something like – “General Web Contact” is a good name.
  • Use a different list for each form used with an advertisement, microsite or other campaign. Yes, you will have a large number of lists. This is absolutely fine.
  • You could use one list and have a custom field populated with a source name that is unique to each form. This is not the preferred method since this will have a single list that may become prohibitively large.
  • Where possible use the Constant Contact forms that are provided for inclusion as this can be a very easy and direct method to include the forms with minimal programming.
  • Use a plug-in/module for WordPress ( or Drupal ( as these can help shorten programming cycles and make it easier to create the forms.

No Comments