Menu

Learn and show support?

5 things you should not do on a Drupal site

In this article I am going to go over 5 things you should definitely not be doing on a Drupal site. In this venture I will try to avoid the "not not do" type of actions and focus only on what you should simply not do.

Do not hack core

I think this advice is quite straightforward and spread within the Drupal community. But it cannot be stressed enough. Drupal provides a myriad of ways you can avoid the temptation of modifying core files. And even if a particular problem you have seems that it can be solved so easily by hacking core, don't. Employ proper techniques of overriding that particular functionality.

Why? Well, good luck updating Drupal later on if you modify core files. Either you will override your changes which will effectively break your functionality or you will have to keep making those changes every time you update. Drupal 7 is already past 20 versions, so think about it. A, and a kitten dies every time someone hacks core.

Do not make updates on production

Speaking of updating Drupal core (or even contrib), I think it's important to know you should never perform the updates straight on the production environment. You never know what can break as a result of the new functionality core or contrib brings to the table or removes from your site.

In other words, make sure you test everything locally or on a specific environment you have for this kind of purpose. It's not a big deal, you set it up once and then can reuse it for all your other sites or projects. This goes of course also for any kind of development work you do - never first on production.

And since we are on updates, make sure you read what the nature of the update is - even if it's security. It doesn't hurt to know what functionality will be affected. And this way, you learn maybe some new things about Drupal.

Do not install all the modules in the world

When I was a beginner I was amazed by the plethora of modules available to extend core. So I installed and installed because maybe the functionality will be needed later on site. Drupal can do so much. Little did I know that this would virtually halt my site to a standstill. And turns out, most of that functionality was never even needed.

So my point is, make sure the modules you install are needed at the moment you install them. Try to gauge the quality of the code (there are various factors for that) and then test locally if it does the job for you. If yes, commit it to the repository and use it. If not, delete it, no point in cluttering your codebase or even worse, having it enabled and loaded by Drupal with every page request.

Do not commit your settings.php file

If you are storing the Drupal codebase in a Git repository, and you should, it sometimes happens that you commit the settings.php file. This means the credentials to accessing the database are stored in its history and difficult to remove.

Normally, this shouldn't' happen. Drupal comes with a .gitignore file that by default prevents the settings.php file from being considered relevant to the repo. And that's how it needs to stay. I've seen however cases in which this was not properly respected or the .gitignore file was changed (or removed) causing the the database credentials to be to be committed and available in plain text in the repository. So be careful.

Do not use the PHP Filter module

If you are running Drupal 7, you'll maybe know that there is this module called PHP Filter. Don't use it. Not only it represents a huge security risk if unauthorised users get to evaluate PHP with it, but you can also evaluate PHP with it!. Which is absurd.

There's a good reason why separation of concerns (logic from presentation) is to be desired in web applications. And god knows Drupal 7 falls short in many respects, but this is to the extreme. Putting PHP in with your content is the mother of all the you're doing it wrong. So just don't. Unless you have to. I'm kidding. Write a custom module to handle the functionality you'd need there and disable PHP Filter. But don't delete it because it's core (see my first point).

Conclusion

In this article I talked about 5 random things you should not be doing on or with your Drupal website. There are more of course, but these are - in my opinion - some of the important ones.

In the next one, I will take a more positive approach and give you some random tips on what you should be doing on your Drupal site. See you then.

I completely agree. I always commit settings.php, but load have it load a settings-local.php file that is not committed, which contains all my local overrides, including the database settings. I find this is a much better approach, particularly with distributed development.

Great list, i think most of Drupal beginners have met the above mentioned mistakes. I would add some more: putting themes and modules in the folder on the root level, choosing unsupported module, leaving old or unused modules, using default block systems, using page tpl.php templates and not using Context layouts or Panels, not using API functions, etc.

In my experience it is close to impossible to deliver a fast Drupal site without caching, so this would definitely be on my top 5 (in contrast, simple Wordpress sites will usually be perfectly fast without caching). At minimum:

Opcode Cache (use APC, xcache or something similar to cache PHP)

MySQL cache (get your MySQL caching settings right)

Static Page cache (e.g the Boost module)

You can get even funkier by using CDNs and Varnish and Memcache and suchlike but I have found that the above checklist makes normal (slow) Drupal nice and speedy in 99% of cases.