• Blog >
  • Drupal tips best practices

In my experience working on Drupal sites, from 5 pages to large-scale public sector sites and intranets, I have picked up some quick tips for making a project go smoothly. These best practices for Drupal users are relatively simple and make life so much easier.

 

Simplify Drupal Directory Structure

Drupal is a modular based framework where downloading modules and themes allows you to ‘bolt’ on functionality. The possibilities are great, but adopting a clear directory pattern will make management far easier, especially when many people are working on the same project,

A standard Drupal installation will follow the below directory structure:

- Drupal
  -includes
  -misc
  -modules
  -profiles
  -scripts
  -sites
  -themes

Many newcomers to Drupal will download/create themes within the root themes folder; the same goes for modules, with inexperienced developers copying them to the modules folder. This works, however, it then is difficult to manage updating the Drupal installation when you don’t know what are core Drupal modules/themes and which are downloaded ones.

A better approach is the following structure:

- Drupal
  -includes
  -misc
  -modules
  -profiles
  -scripts
  -sites
    -all
      -modules
        |_contrib
        |_custom
      -themes
    -default
  -themes

Based on the example above, you would place all downloaded modules from Drupal.org under ‘sites/all/modules/contrib’ ; any custom modules under ‘sites/all/modules/custom’; and any downloaded/custom themes under ‘sites/all/themes’.

Benefits of this file structure include:

  • You can easily spot the downloaded modules in use and update them: they should all be filed under ‘sites/all/modules/contrib’.
  • It is clearly visible where all your custom project specific modules are if you are using any.
  • Following a Drupal update or security patch, you only need to take a backup of the ‘sites’ folder and copy it across to the new Drupal installation (or extract the new version of drupal to the website root directory).
  • For those of you who are using a VCS (Version Control System), such as git / svn etc, you only need to check the ‘sites’ directory into your repository. (Note, if you have made changes to Drupal core, it may be wise committing everything to the VCS or creating patch files and committing them to the VCS.)

I’ve only created one directory for themes ‘sites/all/themes’ . In general on all the sites we have worked on we only use one theme for the frontend and maybe a second admin theme (RootCandy is our favourite where CTI committed the icon patch for menu items which significantly improves the usability of the Drupal admin pages) . As we only use 2 themes at most there isn’t so much of a issue of manageability issue for themes so placing all themes under ‘sites/all/themes’ should not prove problematic.

 

Boost Memory Allowance

We’ve all seen the ‘white screen of death’ at some point. We’ve gone to Drupal.org, spotted a set of modules which look useful, downloaded them, installed them and then got a blank (white) screen after enabling them or mainly visiting the admin pages.

This ‘white screen of death’ can be explained by how Drupal implements its modular functionality. When loading a page, Drupal goes through what is known as a bootstrap: it loads the enabled Drupal modules into memory to execute the end points in the module (drupal hooks). Outside of the admin pages some of these hooks are cached, such as the menu callbacks, within the admin section no data is cached and this is where memory overhead is at its most as everything loaded.

A modest Drupal installation can use 30-40Mb of memory per request (web page view), or more if you have a large number of modules installed.

 

How to Fix Memory Overload

  • Locate your php.ini file:

The location of the php.ini file will depend on the operating system installed and if you are using WAMP / XAMP on a development machine.

  • Update the ‘memory_limit’ option:
memory_limit = 128M

On a Development server, this amount of memory is not a problem, as you often enable lots of modules and disable them. On a production server, it may be appropriate for you to lower the memory limit until you get a maximum limit where the site still works. This will help stop PHP eating all available memory and causing disk thrashing.

 

Enable Mod Rewrite

When developing a site locally, mod-rewrite is enabled to create SEO-friendly URLs. When you move the site on to the live server, often the links don’t work and you get shown a blank page or a ‘Server 500’ error.

Generally this is because your hosts as prevented the Drupal ‘.htaccess’ file from overriding the hosts default settings.

If you are developing on shared hosts, contact the host to enable mod-rewrite for you.

If the problem is on a local development machine, it is useful to add the following to your vhosts (or httpd.conf depending on your setup).

# A windows example of httpd.conf override

Options All
AllowOverride All
Order Allow,Deny
Allow from all

#A Linux example

Options All
AllowOverride All
Order Allow,Deny
Allow from all

Note: The above examples are based on a development server, on a production machine hosting many sites the above would not be advisable and you would want to configure each vhost specifically.

 

Common Drupal Mistakes

Choosing the Wrong Framework

Drupal is often thought of as a Framework; it is based around nodes: content which is stored in a database (repository). It provides a ‘Front controller’, a database api, access control functionality and a modular plugin system; it’s great. Yet, I’ve seen some instances of Drupal used for its Framework functionality without a single node.

If you want a framework for a content based application (Open Atrium is a good example) Drupal makes sense. If you end up fighting Drupal more than working with it, you may be better looking at one of the other bare-bones MVC frameworks, such as Cake, Symphony for php or Ruby on Rails. My favourite alternative is Grails, built on enterprise technology (Spring, Hibernate, Sitemesh) taking full advantage of the dynamic Goovy programming language which runs on the JVM, allowing full use of existing Java libraries and APIs.

 

Overusing Contributed Modules

One of the nice things about Drupal is that there is a active community and there are lots of modules available, you’ll even find they may be different modules essentially doing the same thing but in a different way. But be careful what you choose.

There's a module for that!

 

When you see a module, ask yourself:  

  • Do I really need it?
  • Can I achieve the same functionality and outcome?
  • Do I really need each and every module? (or will it just slow my site down?)
  • How do these modules work with one another?

Often, new Drupal developers make full use of all available modules but slowly end up with a huge number of modules that are unused or that directly interfere with each other.

 

It looks like every other Drupal site!

As Drupal becomes more popular, you may find more people installing the same modules/themes you have and a lot of sites end up looking the same.

Theming for Drupal is a topic which generates a lot of interest and debate. We like to follow the DRY principle: Don’t Repeat Yourself.  Consider downloading base themes, with minimum features to reduce repetition, such as the Zen theme.

I find in practice that the best looking Drupal sites are designed by a designer, with limited Drupal knowledge, before passing this design on to a Drupal themer who converts this into a theme. This may cost time, but why constrain a designer with requirements when anything is possible within Drupal?!

 

Find out more about how we support newcomers to Drupal with our Drupal Developer Graduate Scheme. 

Read about our Graduate Scheme

● ● ●