Drupal 6 Base Installation Settings

Michael J. Ross

One of my earlier articles , "Drupal 6 Modules for Every Website", presented a set of contributed and optional core modules that, in my experience, are so valuable for any Drupal 6-based website, that they may as well be installed and enabled right from the start. Doing that work in a default Drupal 6 installation does not result in a formal distribution or installation profile, but can be regarded as a simple base installation.

Yet that article did not cover the configuration settings for the modules, as well as all the other possible changes to the default Drupal settings that make for a better starting point for a new project. Here I will explore those settings and the advantages they confer, with screenshots where appropriate. These instructions assume that you have enabled all of the modules mentioned in that article.

Essential Directories

Unlike its successor, the default Drupal 6 installation profile does not include two key directories that should be created before or immediately after the installation process: sites/all/modules/ and sites/all/themes/. These directories are the proper places for installing all contributed (a.k.a. "contrib") modules and themes as they are added to this particular instance of Drupal. One should never install contrib modules or themes in the modules/ and themes/ directories that are in the Drupal root directory; those are for core modules and themes only.

Even though one can build a variety of powerful websites using nothing more than Drupal core and the thousands of modules and themes contributed to it, you may reach a point in your Drupal endeavors that you decide to program your own modules and integrate them into your own or client sites. In that case, you should install those custom modules in a new directory, sites/all/modules/custom/, to keep all of your own code consolidated in one location. Some Drupal developers follow the practice of then moving all of the contrib modules into a new directory, sites/all/modules/contrib/. This practice is optional, and is your decision. Drupal supports either approach equally well. One advantage is that it allows you to do a global search through all of the contrib module code that is not your own, in a single search operation. One disadvantage is that, when traversing the directory tree — in your editor, or IDE, or FTP client program, or command line — there's usually an extra step to arrive at the contrib modules.

You may also want to follow a practice that I have found valuable, namely, creating a _database/ directory in the Drupal root. It is useful for storing all of the eventual database backups (both local and remote), as well as the MySQL file for creating the database on the local MySQL server (by importing the file in phpMyAdmin). Prefixing the directory name with an underscore serves as a visual reminder that this directory is not to be uploaded to any remote server. It also forces the directory name to sort to the top of the directory list, thereby speeding up the selection and upload of the files and directories that belong on any remote server. A similar directory is _archive/, which is handy for storing all miscellaneous files that should not be added to any remote server, such as project documents and extra images.

Content and Content Types

When building a Drupal-based website, one of the first orders of business is to define the content types — at least as well as possible given what is known of the intended functionality of the site. Most of the initial content-related settings are fine. However, by default, Drupal limits the length of trimmed posts — which include any promoted to the home page — to 600 characters. Anything beyond that is replaced with a "read more" link. This is fine for blog sites, but most client sites have different needs. For those projects, the home page consists of one or more stories that might be much longer than 600 characters, and you don't want clients or site visitors to encounter home page content that is unexpectedly truncated. So I disable this at admin/content/node-settings, by setting "Length of trimmed posts" to Unlimited.

In the aforementioned article on modules, I recommended the "Add another" module to speed up the process of creating multiple nodes of the same content type. Go to admin/settings/addanother, and for both the Page and Story content types, click the checkboxes under "Enable Add another for these content types". Later, as you manually add more content types, or new modules do the same, revisit this page to enable those content types as well.

Enable Add another
Figure 1. Enable Add another

When Drupal displays a time value, by default it uses the 24-hour format (e.g., 13:00 instead of 1:00pm).

Date formats (default)
Figure 2. Date formats (default)

This may be what countless Asians and Europeans are accustomed to, but for most if not all US-based non-military clients, they and their site visitors will demand an AM/PM format, which can be set at admin/settings/date-time/formats. Some of the available formats also use the MM/DD/YYYY order (with the month number followed by the day number), which is standard in the United States.

Date formats (United States)
Figure 3. Date formats (United States)

Input Formats

When any user is typing text into an entry field, it is stored as is in the Drupal database. But when it is displayed on the website, it can and should be filtered to prevent unapproved HTML tags from changing the appearance or behavior of the page. These filters are encapsulated in input formats, which are managed at admin/settings/filters. "Filtered HTML" is the safest choice, in that it allows the most limited set of HTML tags: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd>. Unfortunately, most developers find that set to be too limited, and missing some safe and frequently needed tags: <address> <div> <pre> <h1> <h2> <h3> <h4> <h5> <h6> <sup> <u>. That last one may be much frowned upon by the web community, but CKEditor needs it for showing underlined text (which some clients will insist upon using, despite your fervent advice otherwise). On the Configure tab (admin/settings/filters/1/configure), you can add these extra tags.

For both the "Filtered HTML" and "Full HTML" formats, the default behavior is to use break tags (<br />) and paragraph tags (<p></p>) to format user-entered line breaks, which unfortunately often makes a mess of the content. So I always disable that option for both input formats. If you are going to allow users to enter HTML tags, they should learn to use the most basic ones properly, as early as possible.

Users, Roles, and Permissions

For some inexplicable reason, by default Drupal 6 allows unknown visitors (human or otherwise) to sign up for new accounts (see admin/user/settings).

User account registration
Figure 4. User account registration

Admittedly, these new accounts are blocked by default, but that's not going to stop all sorts of online miscreants from filling up your account request queue. Change the setting to "Only site administrators can create new user accounts".

But that's not to say that you want your website to be completely antisocial. Most sites should have some sort of contact form, allowing visitors to send messages without knowing any of your clients' email addresses. This is most easily achieved using the Contact module. Visit the permissions management page (admin/user/permissions), locate the "contact module" section, and enable "access site-wide contact form" for anonymous and authenticated users.

Links and Menus

The Pathauto module is wonderful for automatically defining search-engine-friendly URLs. But for some reason its creators decided that underscores should, by default, be stripped out, which has the unfortunate side effect of concatenating two words that would have otherwise been detected and understood by search engines. This can cause problems, e.g., "http://www.example.com/pen_is_mightier.jpg" becomes "http://www.example.com/penismightier.jpg". So go to admin/build/path/pathauto, and in the Punctuation settings, change the value for Underscore to either "Replaced by separator" (which by default is a hyphen) or "No action (do not replace)" (since search engines process underscores similar to hyphens).

Nice Menus is a module that allows you to easily create exactly that. Almost every website nowadays uses drop-down menus, so you may as well configure them once and for all. Go to admin/settings/nice_menus, and set the number of menu blocks to 1. On the blocks management page (admin/build/block), move the "Nice menu 1 (Nice menu)" block to the Header region. After saving the change, you should see the Navigation menu in the Header region. But that is usually not the menu you will want in the header. So configure the block (admin/build/block/configure/nice_menus/1) by setting the Block title to "<none>", the Menu Name to "Main Menu", the Menu Parent to "Primary links", and the Menu Style to "down" (since most navigation menus are designed to drop down, rather than popping out to the right). The Navigation menu disappears from the Header region, but as you add links to the Primary links menu, they will show up in the header.

Appearance and Themes

Page elements other than menus contribute to the look and feel of your future website. By default, the site name is "localhost", and appears in the header and the window title. You should visit the site configuration page (admin/settings/site-information) and change the site name to something more meaningful, such as "D6 - base site".

Clients likely will not want their sites advertising Drupal, so return to the block admin page (admin/build/block) and disable the "Powered by Drupal" block.

Also, when clients are managing their own content, it is quite possible that their public-facing theme is designed in such a way as to inadvertently make content management difficult. On the Administration theme page (admin/settings/admin), set Garland as the administration theme, and enable "Use administration theme for content editing". Now, no matter how messed up the default theme may become (for whatever reason), you and the client will always have a dependable and readable theme for administering the site.

For most projects, clients do not want the user names and modification dates displayed for content added to the home page or other story locations. Hence, on the global settings page for themes (admin/build/themes/settings/global), for the Story content type, disable the "Display post information on" option. Also disable the mission statement. If the theme calls for the site name in the header to be displayed as an image, then disable the "Site name" option.

Garland and Minelli (its fixed-width counterpart) are the only decent built-in Drupal 6 themes, so you may as well reduce complexity and disk space usage by deleting all of the others from the modules/ directory. Those would be the bluemarine, chameleon, and pushbutton directories. Do not delete the engines directory! Do not delete Minelli, even if you do not plan on using it, because otherwise it could result in "undefined function: phptemplate_get_ie_styles()" errors.

Help Information

The "Advanced help" module makes it easier for developers to store help information outside of their module files, in HTML files. But if the module is missing, you may see (useless) warning messages. Go to the Tools page for the Views module (admin/build/views/tools), and enable the "Ignore missing advanced help module" option.

On the modules management page (admin/build/modules), above the list of modules, there are six paragraphs of help information, which fill roughly half the page, and push the module list down.

Modules admin with help info
Figure 5. Modules admin with help info

None of that text is needed, once you have become familiar with administering a Drupal site. To hide this help information on this page and others, you can add the following CSS code to Garland's primary stylesheet, or to the stylesheet of whatever theme you use for administration: .help { display: none; }

Modules admin without help info
Figure 6. Modules admin without help info

Admittedly, this is an example of "hacking core", which is usually and justifiably condemned. But this change is slight, and will make administering modules easier.

Unneeded Files

The default Drupal installation contains all sorts of files that may be valuable as references when you would like to learn more about core modules and other components. But those files can always be found in the Drupal package, and are rarely referenced. So you may as well eliminate them, which saves space and reduces clutter on any web servers to which this base installation is placed, as well as all derivative sites. You can safely delete the following files (whose paths shown here are relative to the root directory):

That last one need only be retained if you plan on doing remote procedure calls, but otherwise may pose an unnecessary security hole. This deletion process can be encoded in a script, to save time in the future, when creating similar base installations.

There are probably countless other ways that one could optimize a starter Drupal site, and you may already have some of your own. I hope the information provided here can supplement whatever configuration settings you have already found to be worthwhile.

Copyright © 2011 Michael J. Ross. All rights reserved.
bad bots block