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).
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.
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.