by David Snopek on March 14, 2017 - 3:44pm

myDropWizard offers support and maintenance for Drupal sites that we didn't build initially. We've learned the hard way which site building mistakes have the greatest potential for creating issues later.

Before taking on a new client, we do an in-depth site audit looking for security issues and checking if the site follows best practices or has any problems that would make it harder to maintain the site going forward.

In 2016 alone, we did 64 site audits!

Looking at that many sites has taught us A TON about the most common mistakes that people make when building Drupal sites. Some of them were very surprising to us as experienced Drupal site builders!

This is the first in a series of articles, in which I'd like to share the most common pitfalls we've seen, so that you can avoid making the same mistakes when building your sites!

NOTE: even though they might take a slightly different form depending on the version, most of these same pitfalls apply equally to Drupal 6, 7 and 8! It turns out that bad practices are quite compatible with multiple Drupal versions ;-)

1. Unapplied security updates

I almost feel bad including this because everyone knows you should apply all security updates as soon as possible.

But you'd be surprised! We’ve audited maybe 4 sites where all the security updates were applied. :-)

Here's some pointers for staying on top of security updates:

  • Updates always come out on Wedensday after noon Eastern time
  • You can find all security advisories for core and contrib, as well as security PSAs, on
  • To receive e-mails when new security advisories are posted: edit your account on, click "My newsletters", check the "Security announcements" checkbox and click "Save"
  • Install the "Update manager" module, and see the "Available updates" report to see if there are any unapplied security updates on your site!

We apply all security updates to our customer sites the same day they are released.

Depending on your site and the particular security advisory, you might not need to be so aggressive, but we highly recommend applying any security updates as soon as possible! See our series on Understanding Security Advisories for advice on evaluating security advisories.

2. Multiple copies of the same module at the same "layer"

Let's say you downloaded and installed the Google Analytics module at 'sites/all/modules/google_analytics'. Some time goes by and there's several new releases, and you want to test the latest version on your site. Rather than deleting the old google_analytics directory, you rename it to google_analytics-old -- you know, just in case -- and put the new version at in a new google_analytics directory. You do some testing and everything seems to work, so you're done, right?

Unfortunately, Drupal doesn't use the name of the module directory to decide which copy of the module to use -- it's only looking for .info (Drupal 6 or 7) or .info.yml (Drupal 8) files.

So, if you have both of these files:

  • sites/all/modules/google_analytics-old/
  • sites/all/modules/google_analytics/

... Drupal will choose to use one copy of the module as the 'google_analytics' module, but it's impossible to know which one it'll use AND it could change its mind later!

While Drupal is unlikely to flip-flop back and forth constantly, seemingly unrelated changes like server updates, filesystem changes, or PHP version upgrades could cause Drupal to switch to using the other copy.

Also, having the two copies around makes security updates problematic: You might replace the module at 'sites/all/modules/google_analytics' but Drupal is really using 'sites/all/modules/google_analytics-old' so your update had no effect!

We highly recommend making sure there is only ever one copy of a module at the same "layer"! We have an internal script to detect this for Drupal 6, 7 and 8, and it's something we fix for all our clients during the on-boarding process.

(Note: Drupal DOES allow having multiple copies of the same module in different "layers" which override each other in a particular order. For example, if you have the same module in 'sites/all/modules' and 'sites/' the latter will override the former. This is a Drupal feature and isn't necessarily a problem! We're talking about multiple copies in the same "layer".)

3. Unorganized module patches

Drupal is Open Source, and that's great, because it means you can modify (or "patch") the code or use patches provided by other people to fix bugs or add features.

However, depending on patches can be dangerous, because when a new update comes out it's easy to forget to re-apply your patch after making the update (and sometimes you need to change the patch for the new version).

To avoid wiping out patches and breaking critical site functionality, we strongly recommend organizing your patches in some way!

At minimum this could be a special directory with all your patches or a text file with a list of links to the patches.

However, we recommend creating a drush .make file, which is text file that lists the modules, their versions and any patches, which can be used by drush (a Drupal command-line tool) to download your modules and apply the patches. This way, updating a module is just updating the version in the .make file, and running 'drush make' and it'll try to apply your patches against the new version -- if they don't apply any more, you get an error and the update won't happen.

You can use 'drush make' with Drupal 6, 7 and 8 (which is why we use it -- we support all those versions) but if you're doing Drupal 8 development, you can accomplish the same thing with composer, which you'll need to install certain modules and libraries anyway. See this composer plugin for applying patches.

But what if you don't remember what patches you've used already?

If you've lost track, check out the Hacked module! It will compare the module code on your site with the code from at the same version. We use it to create a .make file for all the patched modules when on-boarding a new customer site.

What next?

In this article, we covered 3 of the most common site building mistakes that we encounter when taking on a new Drupal site. There's certainly more! In fact, this is only the first article in a 3-part series -- we'll cover 7 pitfalls in total.

Have you encoutered Drupal sites that have these problems? Are there any other important pitfalls that you've encountered when building a Drupal site or reviewing a site built by someone else? Please write a comment below!

Or, if you'd like us to audit your Drupal site, please contact us about a FREE site audit!

Want to read more articles like this? blog Subscribe to the blog and recieve e-mail updates when new articles are published!


Very helpful information. Sharing this, needs to be heard and adapted quite a lot more out there!

The Hacked module seems like a good idea. Should I be concerned that it shows the following on the site page:
"This project is not covered by Drupal’s security advisory policy."

Well, even if the Hacked module was covered by the security team, it's a development module, so I'd recommend either (a) installing it on a cloned "development" version of the site or (b) installing it, getting the information you need, and then uninstalling it. Once you're caught up on all your old patches, if you stay on top of organizing them, then you won't need it again!

Add comment