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

Architecture: Content

Content is the essence of your website, the reason it exists. Determining the structure of content is the first
step in creating website architecture.

Best Practice

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
types.

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.

Architecture: Display

Drupal is a powerful tool for displaying content in different regions, formats, and displays. Display
architecture includes the Views, Panels, and Context modules.

Best Practice

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.

Recommended Tool:

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
that section.

Architecture: Site or Functionality

Site architecture includes how the site works, the number of modules, and how they interact.

Best Practice

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.

Recommended Tools:

  • 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.

Comments

Posted on by Bill Winett.

Good list.

I think stating that "new fields created for every content type" is a mistake and causes a performance hit needs further discussion. At least in D6, with which I'm most familiar, if you share a field between multiple content types, the field is deleted from the "content_type_<content type>" table, and it is stored in a new table with the name "content_field_<field name>". This means that every node load now includes an additional join, which is a performance hit.

Posted on by Brian Osborne.

I think this needs further discussions as well. For one thing, it's essentially a requirement to use independent fields for each content type if you're using the Features module.

Posted on by Dustin Windibank.

Features module now supports sharing fields via base fields, see: http://www.phase2technology.com/blog/new-field-bases- and-instances-in-fe...

Posted on by Brian Osborne.

This article was just published and provides detail on the advantages/disadvantages of shared fields:

ht tp://www.ostraining.com/blog/drupal/re-using-drupal-fields

Posted on by heather.

That's correct, in Drupal 6, the shared field does go into its own table, and requires the join. I added a note in 2011 from Earl Mile's book on CCK in Drupal 6 about shared field performance, shared fields could be better:
https://drup al.org/comment/5163648#comment-5163648

Overall the issues of maintenance and design outweigh any negatives.

For performance the emphasis should be on the caching strategy. Check out this blog post by my colleague: https://ww w.acquia.com/blog/when-and-how-caching-can-save-your-drupal-site

It's not a cut-and dried decision. It's sort of like the "200 modules" point made above. I dithered about that... it's more about the lines of code than the number of modules, but it's a guideline you should be concerned with that amount. if you had 20 modules like Panels and Views, then you'd be concerned!

Posted on by Bill Winett.

This is exactly the type of discussion I was hoping for. Thanks!

BTW, anyone know if D8 works similarly (in terms of shared fields)?

Aside: if I hadn't clicked on the link to this post in TheWeeklyDrop email (http://www.theweeklydrop.com/ ), I wouldn't have seen these great responses.

Posted on by heather.

Yeah! The WeeklyDrop is pretty awesome!

Posted on by Greg Boggs (not verified).

Drupal Commerce could ship as 1 module instead of a large set. But, the Drupal way of many small modules is one of the big advantages for enterprise over WordPress which uses monolithic plugins.

Certainly, unused modules are bad, but if a module is well-maintained by the community, and solves a feature without custom code, then using a module is easier to maintain than writing custom code that can't be reused.

Add new comment

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.

Filtered HTML

  • Use [acphone_sales], [acphone_sales_text], [acphone_support], [acphone_international], [acphone_devcloud], [acphone_extra1] and [acphone_extra2] as placeholders for Acquia phone numbers. Add class "acquia-phones-link" to wrapper element to make number a link.
  • To post pieces of code, surround them with <code>...</code> tags. For PHP code, you can use <?php ... ?>, which will also colour it based on syntax.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Allowed HTML tags: <a> <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <h4> <h5> <h2> <img>
  • Lines and paragraphs break automatically.
By submitting this form, you accept the Mollom privacy policy.