« Best Practice: Constant Contact List Segmentation
Drupal vs. WordPress »

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: http://zzolo.org/thoughts/drupal-basics-and-best-practices 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 www.drupal.org 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 acquia.com 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

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

Draft

http://redesign.pparx.org/admin/settings/draft

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

CustomError

http://redesign.pparx.org/admin/settings/customerror

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.

Accounts/Roles

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.

Scalability

The following is a good resource for Drupal scalability – http://www.optaros.com/blogs/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 : http://www.optaros.com/blogs/drupal-scalability.[8]

Use database, member and caching systems for files. The Cache Router module at http://drupal.org/project/cacherouter is recommended.[9]

Follow at least the basic guidelines for shared server and mySQL optimization as found on http://drupal.org/node/36628

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.

· http://drupal.org/node/287350

· http://drupal.org/node/244642

· http://drupal.org/node/36628

· http://drupal.org/node/22283

· http://drupal.org/node/224921

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.

· http://www.slideshare.net/manugoel2003/drupal-best-practices

· http://zzolo.org/thoughts/drupal-basics-and-best-practices – Great great easy to read bullet list – start here.

· http://acquia.com/community/resources/webinars/seo-best-practices-your-drupal-site-0

[1] http://www.slideshare.net/manugoel2003/drupal-best-practices

[2] http://www.slideshare.net/manugoel2003/drupal-best-practices

[3] http://www.slideshare.net/manugoel2003/drupal-best-practices

[4] http://www.slideshare.net/manugoel2003/drupal-best-practices

[5] http://www.optaros.com/blogs/drupal-scalability

[6] http://www.optaros.com/blogs/drupal-scalability

[7] http://www.optaros.com/blogs/drupal-scalability

[8] http://www.optaros.com/blogs/drupal-scalability

[9] http://www.optaros.com/blogs/drupal-scalability

This entry was posted on May 26, 2009, 9:42 am and is filed under Best Practice. You can follow any responses to this entry through RSS 2.0. You can leave a response, or trackback from your own site.

  1. #1 by Paul Salvaggio on May 26, 2009 - 9:47 am

    How does Drupal compare to Joomla?

    Quote

  2. #2 by Keyz on June 14, 2009 - 12:02 am

    Not meaning to nitpick, only to help. Please don’t take these comments negatively.

    Your recommendation of some modules as best practice for all sites is not necessarily accurate. For instance CCK and Views are definitely recommended, but a simpler site very well may not require them and adding them when unneeded adds to the memory footprint of Drupal and also adds more modules to care for security/updates (never add any modules you do not actually need). Some of the other mentioned modules may certainly be recommended as needed as well, but not as “best practice for all sites” per se (and some are actually not recommended at all). TinyMCE module should definitely not be recommended, as it is fully deprecated in favor of the Wysiwyg API (which is the future handler of all Wysiwyg functionality in Drupal… it is a single unified module for plugging in and configuring a wide variety of Wysiwyg editors). Various modules likely to be recommended include Filefield, ImageAPI, ImageField, ImageCache, Voting API, Administration Menu, etc.

    One does not need to have strong skills in Javascript/jQuery to work with or develop for Drupal. In fact quite complex sites can be created in Drupal with little to no coding beyond HTML and CSS, and a slight touch of the most basic PHP (e.g. simply copying and pasting the dynamic variables in the template files if any adjustments are needed). If developing modules yourself, intermediate or better PHP experience is recommended, and of course if you need to create custom jQuery features and effects you’d need to understand jQuery.

    Best practice is to always put all contributed modules into sites/all/modules and all contributed themes in sites/all/themes, regardless of whether you initially use the multi-site capabilities or not. Placing them only at the path you mentioned (sites/all) is not correct. If you do have a multi-site you can place modules and themes into that site’s own sites/sitename.com/modules (and themes) directories to make them available only to that site.

    Regarding scalability… you didn’t quite accurately portray the information you acquired from the source article. For instance the site does not say CCK is bad for high traffic sites – it recommends avoiding or reducing the practice of using shared fields in CCK (the reason being that it causes fields to split into their own tables, therefore causing extra join queries when calling the data up, which can be bad for performance [this only applies to logged in users, not regular visitors, which are heavily cached]). CCK is used on huge Drupal sites such as those by Sony, Symantec, MTV UK, and others. Also the part regarding theming being part of the “data architecture” wasn’t accurately represented (the referenced article says “Drupal’s architecture” which is completely different).

    Anyhow I just wanted to help clarify these points for those who may read this in the future. Thanks for your post :)

    Quote
(will not be published)