Adding Modules and Themes

Last modified: June 8, 2009 - 23:58

Just a note: Before deciding to install and/or enable extra modules on your site, it is recommended that you first consider the intended functionality for your site, and only add new modules if your site actually needs them. Enabling modules that your site doesn't need adds to the memory and other resource needs of your site unecessarily, and will make your site's pages load slower. Because a module is popular or someone tells you that 'every site needs it' doesn't mean yours does. There are good sites that have been built with absolutely no contributed modules at all.

Also, it is recommended that you work on content, functionality, and configuration of your site before you consider how it should look (the theme), since that decision can be made later and may detract from your thinking about functionality and content.

Themes are largely a matter of taste. For example, many people do not like to use a "fixed width" theme, but lots of people do. One nice thing about themes are they are pretty much independent of your content so you can switch them when you want. Caution, though, there are parts of your site (blocks, for example) that get built based on the theme, so switching themes can leave junk lying around to slow down your site.

Contributed modules are ways to add or extend functionality of your site. The only module I, personally, consider necessary is the Nodewords (a.k.a Meta Tags) module; in my opinion, it should be promoted to "core" status. This one allows you to add the "content," "keywords," and "robots" meta tags to your pages. This is useful if you're interested in your search engine rankings. You will also find that many contributed modules also require the Views module; I go ahead and make that a standard one for my sites.

Now, if you experiment with different themes and modules, as I know you will, despite my suggestions, you should also look at the Update Status (core in D6) and Site Documentation modules to make sure you are current and to document and clean up the mess your experimentation will make. Here are some suggestions on choosing the release: Strong stomach?

For examples of different opinions on what are "must have" modules, here is one, and here is another.

Installation

Installing a module or theme is pretty much the same until you get to enabling them. Now keep in mind that I use a Windows based PC (development) and Linux servers (on my live sites).

  1. Go to the Drupal site and click on the "Downloads" tab. Then select either "Modules" or "Themes" depending on what you're after.
  2. Locate the module or theme you want.
  3. Make sure there is a version for the version of Drupal that you are using. D5 modules and themes will not work on D6.
  4. I always click on "Find out more" and read the stuff again. This gives you the chance to see if there is support for your release of Drupal. You can also look at pending bugs and feature requests - it might change your mind.
  5. Download the proper release. (I put them in a Drupal folder in "My Downloads.")
  6. Unzip the downloaded file (I use WinZip). It may tell you that there is only one file in the zipped file; click "yes" or "OK."
  7. Extract the code to to your /sites/{sitename}/modules/{modulename} or sites/{sitename}/themes/{themename} folder. If you are not running multiple sites, this would be /sites/all/modules/ or /sites/all/themes/.
  8. That's it! Now you need to enable it.

You should end up with a folder structure something like:
screenshot of a mock-up files folder layout

For advanced users

If you have access to a Unix shell (e.g. SSH), the following series of commands will download and extract the files directly to your server.

Before you start, use the pwd (print working directory) command to confirm that you are in the correct directory (e.g. modules). If not, use the ls (list directory) and cd (change directory) commands to navigate to the correct directory.

Steps:
  1. Step Download Archive:
    wget http://copy_and_paste_archive_url/sitedoc-5.x-1.x-dev.tar.gz
  2. Step Uncompress Archive: tar zxvf sitedoc-5.x-1.x-dev.tar.gz
  3. Step Delete/Remove Archive: rm sitedoc-5.x-1.x-dev.tar.gz
  4. Note: the module sitedoc-5.x-1.x-dev.tar.gz is taken here as example please check the current version and or substitute with your preferred module.

Recommended modules for Drupal

Aminto - September 3, 2009 - 20:15

I've put together an end user guide which includes a list of some recommended modules for Drupal, an introduction to SEO and answers to a handful of FAQ's. It's aimed at end users rather than Drupal developers, so if you're an end-user, you may well find it useful:

http://www.1websitedesigner.com/drupal-end-user-guide

The modules are all important for pretty much every site (SEO, text editors, adding images easily, backing up your site automatically, automatic cron runs, etc.)

My site structure is different

brighty - September 29, 2009 - 09:21

I have just installed a new version of drupal (6.14) and my structure is different to that shown above. I have a 'modules' folder and a 'themes' folder at the top level (not in 'sites/all'). The modules folder then has the individual core modules stored directly below it (there is no intermediate folder called 'default'). Where should I download extra modules to in this set up?

/modules and /theme are core

bagelzorg - September 29, 2009 - 11:57

/modules and /theme are core files and for the core install.

6.14 should already have /sites/all/ /sites/default in place.
It must have /sites/default/ as that's where the settings file is.

If not you can just create them yourself.

You might also find it useful to place your modules under subdirs in the modules dir.

/sites/all/modules/{subdir}/

{subdir} might be 'contrib', 'custom', 'testing'

Hope that helps.

Thanks - that does help. It

brighty - September 29, 2009 - 13:00

Thanks - that does help. It just wasn't very clear from the instructions above that you have to *create* a folder called 'modules' under 'sites/all' - I was looking for it and was confused when it wasn't there in the first place.

Personally I wouldn't stick

jp.stacey - September 29, 2009 - 16:05

Personally I wouldn't stick anything in sites/all . It means that site foo can no longer be contained in sites/foo.example.com , so it looks fabulous until you try to deploy it to a fresh Drupal core installation and suddenly everything catches fire and falls over. Having to put WYSIWYG editors in sites/all/libraries is a pain in itself, especially if different clients are working off different versions of the TinyMCE editor, but there's not much of a way around that.

My recommendation is: stick each site's modules and themes in sites/foo.example.com/modules and sites/foo.example.com/themes . Avoid sites/all and try to move away from sites/default (use a URL-based site directory instead). Change the file upload directory to be sites/files/foo rather than files/ or sites/foo.example.com/files . That means that your files will (a) be development/staging/production-independent (b) any links to files in your content won't have to be updated when you move to a different Drupal environment and (c) all your non-core files are in a single sites directory. With everything custom in sites it's much easier to upgrade core.

Well

NancyDru - September 29, 2009 - 13:41

To some extent, it depends on whether you do multisite or not. My development is done on my local PC where all sites are part of a multisite. Some of my live sites are single and some are multis.

On a single site, it is slightly easier to put contributed modules in sites/default/modules and themes (including modified core themes) into sites/default/themes.

On multsites, it gets a bit more complicated, but terribly so. I put modules that will be used by more than one site in sites/all/modules (which you have to create), and, of course, themes in sites/all/themes. If there is a site-specific module, or version, then that is placed in sites/sitename/modules (or sites/sitename/themes).

On a side note, I do NOT use sites/sitename/files for my files directories, I create a files/site-short-name for those. I find this much better for moving from my development site to the live site with minimal effort (and changing hosts, if ever needed).

 
 

Drupal is a registered trademark of Dries Buytaert.