- How you structure content
- How you configure the display
- How you organize functionality
Architecture: ContentContent is the essence of your website, the reason it exists. Determining the structure of content is the first step in creating website architecture.
Best PracticePlan 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: DisplayDrupal is a powerful tool for displaying content in different regions, formats, and displays. Display architecture includes the Views, Panels, and Context modules.
Best PracticePlan 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 FunctionalitySite architecture includes how the site works, the number of modules, and how they interact.
Best PracticeKeep 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 Cloud, which comes with dozens of tools to help you build, deploy, and optimize digital experiences faster.
Ready for another mistake to avoid? Check out the next installment in this series: 5 Mistakes to Avoid on your Drupal Website - Number 2: Security.