5 Mistakes to Avoid on Your Next Drupal Website Project

echris's picture
Drupal Logo

As a Drupal Site Builder/Developer, it is apparent that any site been developed should be secured, safe, flexible and easy to use and implement. However, we sometimes find ourselves wondering at the growth to our structures and fields during development that we seek a better solution to resolve such. This article gives us pointers to improve our development and maintenance as well as provide tips on how to avoid common mistakes during building a Drupal Site.

Drupal is one of the most flexible content management systems in existence (No argument on this fact). The following categories will be discussed

Please note: This write-up makes use of some assumption which are recommended but can be easily overcome with little time for studies:

  • That you are familiar with Drupal Site Building
  • That you know some PHP
  • That you are aware of some Drupal-specific programming such as Hooks
  • That you are familiar with MySQL Database



There's this saying on the Internet that "Content is King". Content is the essence of your website, the reason it exists. People come to a site to get Content which can be Images, Text, Audio, Videos etc. Determining the structure of contents is the first step in creating website architecture

Some Best Practices include:


  • Planning your content structures, including fields and content types.
  • Avoiding identical multiple Content types like "news" and "articles" which are almost identical. Reuse and standardize content types
  • Avoid creating new fields for every content types. This is a huge waste of resource and drain performances. e.g Using two different fields for school
  • city and teach city. Kindly reuse and standardize field:
  • Note: You can view your field report on yoursitename.com/admin/reports/fields
  • Avoid building content type with no nodes. It adds extra unnecessary complexity. Reassess your needs as you build the site. Filter your content list to identify and delete unused content types


Drupal is a powerful tool for display 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 based theme and learn it thoroughly (either Omega or AdaptiveTheme)
  • Analyze any new View you create to determine if you can reuse a View you already have, and use Contextual Filters (by the right side of the View Page), to render lists based on specific parameters
  • Write all logic, including PHP, calls to web services, and SQL queries, in modules or theme preprocess functions if necessary. Avoid using the PHP Filter Module to write PHP Script directly.

Recommendation: Theme Developer Module is a good tool that can help mouse over different areas of a webpage to see what template renders that section which gives you the tool to call the template file holding such rendering.

Site or Functionality

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

  • Keep your site leans, using the minimal amount of code and fewest number of modules necessary
  • Use contrib modules whenever possible rather than writing custom code (We developers disobey this sometimes - some humor)
  • Become expert at key contrib modules, such as Views and Panels
  • Follow Drupal Standards for custom code (I can see developers shouting "Aha! now we are talking")
  • Reevaluate your site periodically, and disable, uninstall, and remove unused modules from the code base. Additionally, clear your cache if some serious changes have taken place in your Drupal site to avoid lagging.
  • Evaluate roles and permission on your site. Group into functional role that can cascade and inherit permissions
  • Before creating a custom code, be sure no contrib module already does what you need to avoid reinventing the wheel.
  • If however, a 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 the following recommendations:

- Simplytest.me - Useful to testing the functionality of a Module as well as new features

- Hacked! Module - Enables you to scan 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 - Does similar thing as Hacked! Module but provides additional site configuration and security checks as well. Highly recommendable



Providing a secured environment of operation especially in management of a Drupal site is highly recommended. Good security practices protect your site from hacker attackers. Drupal is built with security in mind if used correctly:

  • Plan your configuration so that only trusted users have permission that involved security risks
  • Keep your core and contrib modules updated. You may not opt to do some module updates if the fixes or improvements have no direct effect on your site, however you should always apply security updates as soon as possible. My personal favorite is to subscribe to security announcements on Drupal.org site
  • Use strong passwords policy. Passwords are the most likely candidates for points of failure in your site security. Using the Password Policy module to devise a set of constraints before you users set their passwords. You can also set passwords to expire.
  • Limit file uploads and what files are served. Limit the file types allowed and limit uploads to trusted users only. Check your permissions for specific content types and files allowed in field uploads.
  • User the Security Review Module (which analyze your site configuration and report methods for fixing errors - Use on staging or test site) and Acquia Insight( for additional site configuration and security checks as well).
  • Avoid using SQL in code rather than using Drupal API. Use the Drupal's database abstraction layers (http://api.drupal.org/api/drupal/includes%21database%21database.inc/grou...)
  • Clean (Sanitize or Filter) any input from untrusted users before returning to the browser for rendering
  • Always use the Drupal's Form API, which protects against Cross-Site Request Forgery by inserting a token in every form.



Providing an improved performance is critical in leveraging great user experience. If the site is slow or balky, even great functionality won't keep the site visitor engaged.

Be sure to analyze what the website is doing. With the answer to this question, optimize as much as possible, then implement caching

Analyze Tools include

  • Devel: for viewing database queries which run on each page
  • XHProf: is generally the best tool to start with. Profiling is what helpes you find the issues to begin with
  • New Relic: will analyze your site at a low level and report slow database queries, external queries, and specific pages
  • Yottaa.com: focuses on front-end performance. This service will tell you how fast your site loads in different locations around the world

Optimize- common problem areas:

  • Using complex queries that take too much time and don't use an index
  • Calling functions too often
  • Keeping unused modules enabled on your site. Disable any unused modules
  • Misconfiguring cron.
  • Using the default views pager which requires an additional COUNT query.
  • Using database logging (dblog). It is enabled by default in Drupal 7, and errors can fill up your database quickly. One common solution is to use syslog instead, but this merely masks the problem by making the logs less accessible. a better solution is to fix all PHP notices and warnings to reduce logging overhead
  • Use the Fast 404 module to serve static 404s for image, icon, css, or other static files, rather than bootstraping Drupal
  • Not aggregating CSS and JavaScript



This covers the stack your website lives on, including the server, the database, and any software layers, such as Varnish or Memcached, which ensure your visitors, have a snappy experience. Planning the infrastructure from the start and developing on the same environment can greatly reduce variables and risk at launch time. Having a reliable multiple environment configuration and a solid disaster recovery plan shouldn't be left to last-minute decisions. When it is, mistakes start arising.

  • Size your stack correctly (Server's Hardware capacity), not too large, not too small. This can ensure you're economically prepared for anything
  • Bottlenecks can arise from the hardware or from processes hogging memory. Check logs for errors and prepare for growth and spikes. Your stack is only as fast as the slowest component. Focus your efforts there: You'll probably find low hanging fruit.
  • In terms of security, its crucial to configure to protect from internal attacks as well as external attacks
  • Check response headers to ensure that pages you expect to be cached are indeed cached. Ensure that modules aren't setting session variables unnecessarily
  • Fortify remote connection to databases, Memcached or Solr, and maintain this configuration through any infrastructure changes

Recommended Tools: mysqltuner.pl or MYSQLTuner: This is a perl script that you can download from Githubt. It will present current configuration variables and status data for your MYSQL installation, along with some basic performance suggestions



The life cycle of a website begins from initial plans and extends to the end of the site. The site exists in three different phases:

*Development,  *Deployment, *Maintenance.

After the site is launched, your website lifecycle practices become official to the success of changing and maintaining your site

  • Keep your code under version control. Using Git which happens to be the most popular among Developers. Note: Be sure to leave meaningful commit messages so that colleagues can understand the changes you have made.
  • Maintain separate environments for the different stages of the site, and keep them up to date
  • Restrict access to the production site for all but the most trusted users
  • Review all logs periodically, including Apache, Drupal, and MySQL
  • Review and assess your architectural periodically, and plan for the future
  • Maintain testing environments as similar to production as possible. With these, you can easily copy from production and execute tests to ensure that changes will work when moved to production.
  • As always, keep all modules and core as current as possible - AND DON'T FORGET TO BACKUP O!


A website is never a fixed organism but a living one. Regularly check all logs so that you'll know where its going as it changes over time. Keeping a large Drupal website going is a challenge on many fronts. If you follow these best practices and avoid the mistakes outline here, which i am currently implementing, you'll find your work goes much better.


Next on my list

  • How to use GIT for Drupal Development and Management
  •  Drupal Performance without Coding