5 Mistakes to Avoid on your Drupal Website - Number 1: Architecture
Drupal is one of the most flexible content management systems in existence. In this blog series, I'll go over five mistakes to avoid on your Drupal website which include: architecture, security, performance, infrastructure, and website lifecycle management.
Hat tip to my colleague Ryan MacInnis for prompting me to write this up!
From an architecture standpoint, these are the most vital decisions you'll make to ensure the success and performance of your Drupal website.
- How you structure content
- How you configure the display
- How you organize functionality
Content is the essence of your website, the reason it exists. Determining the structure of content is the first
step in creating website architecture.
Plan your content structures, including fields and content types. Clear content architecture helps ensure
good performance, a better user experience, and easier maintenance. You will find overlap here with Display Architecture, because Views often depends on fields available in specific
Mistake: Too many content types.
Result: This will confuse content creators.
Example: Content types “news” and “article,” which are almost identical.
Solution: Reuse and standardize content types.
Mistake: New fields created for every content type.
Result: This is a waste of resources and drain on performance.
Example: Two different fields for school city and teacher city.
Solution: Reuse and standardize fields. Check your field report at example.com/admin/reports/fields.
Mistake: Content types with no nodes.
Result: An unneeded content type adds unnecessary complexity.
Solution: Reassess your needs as you build the site. Filter your content list to identify unused content types and delete unused content types.
Drupal is a powerful tool for displaying content in different regions, formats, and displays. Display
architecture includes the Views, Panels, and Context modules.
Plan your display architecture to render content only when needed . Optimize and reuse as much as
possible. Always separate logic and presentation. Start with a solid base theme and learn it thoroughly. The
ease of changing the look and feel of your website is an indication of good display architecture.
Mistake: A new View for every list.
Example: Three separate Views for jobs in London, Paris, and Lisbon.
Solution: Analyze any new View you create to determine if you can reuse a View you already have, and use Contextual Filters to render lists based on specific perameters.
Mistake: PHP code or other logic in the database or in template ( .tpl .php) files.
Example: PHP code that determines visibility of a scores block in a sports section.
Solution: Write all logic, including PHP, calls to web services, and SQL queries, in modules or theme
preprocess functions if necessary.
Theme Developer module http://drupal.org/project/devel_themer
With this module enabled, you can mouse over different areas of a webpage to see what template renders
Architecture: Site or Functionality
Site architecture includes how the site works, the number of modules, and how they interact.
Keep your site lean, using the minimal amount of code and fewest number of modules necessary. Use contrib
modules whenever possible rather than writing custom code. Become expert at key contrib modules, such as
Views and Panels. Follow Drupal standards for custom code. Reevaluate your architecture periodically.
Mistake: Too many modules. More than 200 modules enabled indicates a need for analysis to be sure all are modules necessary.
Example 1: Original plan included multiple languages, but site ended up in English only. All multilingual modules and contributed modules installed and enabled.
Solution: Reevaluate your site periodically, and disable, uninstall and remove unused modules from the code base.
Mistake: Too many roles which makes maintenance and security checking difficult.
Example: Original plan anticipated need for numerous roles, but most not used. Often roles attempt to match job titles too closely.
Solution: Evaluate roles and permissions on your site. Group into functional roles which can cascade and inherit permissions.
Mistake: Creating custom code when a contrib module already does the job well.
Example: Custom module to create forms on the fly that can be sent by email to site admins.
Solution: In this case, the well-tested Webform module provides this functionality, along with flexibility for site
admins . Be sure no contrib module already does what you need.
Mistake: Hacked core or contrib modules . Behavior will be unpredictable . Updating is difficult.
Solution: If core or contrib doesn’t do quite what you need, build a custom module using hooks to alter
behavior. If you inherit a site, use Acquia Insight or the Hacked! module (see Recommended Tools).
Mistake: Custom code using the wrong hooks or using the Drupal API incorrectly.
Example 1: Using hook_init, which loads on every page, for something only used on the home page.
Example 2: Custom modules with hardcoded strings for nids, tids, and vids. When these change in the
future, troubleshooting the cause of resulting problems is very difficult.
Solution: Plan carefully when using custom code. Find the right hooks and syntax using drupal .org’s API
documentation at http://api.drupal.org/api/drupal.
- Simplytest.me. On this site, simply enter the name of a Drupal module. The site will spin up a Drupal instance for you to test the module for 30 minutes.
- Hacked! module. This module scans your Drupal installation, including contrib modules and themes, and determines if they have been changed. Used with the Diff module, result screens will tell you the exact lines that have changed. Absolutely not to be used on production sites.
- Acquia Insight. Our service does similar scans to the Hacked module, but provides additional site configuration and security checks as well.