Profile picture for user admin
Daniel Sipos
31 Mar 2014

This article comes as a continuation to the previous one in which I exemplified 5 things you should not do on or with your Drupal site. Today, however, I'll double up, take a more positive approach and go with 10 things you definitely should be doing. So let's begin.

Turn on caching and aggregation on production

When you develop locally you'll most likely disable css/js aggregation and turn off the caches. This makes it easier to quickly see changes as you make them and allows for a more efficient development. However, you have to make sure that these are turned back on when you move to the live site.

Drupal comes with a few powerful performance related settings that greatly improve the speed of your site. Page caching and compression for anonymous users is one of them. CSS/JS aggregation is another. And there are a bunch of contrib modules that enhance performance and I recommend you also look into those.

Disable development modules and functionality on production

If the previous point was about performance, this one is about security. There are various things you'll use locally while you develop or debug your Drupal site. The Devel module is something you'll probably enable and the error reporting will most likely be turned on so you can see what's going on.

This is all good and well but make sure that when you push your changes to the production site, these get turned off. Keeping the Devel module enabled on a live site is not indicated and can be a security risk. And although it constitutes security by obscurity, disabling the printing of errors to the screen is also important. Not to mention user friendly.

So either you create a checklist of things to do or automate these processes however you want. Drush will be a very good friend with this.

Use Drush for shell tasks like updating and installing modules

Speaking of Drush, any respectable Drupal developer will know how to use and will use Drush for one thing or another. It is a very helpful tool to run tasks related to Drupal from the command line. A Drupal shell basically.

I'm not even going to enumerate all the cool things you can do with it but I will refer you to a couple of articles I wrote before on how you can begin with Drush and some of the basic things you can use it for.

Keep regular backups of your production environment

The best backups are the ones you don't ever need. That being said, you'll need to keep regular backups of your site and server in order to revert if the worst should happen. There are many tools you can use for this (both manual and automated) but I'm not going to go into that right now. I will however share a story to scare you straight into opening your MySQL interface of choice and taking a database dump.

A while ago, I hosted a site for someone on a shared server from a random hosting company. One day I notice the site is down and in about 24 hours (of the site being down) I get an email. Someone hacked into their datacenter and deleted everything (both live servers and backup server). Apparently both were kept in the same place and their access was solely protected by the act of sending an email to the datacenter from the hosting company's email address asking for access...

The resolution was the following: no more data, ever, retrieved. Nobody got anything back. Luckily, I had backups and so should you. The moral of the story is obvious I think.

Find a good balance between contrib and custom

In the previous article I strongly advised against using too many contrib modules. I mean if the site is huge and needs them, it's fine. As long as they are accompanied with performance related enhancements to compensate for the load.

In this point I would like to stress the importance of finding a good balance between using contrib modules vs your own custom code. The rule of thumb is to use contrib modules as much as you can. This means do not write custom code that is already present in a module. This is because there are multiple people looking at that module and can spot problems, make updates and you'll be also better off.

That being said, you also have to be careful of (1) what modules you use and (2) what problem they solve. First of all, the module can be of bad quality or not performant, so you'll need to investigate a bit (how many people use it, how does the issue queue looks like, etc). Second of all, it can be an overkill. If you need a tiny piece of functionality offered by a module that does a bunch of other stuff you don't need, it's maybe time to think about whether or not you can implement that yourself. It's a judgement call depending on the case.

If you don't expect users to create accounts, disable this functionality

One of the things I kept forgetting and paid the price later was to disable the right for anonymous users to create user accounts on the site. By default on a fresh Drupal install, anonymous users can create accounts and you as an admin need to approve them. The problem is that if you forget, you can wake up in 6 months with a huge spam user list that you need to take care of.

This piece of advice concerns those who create new websites that don't need people creating accounts of course. If you require users to be able to create them themselves, make sure you implement some anti-spam techniques like Captcha, Mollom or Honeypot.

Employ Drupal coding and security standards

One of the important things that beginner Drupal developers need to learn is how to respect the Drupal coding and security standards in place.

The coding standards represent a particular way of writing, formatting and structuring code. Aside from syntactical rules, you also have readability rules and implementation rules (where and how should I use this function or hook).

The security standards represent the rules the respect of which ensures that you will write secure code. This means using helper functions and techniques that actually make Drupal a pretty secure system.

So make sure you got these down before attempting to write enterprise code for Drupal production sites.

Keep your code in Git

Using version control is a must with any web application. In this day and age you cannot write code without keeping it in some sort of versioning system like Git, Mercurial, or SVN. The Drupal community adopted Git and it's awesome. It's also one of the most popular ones out there.

If you want to develop Drupal modules, themes or contribute to existing ones or even core, you can't get around using Git. So make sure you start using it for all your projects if you don't already.

You can also use Git to deploy your code between environments. Keeping a central repository from which you can pull provides a fast and easy way to deploy code. This is of course if you're not already using some automated tool like Jenkins (that also integrates with Git by the way).

Update core regularly

It's recommended that you update your site when there are updates issued by the core maintainers, especially when they are security updates. Yes, it can take some time to perform these updates, but it's worth it.

Why? There is no getting around the fact that security updates need to be done. Once they are public, the vulnerabilities are as well. So if you haven't deleted the CHANGELOG.TXT file from your Drupal root (which you can do), potential attackers can find out the version of Drupal you are running. And the risk of exploiting those vulnerabilities increases. This is not to say that deleting the CHANGELOG.TXT file is enough and you shouldn't update.

Additionally, if you leave it for later, you'll end up having to do a big update across many version numbers which makes it much more difficult. It'll take much more time to do and the risk of breaking some functionality will increase as well.

So take the time regularly to do the updates, look at what is affected by them and test your site to make sure it won't break (locally!). If it does, fix the custom code (or update contrib) that no longer functions due to this. The problems should however be minimal with incremental updates.

Keep the modules in the right folders

There is a best practice in Drupal regarding the way you organise the modules on your site. We know that they must be kept in the sites/all/ folder but we can better organise them inside that as well.

Contrib modules need to go in a folder called contrib/ and custom modules in a folder custom/. Trust me, when you will have plenty of modules (of both types), finding them will be much easier.

Additionally, if you use the Features module, you should put all your features into a features/ folder. And if you patch any of the contrib modules, it's best if you move them from contrib/ to a folder called patched/. This way you have an overview of which modules you need to pay extra attention to when doing updates. After moving the module make sure you run a registry rebuild to update Drupal as well that the location has changed. With Drush this is easy: drush rr.


There you have them: 10 things I recommend you do on your Drupal site. Again, there are more of course, but here are 10 of my most important ones. By the way, do you know that saying: do as I say not as I do? :)

Profile picture for user admin

Daniel Sipos

CEO @ Web Omelette

Danny founded WEBOMELETTE in 2012 as a passion project, mostly writing about Drupal problems he faced day to day, as well as about new technologies and things that he thought other developers would find useful. Now he now manages a team of developers and designers, delivering quality products that make businesses successful.

Contact us


karlos 31 Mar 2014 13:17

i disagree

Last thing is totally wrong. I disagree about contrib, patched etc. You have a contrib module. And you need to patch it - move to other directory? After new stable release it is not patched anymore - another move? Why the hell? My solution: ROOT/_PATCHES, each patch contains module name, issue NID and comment number.

Roger Nyman 02 Apr 2014 23:31

In reply to by karlos (not verified)

Why such a strong language?

Why such a strong language? You can disagree allright, and you might even be right, but keep up a good manner. Please.

Daniel 06 Apr 2014 06:13

In reply to by Roger Nyman (not verified)

Positive intent?

@Roger Nyman: I don't know if you know karlos? - I do not, and I presume you do neither.
Do you know which country he is from? If he is a native speaker? What is cultural background? Maybe he is indeed a native speaker, maybe he is simply what you define as 'rude'? - But are you certain and isn't it somewhat rude to presume that he has negative intent where you can't be certain?
In a global internet environment you cannot simply always presume that somebody has negative intent? Some people might have a limited capability of expressing them selves, which might come across as rude or might be simply from a different cultural background where what you consider 'rude' is simply not considered rude.
Again disclaimer: I do not know if you know karlos and I'm going simply with the limited information I have - and so I might be simply wrong with my presumptions.
What you consider 'strong' might have different reasons that what you expect.

Alex 31 Mar 2014 15:20

Good tips but...

Good tips but I personally am not a fan of the "put features in a features directory" approach. In fact, I find that it just makes things more confusing!

The truth is that there's a fine line between a feature and a custom module... let's go with the ever-popular "blog feature" example here: according to your article it should go in a features directory. However, what if you want to add a couple hooks to it, say you want to create a custom admin interface and need a menu local action and some hook_help for end users? That code should definitely go in the blog feature, so as to keep it more organized.

What happens next is that, at the end of your project, you will have part of your custom code in the custom modules directory and part of it in the features directory, making finding it (for new developers working on the project for example) a bit harder.

Not to mention that, at least in my experience, it's not unheard of to "convert" a custom module into a feature. For example you build a custom module and all is well but at some point you realize you need to export a particular bit of configuration to it... in order to do that all you need to do is add the "features api" .info line and boom, your module is now a feature! But it lives in the custom directory... what do you do? Do you move it and risk a messy upgrade path for other members of the team? Or do you leave it there and effectively have features in both directories?

You can hopefully now see why I'm not a fan of that approach! IMHO custom code, features or otherwise, should always go in the custom modules directory!

Just my $0.02...


karlos 31 Mar 2014 21:00

In reply to by Alex (not verified)

Same here. And with Features

Same here. And with Features 2.0 another important thing: make a feature called like "Global content types" - add there field BASES for common fields like body, perex_image, attachments etc which are used on multiple content types. Then a feature like blog or gallery includes only field instances of these field + complete fields specific for them. Same thing i do with global taxonomy vocabulary like Tags. And never use default Views - taxonomy_term for example. Every time you should disable it and clone it to my_taxonomy_term. The default thing you can not export with Features.

Dave Hansen-Lange 03 Apr 2014 20:47

There is no security risk to

There is no security risk to having the devel module enabled on a production site. If there were then the Drupal security team would need to work with the maintainers on creating a fix. Sure if you give anonymous users permission to execute PHP that would be a gaping security hole. But that's why the permissions page has warnings "this permission has security implications...". There are several similar permissions in Drupal core.

Please don't spread FUD.

Daniel Sipos 03 Apr 2014 22:40

In reply to by Dave Hansen-Lange (not verified)

Well then Dave, I invite you

Well then Dave, I invite you to keep Devel module enabled on your production site. Good luck!

Dave Hansen-Lange 03 Apr 2014 20:44

Removing CHANGELOG.txt is not

Removing CHANGELOG.txt is not a technique suggested by the majority of the Drupal community for reasons listed here:
Basically it will do absolutely nothing for security. There are times where obscurity as an addition to solid security is a good practice, but this isn't one of them.

Ryan 26 Nov 2017 22:28


Thanks for the tips! After years dabbling in Drupal I'm finally starting to conform to best-practices and this list was insightful. Long live Drupal!

Add new comment