Installation and configuration

Formatted Drupal 5.x Installation instructions for better readability

Installation

// $Id: INSTALL.txt,v 1.39 2007/01/08 11:59:16 dries Exp $

Table of Contents

1. Changes
2. Requirements
3. Optional requirements
4. Installation
5. Drupal administration
6. Customizing your theme(s)
7. Multisite Configuration
8. More Information

Changes

As of Drupal 5.0 installation has been automated by an install script. It is no longer necessary to manually edit the "settings.php" file, and database tables are created automatically.

Requirements

Drupal requires a web server, PHP4 (4.3.3 or greater) or PHP5 (http://www.php.net/) and either MySQL (http://www.mysql.com/) or PostgreSQL (http://www.postgresql.org/). The Apache web server and MySQL database are recommended; other web server and database combinations such as IIS and PostgreSQL have been tested to a lesser extent. When using MySQL, version 4.1 or greater is recommended to assure you can safely transfer the database.

For more detailed information about Drupal requirements, see "Requirements" (http://drupal.org/requirements) in the Drupal Handbook.

Guidelines for setting up a server environment with a variety of operating systems and in special cases are available in the Drupal handbook (http://drupal.org/node/260)

Optional Requirements

- To use XML-based services such as the Blogger API, Jabber, and RSS syndication, you will need PHP's XML extension. This extension is enabled by default.

- If you want support for clean URLs, you'll need mod_rewrite and the ability to use local .htaccess files.

Installation

1. Download Drupal

You can obtain the latest Drupal release from http://drupal.org/. The files are in .tar.gz format and can be extracted using most compression tools. On a typical Unix command line, use:

This will create a new directory drupal-x.x/ containing all Drupal files and directories. Move the contents of that directory into a directory within your web server's document root or your public HTML directory:

     mv drupal-x.x/* drupal-x.x/.htaccess /var/www/html 

2. Create the Drupal database

Drupal requires access to a database in order to be installed. Your database user will need sufficient privileges to run Drupal. Additional information about privileges, and instructions to create a database using the command line are available in INSTALL.mysql.txt (for MySQL) or INSTALL.pgsql.txt (for PostgreSQL).

To create a database using PHPMyAdmin or a web-based control panel consult the documentation or ask your webhost service provider.

Take note of the username, password, database name and hostname as you create the database. You will enter these items in the install script.

3. Run the install script

The install script will set the base URL, connect Drupal to the database, and create tables in the database.

To run the install script point your browser to the base url of your website (i.e. http://www.example.com). You will be presented with the "Database Configuration" page.

The install script will attempt to write-protect the settings.php after updating it with the information you provide in the installation routine. If you make manual changes to that file later, be sure to protect it again after making your modifications. Failure to remove write permissions to that file is a security risk. The default location for the settings.php file is at sites/default/settings.php, but it may be in another location if you use the multi-site setup, as explained below.

4. Configure Drupal

When the install script succeeds, you will be directed to the "Welcome" page. In "step one" click "create the first account" which will become the main administrator account with total control. Login as the administrator and complete the initial configuration steps on the "Welcome" page.

Consider creating a "files" subdirectory in your Drupal installation directory. This subdirectory stores files such as custom logos, user avatars, and other media associated with your new site. The sub-directory requires "read and write" permission by the Drupal server process. You can change the name of this subdirectory at "administer > site configuration > file system".

5. Cron Tasks

Many Drupal modules (such as the search functionality) have periodic tasks that must be triggered by a cron job. To activate these tasks, call the cron page by visiting http://www.example.com/cron.php --this will pass control to the modules and the modules will decide if and what they must do.

Most systems support the crontab utility for scheduling tasks like this. The following example crontab line will activate the cron tasks automatically on the hour:

   0   *   *   *   *   wget -O - -q http://www.example.com/cron.php 

More information about the cron scripts are available in the admin help pages and in the Drupal handbook at drupal.org. Example scripts can be found in the scripts/ directory.

Drupal Administration

A new installation of Drupal defaults to a very basic configuration with only aw active modules and minimal user access rights.

Use your administration panel to enable and configure services. For example:

General Settings     administer > site configuration > site information
Enable Modules     administer > site configuration > modules
Set User Permissions     administer > users management > access control
Configure Themes     administer > site building > themes

For more information on configuration options, read the instructions which accompany the different configuration settings and consult the various help pages available in the administration panel.

Community-contributed modules and themes are available at http://drupal.org/.

Customizing your theme(s)

Now that your installation is running, you will want to customize the look of your site. Several sample themes are included and more can be downloaded from drupal.org.

Simple customization of your theme can be done using only CSS. Further changes require understanding the phptemplate engine that is now part of Drupal. See http://drupal.org/handbook/customization to find out more.

Multi-site configuration

A single Drupal installation can host several Drupal-powered sites, each with its own individual configuration.

Additional site configurations are created in subdirectories within the 'sites' directory. Each subdirectory must have a 'settings.php' file which specifies the configuration settings. The easiest way to create additional sites is to copy the 'default' directory and modify the 'settings.php' file as appropriate. The new directory name is constructed from the site's URL. The configuration for www.example.com could be in 'sites/example.com/settings.php' (note that 'www.' should be omitted if users can access your site at http://example.com/).

Sites do not have to have a different domain. You can also use subdomains and subdirectories for Drupal sites. For example, example.com, sub.example.com, and sub.example.com/site3 can all be defined as independent Drupal sites. The setup for a configuration such as this would look like the following:

sites/default/settings.php
sites/example.com/settings.php
sites/sub.example.com/settings.php
sites/sub.example.com.site3/settings.php

When searching for a site configuration (for example www.sub.example.com/site3), Drupal will search for configuration files in the following order, using the first configuration it finds:

sites/www.sub.example.com.site3/settings.php
sites/sub.example.com.site3/settings.php
sites/example.com.site3/settings.php
sites/www.sub.example.com/settings.php
sites/sub.example.com/settings.php
sites/example.com/settings.php
sites/default/settings.php

If you are installing on a non-standard port, the port number is treated as the deepest subdomain. For example: http://www.example.com:8080/ could be loaded from sites/8080.www.example.com/. The port number will be removed according to the pattern above if no port-specific configuration is found, just like a real subdomain.

Each site configuration can have its own site-specific modules and themes in addition to those installed in the standard 'modules'and 'themes' directories. To use site-specific modules or themes, simply create a 'modules' or 'themes' directory within the site configuration directory. For example, if sub.example.com has a custom theme and a custom module that should not be accessible to other sites, the setup would look like this:

sites/sub.example.com/:
settings.php
themes/custom_theme
modules/custom_module

NOTE: for more information about multiple virtual hosts or the configuration settings, consult the Drupal handbook at drupal.org.

More Information

For platform specific configuration issues and other installation and administration assistance, please consult the Drupal handbook at http://drupal.org/handbook. You can view the wide range of other support options available at http://drupal.org/support.

Formatted Drupal 4.7.x Installation instructions for better readability

Installation

// $Id: INSTALL.txt,v 1.6 2004/11/27 11:28:55 dries Exp $

This document outlines the standard installation process.

1. REQUIREMENTS
2. SERVER CONFIGURATION
3. OPTIONAL COMPONENTS
4. INSTALLATION
5. DRUPAL ADMINISTRATION
6. CUSTOMIZING YOUR THEME(S)
7. UPGRADING
8. MORE INFORMATION

REQUIREMENTS

1. Drupal requires a web server, PHP4 (http://www.php.net/) and either
   MySQL, PostgreSQL or a database server supported by the PHP PEAR API
   (http://pear.php.net/).
2. To Install you will need an FTP program to upload files to the server, or shell access if you wish to install using the commands listed below; access to run database scripts directly or a tool such as PHPMyAdmin to manage a database; knowledge of how to use either FTP programs or shell access to set permissions on directories, and how to run database scripts.
3. NOTE: The Apache web server and MySQL database are strongly recommended;
   other web server and database combinations such as IIS and PostgreSQL
   are possible but tested to a lesser extent.

SERVER CONFIGURATION

Your PHP must have the following settings:

session.save_handler     user

In addition, we recommend the following settings:

session.cache_limiter    none

These values are set in php.ini and can be overwritten in a .htaccess
file; you can print out your local PHP settings with PHP's phpinfo()
function.

OPTIONAL COMPONENTS

• To use XML-based services such as the Blogger API, Jabber, RSS
  syndication, you will need PHP's XML extension. This extension is
  enabled by default in standard PHP4 installations.
• If you want support for clean URLs, you'll need mod_rewrite and
  the ability to use local .htaccess files. (More information can
  be found in the Drupal handbook on drupal.org.)

INSTALLATION

1. DOWNLOAD DRUPAL

You can obtain the latest Drupal release from http://drupal.org/.
Download the current tar.gz format and extract the files:

This will create a new directory drupal-x.x.x/ containing all
Drupal files and directories. Move the contents of that directory
into a directory within your web server's document root or your
public HTML directory:

$ mv drupal-x.x.x/* drupal-x.x.x/.htaccess /var/www/html

2. CREATE THE DRUPAL DATABASE

These instructions are for MySQL. If you are using another database,
check the database documentation. In the following examples,
"dba_user" is an example MySQL user which has the CREATE and GRANT
privileges. You will need to use the appropriate user name for your
system.

First, you must create a new database for your Drupal site:

$ mysqladmin -u dba_user -p create drupal

MySQL will prompt for the dba_user database password and then create
the initial database files. Next you must login and set the access
database rights:

$ mysql -u dba_user -p

Again, you will be asked for the dba_user database password. At the
MySQL prompt, enter following command:

where

• 'drupal' is the name of your database
• 'nobody@localhost' is the userid of your webserver MySQL account
• 'password' is the password required to log in as the MySQL user

If successful, MySQL will reply with

Query OK, 0 rows affected

to activate the new permissions you must enter the command

flush privileges;

and then enter '\q' to exit MySQL.

3. LOAD THE DRUPAL DATABASE SCHEME

Once you have a database, you must load the required tables:

$ mysql -u nobody -p drupal < database/database.mysql

4. CONNECTING DRUPAL

The default configuration can be found in the
'sites/default/settings.php' file within your Drupal installation.
Before you can run Drupal, you must set the database URL and the
base URL to the web site. Open the configuration file and edit the
$db_url line to match the database defined in the previous steps:

$db_url = "mysql://username:password@localhost/drupal";

Set $base_url to match the address to your web site:

$base_url = "http://www.example.com";

In addition, a single Drupal installation can host several
Drupal-powered sites, each with its own individual configuration.
If you don't need to run multiple Drupal sites, you can skip to the
next section.

Additional site configurations are created in subdirectories within
the 'sites' directory. Each site subdirectory must have a
'settings.php' file which specifies the configuration settings. The
easiest way to create additional sites is to copy the 'default'
directory and modify the 'settings.php' file as appropriate. The new
directory name is constructed from the site's URL. The
configuration for www.example.com could be in
'sites/example.com/settings.php' (note that 'www.' should be omitted
if users can access your site at http://example.com/).

Sites do not each have to have a different domain. You can use
subdomains and subdirectories for Drupal sites also. For example,
example.com, sub.example.com, and sub.example.com/site3 can all be
defined as independent Drupal sites. The setup for a configuration
such as this would look like the following:

When searching for a site configuration (for example
www.sub.example.com/site3), Drupal will search for configuration
files in the following order, using the first configuration file it
finds:

Each site configuration can have its own site-specific modules and
themes that will be made available in addition to those installed
in the standard 'modules' and 'themes' directories. To use
site-specific modules or themes, simply create a 'modules' or
'themes' directory within the site configuration directory. For
example, if sub.example.dom has a custom theme and a custom module
that should not be accessible to other sites, the setup would look
like this:

NOTE: for more information about multiple virtual hosts or the
configuration settings, consult the Drupal handbook at drupal.org.

5. CONFIGURE DRUPAL

You can now launch your browser and point it to your Drupal site.

Create an account and login. The first account will automatically
become the main administrator account.

6. CRON TASKS

Many Drupal modules have periodic tasks that must be triggered by a
cron job. To activate these tasks, you must call the cron page;
this will pass control to the modules and the modules will decide
if and what they must do.

The following example crontab line will activate the cron script
on the hour:

0    *   *   *   *   wget -O - -q http://HOSTNAME/cron.php

More information about the cron scripts are available in the admin
help pages and in the Drupal handbook at drupal.org. Example
scripts can be found in the scripts/ directory.

DRUPAL ADMINISTRATION

Upon a new installation, your Drupal website defaults to a very basic
configuration with only a few active modules, one theme, and no user
access rights.

Use your administration panel to enable and configure services. For
example, set some general settings for your site with "Administration -
configuration". Enable modules via "Administration - configuration -
modules". User permissions can be set with "Administration - accounts
- permissions".

For more information on configuration options, read through the
instructions which accompany the different configuration settings and
consult the various help pages available in the administration panel.

Note that additional community-contributed modules and themes are
available at http://drupal.org/.

CUSTOMIZING YOUR THEME(S)

Now that your server is running, you will want to customize the look
of your site. Several sample themes are included in the Drupal
installation and more can be downloaded from drupal.org.

Customizing each theme depends on the theme. In general, each theme
contains a PHP file themename.theme which defines a function header()
that can be changed to reference your own logos.

Most themes also contain stylesheets or PHP configuration files to
tune the colors and layouts; check the themes/ directory for README
files describing each alternate theme.

UPGRADING

1. Backup your database and Drupal directory - especially your
   configuration file (www.example.com.conf or includes/conf.php).
2. Log on as the user with user ID 1.
3. Remove all the old Drupal files then unpack the new Drupal files
   into the directory that you run Drupal from.
4. Modify the new configuration file to make sure it has the
   correct information.
5. Run update.php by visiting http://www.example.com/update.php.

MORE INFORMATION

For platform specific configuration issues and other installation and
administration assistance, please consult the Drupal handbook at
http://drupal.org/. You can also find support at the Drupal support forum or through the Drupal mailing lists.

10 minute install using PuTTY SSH/Telnet client

I've been developing best practices for my development company and wanted to share/collaborate on some of them.

Development environment:

Server: LAMP
SSH/Telenet Client: PuTTY
Server Interface: WHM
Must have root access.

10 minute Install:

How I installed Drupal: The Eightfold Way

Try this for a supereasy install.

This installation is for a test site.

The aim is to have a test site: \http://drupal.yoursite.com\

When the test site is functioning, the drupal subdomain prefix will be deleted. Therefore the domain name in the root will be mysite.com The DNS servers will automatically point to this (hopefully!). This is what worked for me:

1) Downloaded Drupal 5.0
2) Created a subdomain ("drupal") via my webhost's control panel
3) Created a database ("dbname") via my webhost's control panel (note the user name and password). Noted the hostname, e.g., testsite.yoursite.com
4) Using browser, pointed to URL \http://drupal.yoursite.com\
5) The install.php script automatically installed Drupal
6) Entered information. Database name ("dbname"), username, password
7) Clicked "Advanced options"
8) Entered hostname (e.g., testsite.yoursite.com). Went to testsite.yoursite.com in browser.

Installing virtual hosts for Drupal sites and subsites

The purpose of this guide is to concisely summarize how to implement apache vhost settings for each site or subsite.

All steps for this tutorial were implemented with Debian using Apache version 2.0.54.

1. Gain entrance into your shell system, and su to root or another user that can edit apache2 configuration files.
2. Go to your apache configuration files:
   cd /etc/apache2/sites-available
3. Create a configuration file for your new site. For an example site, www.example.com, we make the site as such:
   nano example.com

• Activate the site's configuration:
  a2ensite www.example.com
• Reload Apache's configuration:
  /etc/init.d/apache2 force-reload

• Done!

  Please post any changes or concerns,

  Tarek : )

Mac OS X-specific guidelines

Install and configure Mysql and PHP, if necessary. Server Logistics provides nice pre-compiled packages and instructions. PHP is also available from Marc Liyanage. PHP may already be installed on your system, so check first.

The stock version of Apache should be fine (typically 1.33).

Turn on "personal web sharing" in the sharing panel of System Preferences to start Apache. Now comes the more involved part- changing the webserver configuration.

To make changes to the Apache configuration you should NOT edit /etc/httpd/httpd.conf but instead edit files in /private/etc/httpd/users/. Any file in the directory /private/etc/httpd/users/ ending with “.conf” will effectively be appended to /etc/httpd/httpd.conf. So any changes you want to make should be made in one or more configuration files of your own construction. System updates will leave these files untouched. You can create a file /private/etc/httpd/users/drupal.conf for all your Drupal-specific changes (even if you have no user named Drupal) and they will be loaded when Apache starts up.

Note: for Mac OS X Server 10.4 (Tiger Server) and most likely previous versions as well, do not make changes to /etc/httpd/httpd.conf expecting the AllowOverride All directive to work. The correct file to add the AllowOverride All directive is in the directory /etc/httpd/sites/. In that directory are the virtual host configuration files. Each virtual server has a configuration file in that directory so it is in those files that you must enable AllowOverride All. If you only have one web server on your server configured, then the file you want to modify is /etc/httpd/sites/0000_any_80_.conf.

To enable clean URLs you will need the following code in your conf file. You'll need to be root (or sudo) to do this. Don't forget to restart apache after modifying httpd.conf (turn personal web sharing off, then back on again, or use /usr/sbin/apachectl restart).

You may also need to edit this file to enable the PHP module for Apache. You have to uncomment two lines. First in this section:

Uncomment this line (around line 235) by removing the #:

Then go below to this section:

and uncomment this line (around line 278) by removing the #:

Drupal goes into /Library/WebServer/Documents/, or ~/Sites. If you use ~/Sites, you may also have to edit the .conf file in /etc/httpd/users that corresponds to your user account. You must AllowOverride in this file for your ~/Sites for clean URLs to work there.

After any edits to your .conf files, be sure to restart Apache (as described above).

MacZeaolots has a good tutorial on installing Drupal on Mac OS X 10.4. The same tutorial applies to 10.3 as well. While the tutorial talks about Drupal 4.6, the setup of the server environment is the same for any version of Drupal.

Important notes for MySQL install:

The version of PHP that Apple included with Mac OS X 10.4.4 has mysql.default_socket set to "/var/mysql/mysql.sock", while the binary version of MySQL from mysql.com uses "/tmp/mysql.sock". This will cause PHP to fail to connect to mysql with a message in Drupal like

can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (2)

Make PHP look for "/tmp/mysql.sock" by setting this in /etc/php.ini:

You can instead set this in /etc/my.cnf.

Both work, but the second one may make the MySQL preference pane stop working.

You may also need to restart apache to have this take effect.

Restart from the terminal:

$ sudo apachectl restart

or restart by disabling and re-enabling personal web sharing.

Prefixed database.mysql for search and replace

Use a texteditor with search & replace functionality to replace 'prefix' with your own eg. site1, site2.
This is database.mysql from 4.6.5. Contributed by Shane Birley.

Setup Drupal on Windows XP Pro using IIS

While trying to install Drupal on stand alone machine with Windows XP Pro & IIS I was unable to find all the installation information at one place therefore I am sharing my experiences and solutions to the problems. I think it will be useful for people who are new to Drupal because Drupal on stand alone machine reduces the learning curve.

Setup Drupal on Windows XP Pro using IIS:
1. Download Mysql server and install. (I have used ver. 5.0)
2. Download PHP and install. (I have used ver. 4)
3. Download Drupal (I have used ver. 4.7.3).
4. Create a folder with any name for example Drupal in Inetpub folder in C: drive.
5. Open IIS and create virtual folder giving alias and path of the Drupal folder which you have just created in Inetpub.
6. Untar (you can use Winrar for this) the downloaded drupal file contents in Drupal folder.
7. Create a schema/database with any name example drupaldata and create a user.
8. Now grant privileges to this user.
Grant ALL ON databasename.*
TO 'username'@'localhost' IDENTIFIED BY 'password';
Flush privileges;

9. Modify the file C:\Inetpub\wwwroot\[YOURDIRNAME]\sites\default\settings.php by giving user name, password and database name.

10. Now browse this virtual folder with its alias name in IE example http://localhost/"aliasname"

11. If following error is displayed;
Client does not support authentication protocol requested by server; consider upgrading MySQL client

Then use these commands;
SET PASSWORD FOR 'some_user'@'some_host' = OLD_PASSWORD('newpwd');
Flush privileges;

12. Repeat step 10, I hope its working ….

Have a look at one of the pretty clean theme implementation in drupal - ENJOY . . .

Basic /sites directory setup

Version 5.x supports a new /sites/all directory. Best practice for basic initial setup is the following placements in the /sites directory:

Directory	Contents
/drupal/sites/all	/modules /themes
/drupal/sites/default	settings.php
/drupal/sites/example.com	/tmp /files (but see below)

Understand the different common locations. The /sites/all and the /sites/default directories are exclusive, and are intended for the above items. The critical principle is to keep all your site customizations within the /sites directory so that it is easy to upgrade when a new minor version of the Drupal core code is released (e.g. to update from 5.1 to 5.2).

Contributed and custom modules should be placed in /drupal/sites/all/modules. Additional and custom themes should be placed in /drupal/sites/all/themes.

The /files directory is usually best placed in the /sites/example.com directory, which you will have to create. Then set the 'File system path' at administer > site configuration > file system. This is ideal if a second site will likely need a separate /files directory; just create a second site-specific /files directory at /sites/example2.com/files. The same applies for the /tmp directory.

Upon initial installation the /files directory is set to /sites/default/files (you will need to create the actual directory). It can be fine to leave it there (or even to use /sites/files) if you are 100% you will never want to use multi-site features. However, this location shares the /files directory in a multi-site setup , which may or may not be desired. See "Setup of /sites directory for multi-site."

Backup is simplified by use of the /sites directory for all customizations. You can then easily backup all non-core material by backing up the /sites directory and the database.

For multi-site setup, see Multi-site installation and set-up, the sub-topic Setup of /sites directory for multi-site, and the installation instructions (INSTALL.txt). As stated above, there are two common locations in Drupal 5.x and above: /sites/default (for settings.php) and/sites/all (for common /modules and /themes). This allows a new site to be set up using the multi-site features by simply copying the /sites/default directory to /sites/example2.com

Version 4.6 and 4.7: To simplify backups and updates, the best practice (for a single-site install) is to place contributed modules in /sites/default/modules/, contributed or custom themes in /sites/default/themes/, and files in /sites/default/files (or even /sites/files). The /sites/all/ feature was added in Drupal 5.x. It will also work, but be more difficult to update your site, if contributed modules are placed in /drupal/modules, additional themes were placed in /drupal/themes, and files are stored in /drupal/files. If you expect to use multi-sites, then you should make use of /sites/example.com as explained in the "Setup of /sites directory for multi-site." Using /drupal/modules and /drupal/themes will also still work in 5.x, but the best practice above allows easier backup and expansion to multi-site.

Special cases

Various special situations (e.g., installing Drupal behind a firewall, installing Drupal in a subdirectory of the webserver's document root) are discussed in this section. Information specific to particular operating systems or database platforms may be found elsewhere.

Linux specific guidelines

Windows-specific guidelines

Several packages exist which install Apache, PHP, and MySQL in one easy download. These include the following:

• ApacheFriends XAMPP
• Miniserver
• Foxserv
• PHPHome

If you want to install them separately, see the guidelines below.

PostgreSQL specific guidelines

1. Create a PostgreSQL database for your site. createdb -U <i>username</i> -W <i>dbname</i>where username is the owner of the database (this user must have permission to create databases) and dbname is the name of your database. You will be prompted for that user's password. On success, the following is displayed:
   
   CREATE DATABASE
   .
   The user must also have the correct PSQL Grant privileges to use the database correctly.
2. Once you have a proper database, dump the required tables into your database:
   psql -U username -W dbname < database/database.pgsqlYou will be prompted for your database password. You should see a progress report as the tables are created. All has gone well if there are no lines marked "Error:" printed to the screen.
3. Set the database options in includes/conf.php so Drupal can access the database you have created. Edit
   the following line in includes/conf.php:
   $db_url = "pgsql://username:password@hostname/dbname";

HOWTO: Install glossary module

I just finished installing the Glossary module in three Drupal 4.7x websites, so I thought I'd write out some basic steps here:

Where is the Glossary?

One of the first things to try to understand is that, although we will install a "Glossary Module", all the glossary content is actually entered and created in "Administer>Categories*" as entries in a Vocabulary. Although Taxonomy Vocabularies are quite powerful, and contain many other uses (many of which I don't yet understand or I'm not yet aware of), this article only explains Vocabularies as they relate to the Glossary Module. The Glossary Module takes the Vocabulary entries and turns them into one or more Glossaries. Each time you create a new "Vocabulary", you are creating (the potential for) a new Glossary. (The Vocabulary terms are only turned into Glossaries when chosen in the "Administer>Input Formats" section.) (More about this later below.)
*Note: Although the Glossary content is entered through "Administer>Categories>Vocabularies" , don't get this confused with the optional, but different, Category Module, which adds it's own "Administer>Categories" menu listing.

What is the purpose of the Glossary Module, and what does it do?

Creates Glossary Page(s), the Glossary Module creates a glossary page of all your terms, with the definitions. You may create one or multiple glossaries.

Terms Identified:, on any page on your website, whenever you use any of the words in the glossary, those words will be identified on each page. You can choose whether the words will be identified by being underlined (with a broken line), or using a superscript letter (or word), such as the superscript letter "i", like thisⁱ (You can actually type in any letter or word that you want), or by using a small icon by the word. (You can also chose whatever icon you like)(see instructions below)

Definitions Available on "Hover", whenever the visitor "hovers" the mouse pointer over any one of the identified terms, the definition will "pop up" in a small box for about 6 seconds. This way the definitions of all the words in your glossary will be readily available every time you use any of those words.

Instantly Go to Glossary. If you click on the underlined word, or one of the identifiers (the superscript "i" or the small icon), you will immediately be taken to the full glossary page.

Full Page Definitions, you can attach full page (or multiple pages) of descriptions to any, or all, of the glossary terms. (see instructions for this at the bottom). If you have attached any full pages to any glossary term, the pop up definition will still work, but when you click on the word, you will be taken to the full page descriptions instead of to the glossary page. If you have multiple pages attached to the glossary term, then you will be shown the teasers of all the definition pages. You can then choose to look at any of those pages.

Installing the Glossary Module

More detailed instructions (for some of the following steps) can be found in the Glossary Readme file.

1. First download the Glossary Module from http://drupal.org/project/glossary onto your computer.(Some website control panels allow you to upload an archived file; zip, tar, etc. and then unarchive it after the file is on your website in a folder. If this is the case, then just upload the Glossary Module tar or zip file to your website. Otherwise, unzip the file on your computer, then ftp the whole folder to you website folder.)

• Using either a ftp program, such as FileZilla, or from your website control panel: file manager, upload the folder/files to (mywebsite.com/drupal/modules)

• Configuring the Glossary

  1. On your Drupal website, go to "Administer>Modules" and enable the glossary module and save the new configuration.
• Go to Administer>Categories: Add one or more Vocabularies. You might give the vocabularies names that will encompass all your terms. For example, since I do upholstery, I might name one of my Vocabularies "Upholstery Terms" , then add some terms.
• Go to Administer>Input Formats: Choose one of the input formats, for example chose “Filtered HTML”, At the right side, under "Operations", click on “configure”. This will take you to the "'Full HTML' input format" page.
• Under the “View” tab (which is the default), under “Filters,” enable the "Glossary filter", At the bottom of the page, click “Save Configuration”. After it is saved, you will be on the same page.
• Now, at the top of the page, click on the “configure” tab.
• Click on “Glossary Filter” which will open up some choices. In the “Select Vocabulary” box, click on the vocabulary term(s) that you created in Administer>Categories.
  • Next, do you want all the terms of your glossary to show on one page? (This would be suitable for small glossaries) If not, click in the box by "Show glossary across many smaller pages"
• The next choice is "Match Type". I haven't figured that one out yet, so I leave it alone on "Word".
• Chose whether you want your glossary terms to be case sensitive or insensitive. I usually chose case insensitive, since I want all the tems to show up, whether capitalized or not.
• Next, do you want all the terms on any given webpage to be identified as being in the glossary, or do you only want the first term on any page identified? Chose Replace Matches: "Only The First Match" or "All Matches".
• Under "Indicator Settings", you now make choise about how you want your terms identified on the website pages.
  Under "Term Indicator" Choose "superscript", "icon", or "replace with acronym link":
• Superscript:If you want a superscript letter (or word) by each word, like thisⁱ or this^term
• Icon: A default icon is installed with Drupal. the icon will follow the term in place of the superscript. If you want to choose a different icon, upload it somewhere on your website, such as your picture gallery, or a file, copy the URL to your chosen icon, and enter that URL into the Glossary Icon URL: text box.
• Underline: If you'd rather have all you terms underlined (only with a broken line), then choose "replace with acronym link" in the Term Indicator box.
• When you are finished with all of your choices, click on “save configuration”

• Glossary Administration: Finally, Choose which type of user(s) that you want to be able to administer the glossary, such as all "authenticated users" or only members in a "specific user role", or just the "administrator(s)". To make this choice, go to "Administer>Access Control>Permissions. Scroll down to "glossary module" and enable your chosen user role(s).

  Your Glossary Module should be working now. Go back to "Administer>Categories>Vocabularies" to enter your glossary/vocabulary terms. I would suggest that you keep your terms down to one brief paragraph. This paragraph will display all through the website whenever a user's mouse pointer "hovers" over the indicated word; it will only display for about 6 seconds. Keep your paragraph down to about 6 seconds of comfortable reading. (Yes, a user can go back to the indicated word and get the definition to pop up again, but why should they have to? You can put more detailed definitions or explanations on other page(s), which can be connected to any glossary/vocabulary term(s).)

  Adding Full Page Definitions

  Do you want to allow any registered user to add full page definitions to the glossary, or do you want only specific persons to have this ability? This is controlled through the "Administration>Input Formats". If you want every authenticated user to be able to add full pages to the glossary, then you would enable the glossary with each of the input formats available to those users. However, if you only want specific users to have that abililty, Use or create an input format that only those users, or type of users, will be using.
  .............>>> More to be added here later <<< .................

  Adding Glossary To Menus

  This part (below) needs to be written better, more later.

  1. To create additional glossary entries, go to Administer>Categories (as you did above) and enter more.
• (when your create Vocabulary (in Administer>Categories above), menu items and blocks are created for them, but not enabled.)
• If you want your Vocabulary to be on the website menu, go to Administer>Menus and enable them.
• If you want your Vocabulary to have its own menu block, go to Administer>Blocks and enable them.

• Stephen Winters
  Winters Sewing
  Winters Sewing: Upholstery Information Website
  Kingwood Bible: Community Website

Leech - automating content addition

The Leech module is an amazing module that automagically adds content to your site. Once its set up it will read RSS feeds and "leech" the articles from the originating site and each article as a node on your drupal site.

This is how you set up leech (4.7.x-1.6 as of 3/3/2007).:

Enable the following 2 modules:

1. leech

• node_template (which comes with leech)

• next, according to modules/leech/README.txt you have to do the following:

  1. create a story called "template story" and in the body of the story, put any place holder like "template node". Under publishing options disabled "Published"
  2. After creating the story, you will find the node now has a new tab called "template". Click on that and then on the button named "create"
  3. Next go to admin/settings/content-types and enable leech using the template created above. and save
  4. The final and most important part of the leech puzzle is from http://drupal.org/node/116859. which says you have to create a PAGE for each RSS feed. When you create content/page you will now find there is a new option called leech. put in your rss feed's url and wait for like 10 to 30 seconds. the advanced options will fill up with the data for your feed. Give your new leech feed a name and save. I don't believe any body would want this new leech feed posted to their front page so uncheck that option from under publish.
  5. once saved, there is still no data, depending on how often you set your leech module to check for updates (dependent on cron) you will either have to wait for the next cronjob or click on leech data now and VOILA! NEW STORIES!

  NB. its supposedly possible to use other node types and even CCK but i havent tried and the above is exactly what i need

Relationships between modules

This is a start to explain how similar or related modules are related and why you would use one vs another.

Internationalization
- Locale (core), i18n also known as Internationalization, and Translation

http://drupal.org/project/locale
- provides multiple translations of strings generated by drupal
- now part of the core code of drupal, critical if you want the site in something other than english

http://drupal.org/project/i18n
- provides a mechnanism to define multiple a single piece of content in multiple languages.
- requires locale module
- only use this if you want your site in English AND french

http://drupal.org/node/12875
- translation module which allows for people to switch between node content in other languages
- must require locale and i18n module
- designed to make it easier to produce sites in both english AND french

Module Comparisons

- http://drupal.org/project/scheduler vs http://drupal.org/project/event (applied to nodes)

- http://drupal.org/node/19813 vs taxonomy

Installing new modules (Drupal 4.6 or older)

After installing Drupal, you have the option of installing extra modules to extend or alter Drupal's behavior.

In brief. Download the module, extract, upload the folder into your Drupal modules folder, run the mysql file if necessary, and enable the module in administer » modules.

1. Download the new module. Make sure the version of the module is compatible with your version of Drupal. Also note that modules labeled CVS are considered unstable and should be handled with care. Often, CVS modules work only with the CVS version of Drupal. They may be in draft form, or be in the midst of active development.
2. Extract the module. When you first get the module, it will probably come in a compressed file format such as tar.gz. On Windows, use a program like WinZip to extract it. On the Mac, you can use Stuffit Expander. To extract the file using the Unix command line:

   tar -zxvf modulename-4.5.tar.gz

   You should see a list of files extracted in to a folder.

3. When you've extracted the file, upload the files via FTP to a folder inside the modules/ folder of your Drupal installation.
4. Read the installation file (usually INSTALL.txt and/or README.txt). Sometimes the installation file has no extension, so when you try to click on it, your computer doesn't know what program to use. In that case, open Notepad (or your favorite text editor) first, and then open the file into it.
5. There are modules that modify the database. You can generally tell if there is a modulename.mysql and/or modulename.pgsql file included with the module. If you do have to modify the database, see the next few steps. If you do not, please skip to step 7.
6. If you have to modify the database to get your module running, you will need to add tables to the database you made when you installed Drupal. Instructions given here are for MySQL.
   • Using phpMyAdmin:
   • If you have phpmyadmin, log in and go to your drupal database. If you have it, but do not know how to access it, please contact your host.
   • Click on the tab that says 'SQL'
   • You should see a text area labeled 'Run SQL query/queries on database yourdrupaldatabase'. Underneath, it says 'Or Location of the textfile:' Click browse, and find the modulename.mysql that came with the module. Click go. Unless your instructions for the module says anything else, that should be all you have to do to the database.
   • Using the Unix command line:
   • Run the following command.
   • mysql -u username -ppassword database_name < modulename.mysql
   • Replace 'username' with your MySQL username, 'password' (but keep the -p before it) with your MySQL password, 'database_name' with the database Drupal uses, and 'modulename.mysql' with the SQL file that the module comes with. You can generally find this out from settings.php in either the sites/default folder or the sites/sitedomain.com folder, replacing sitedomain.com for the domain that hosts Drupal.)
7. For most modules, all that is left is to activate it! To activate your module, you need to click administer » modules, check the box next to your new module name, and click on 'Save configuration' at the end.
8. Some modules will require you change permissions or settings to get them working as you like them. Permissions and settings info may be in the instructions that came with the module. If not:
9. 1. Click administer » access control. Scroll down to see if the module appears in the list and, if it does, give the appropriate permissions to roles.
   2. Click administer » settings and see if the name of the module you just installed is in the list. If it is, click the module name and configure as appropriate.
10. If you still run into the problems, search the forums. If your problem hasn't already been addressed, post a new post.

Note: To keep up to date on any issues and fixes you can create a user account (if you haven't done so all ready) and subscribe to each module you are using.

Note: You can have only one copy of a module with the same name in an Drupal installation.

10 Minute Multisite Install & Configuration

Multisite 10 minute Install:

Server: LAMP
SSH/Telenet Client: PuTTY
Must have root access to your server.

If website in question is an addon domain, i.e., addon.mydomain.tld, then substitute "www" for "addon" in steps below.

For list of Linux commands visit: http://www.oreillynet.com/linux/cmd/ or http://www.ss64.com/bash/

Here we go:

[login via PuTTY]

Get to location where Drupal core will be located:

[/]# cd /var/www

Upload Drupal core:

"x.x" should be replaced with the version of Drupal you're installing, e.g. "5.1"

[/var/www]# wget http://ftp.osuosl.org/pub/drupal/files/projects/drupal-x.x.tar.gz

Unpack Drupal core:

[/var/www]# tar -zxvf drupal-5.1.tar.gz

Move contents of Drupal core (including .htaccess) to html:

[/var/www]# mv drupal-x.x/* drupal-x.x/.htaccess /var/www/html

Clean-up:

Create the files directory per Drupal instructions and change permissions (will change permission again after install):

Make directories that will hold custom and contributes modules and themes:

Create directory "www.mydomain.tld":

Change permission of "settings.php" per Drupal instructions and copy "settings.php" in default to www.mydomain.tld:

Create database and user with permissions:

mysql> \q

Go back to PuTTY to chmod on settings.php in www.mydomain.tld:

What next?:

• Make changes to "settings.php" in www.mydomain.tld? I've read that it's not necessary to make changes to setting.php.
• Make changes to "httpd.conf" in /usr/local/apache/conf?

I've been using WHM to create accounts, putting Drupal in public_html and having no problems. But when it comes to parting from the WHM abstraction and getting multisite set-up correctly this is the end of the proverbial road for me.

Could use help...:

1. Help making improvements to steps articulated above
2. Help with next steps so that I/we can get on to grander things, like creating modules, custom themes, profiles, (and maybe - just maybe - spend some time working on business strategy :-)

Access all multisites with www. only [.htaccess]

The default .htaccess RewriteRule to redirect every multisite.com to www.multisite.com does not work properly.

If you have problems with that too, just leave the two lines uncommented, and ADD THE FOLLOWING 3 LINES FOR EVERY MULTISITE you set up:

(Thanks to Florian!)

Drupal as a library

Short introduction on how to share drupal with all users on a shared server (without having troubles with file-permissions).

Note: it is still possible to use the Multisite option of drupal.

example server's file-structure:

.htaccess (1)
this isn't neccessary but it keeps public_hml/ clean when several sites are maintained by one user. When only one site is maintained the contents of the main/ directory could be moved to public_html/ itself

Multi-site setup in 5.x using CPanel

After some searching around, I found out how to do multi-site setup using CPanel.

1. Create your initial Drupal site at www.yourdomain.com. Drupal 5.x makes this very easy to do, as it will automatically install the database for you -- all you have to do is input the database information.

2. Create a folder in the sites/ folder that matches the subdomain you want to create (so for site1.yourdomain.com, the folder name would be site1.yourdomain.com).

3. Duplicate the settings.php file from the default folder and place it in your newly created folder from step 2.

4. Edit the settings.php file you just placed in the site1.yourdomain.com folder so that it points to the correct database.

5. In CPanel, set up the subdomain. For the above example of site1.yourdomain.com, a folder named site1 will be automatically created by CPanel.

6. Delete the folder that was created.

7. Use the following example to create and upload a php file onto your site. An easy way to do this is to use Notepad, pasting in the text below, editing as necessary, and then saving as multisite.php. Afterwards, upload via FTP or CPanel's File Manager.

8. Go to the location of the php file in your browser (such as www.yourdomain.com/multisite.php)

This will create a symlink, allowing your subdomain to work properly.

9. Go to your subdomain. Drupal will install the tables necessary to run the new site.

10. You're all set to use the new site.

If you run into any problems, or have questions, use the contact form attached to my user account here to contact me.

Multi-Site, Single Codebase, Shared Database, Shared Sign-on 4.6

I used this option, having a network of interrelated sites. While each site has its own domain, offers its own theme and own primary (homepage) content, the sites are essentially related and needed to share user registration accounts and forums. With a shared database, they also share information, e.g. the site which offers reviews can also display news headlines in a sidebar; the site which offers classified ads can offer reviews in a sidebar; etc.

An unintended consequence of this approach is that savvy users can effectively navigate any and all content from any and all sites (once they understand breadcrumbs and drupal-specific navigation), so they get, essentially, whatever content they want in whatever theme they want.

Apache (http) Configuration

All domains will point to one document root. That cannot be emphasized enough. When using virtual hosting, do not create a separate virtual domain for each site -- only for the first site. When using a control panel such as cPanel or Ensim, create only the first domain. In the first domain's alias area, list all the additional domains and subdomains to be used. Your virtual hosting entries should end up like this:

ServerName www.firsthost.com
ServerAlias firsthost.com
ServerAlias secondhost.com www.secondhost.com
ServerAlias thirdhost.com www.thirdhost.com forums.thirdhost.com
etc...

DocumentRoot /home/virtual/whatever/var/www/html
etc...

Any request for any of the domains will all run to /home/virtual/whatever/var/www/html for response. This is the desired result.

Download and Placement

The code base should sit in the DocumentRoot defined above. Download the tar ball for the latest stable version (4.6 as of this writing) and open it in the doc root. Note: all remaining commands assume you are sitting in your doc root, so go there.

Check ownership and permissions - if you've downloaded directly, they're likely to be very wrong. Security note of caution: I typically go through and change permissions to 444 (read-only) for all .php, .gif, .jpg and .css files. In drupal, that'll also mean .module files. You'll have trouble editing these files, but that's the point. It's easier to change permissions temporarily on a file you want to hack than it is to fix a break-in.

SQL Setup

There are two ways to do this: on the command line and via a control panel. Some control panels (Ensim, for example) require that you create new databases through their interface (so they can limit a site to a set number of databases).

If you can create new databases through the command line, do it like in the install file -

I substituted Name for 'drupal' in the instructions -- really, name your database something other than 'drupal.' Helps to prevent hacking if the attacker isn't intimately familiar with the site configuration. Even if you call it mysite_drupal, that's something.

I also have no idea why the installation instructions suggest permissions for 'nobody,' so I changed that to the database user. If you don't have a database user setup for this site, setup an SQL user with its own unique password. phpMyAdmin makes it easy to do this.

If you have to create databases via your control panel, open it and go to the SQL page. Create a new, empty database associated with the correct host and call it what you will (see notes above about calling it 'drupal.' Most systems create a database user for each site; if yours doesn't, create that user and give it permissions for the database you just created.

Just because you have to create the database via the control panel doesn't mean you have to fill it that way. You can now return to the command line and setup the database structure.

Technically, you're done after the first line, but I like to lock up all setup files once I'm finished with them. This prevents someone else from trying to reset my system to hack in and prevents me from erasing my database in a fat-fingered typing accident.

Individual Site Configuration & Theming

Now, to the individual site information. Drupal will parse the http request and provide the correct content based on the domain name and settings files. You'll need one directory for each domain name and one settings file for each. You can link aliases together. In the example below, Drupal will load this settings.php file for calls to http://firsthost.com and http://www.firsthost.com.

Now, edit sites/firsthost.com/settings.php and enter the following values (using the SQL values above for user, password and database Name). This allows the site to connect up to the database created above, and to create links to itself correctly.

$db_url = 'mysql://user:password@localhost/Name;
$base_url = 'http://firsthost.com'; (or www.firsthost.com depending on preference)

And add the following lines (using site values). This overrides any theme or database settings to provide unique values for this site. Things you may want to override include the individual site's name, slogan, and theme. Also, you can use site_frontpage to set a default module. In the case below, we've chosen 'node' (generic stories) as the home page for this site.

$conf = array(
'site_name' => 'Name of the First Site',
'site_slogan' => 'My Original Drupal Site',
'site_frontpage' => 'node',
'theme_default' => 'pushbutton',
'anonymous' => 'Visitor'
);

Now, repeat from the 'mkdir' command for each new site. Some things will remain the same. The configuration variables will change. In the example below, we've changed the homepage to the book module and the theme to bluemarine. When Drupal parses a request for this second site, it will present those options.

$conf = array(
'site_name' => 'Name of the Second Site',
'site_slogan' => 'The We Love Drupal Fan Site',
'site_frontpage' => 'book',
'theme_default' => 'bluemarine',
'anonymous' => 'Dude'
);

You have working multisites. Call up the first domain, setup your administrative user and run with it. Keep in mind that sites/default is the settings.php file which will be used if Drupal doesn't recognize the http call, so you might want to set that one up to run with your default site ... or set it up to notify you if someone tries it.

Some things which can be improved:

- I have yet to try to use the FOAF module ( http://drupal.org/project/foaf ) to automate logins from one domain to the other. At the present time, users must login separately to each site, even though they use the same account info.

- I don't use the statistics module, so I can't say what it does, but it can be difficult to get individual domain info out of the Apache logs. Unless you do some fancy configuration, you get one combined log.

- Note that to use different databases (completely different Drupal sites) with the same code files, you can still follow the above instructions, creating a separate database and user for each one. Then, point each settings.php file to the appropriate database instead of pointing them all to the same one.

Keywords: multisite multi-site multi site, multihost multi-host, host, sharing code, one codebase, site configuration, step by step

Multi-Site, Single Codebase, Shared Database, Shared Sign-on 5.x

This document is written with assumptions that you have:

• installed Drupal 5 before
• access to your server via ssh / telnet
• access to MySQL database / you can setup your own MySQL database

In this example, I will setup two sites using:

• Drupal 5
• One database on MySQL
• Linux-based server

Also:

• Website's url is: www.example.com
• Drupal is installed in: /var/www/drupal
• Names of sites are: ‘site_1' and ‘site_2'

These sites will share session and user-related tables so once users login to one of the sites, they can view the other site without logging in. User roles and profiles are also shared among the two sites.

1. Prepare database and database user

1.1. create a database and user

In this example, I will use:

• DB name: drupal_db
• DB username: druser
• Password: twosites
• Access right: SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, INDEX, ALTER, CREATE TEMPORARY TABLES, LOCK TABLES

2. create and modify site configuration

2.1. duplicate settings folder

Duplicate a folder contains site config information under drupal/sites/

2.2. Modify config files

2.2.1. provide DB connection detail

Open settings.php in a folder under www.example.com/site_1. Go to line 93 (or somewhere around there) and you should find a line that goes:

change this line with your DB name, DB user and password. It will look like:

2.2.2. set prefixes for table names

just below the line we just changed above, there is a line that goes like:

Since we want to share a database among two sites but not completely, we decide which tables to share / not to share. This can be done by adding prefixes to table names. An example given below is for sharing user-related tables, sequences (this table is a ‘counter' of users, nodes and other stuff) and session information.

the second line that goes:

this means tables that are not shared with other sites will have a prefix ‘site_1_'. So for example, table name ‘node' will be ‘site_1_node'.

Now, when you finish editing this file, open and edit drupal/sites/www.example.com.site_2/settings.php. This time, you enter the exact same information for the database connection. So the line around 93 should look like:

Then, you add an array of prefixes, which will look like:

notice a prefix in the second line is now ‘site_2_'. At the installation, all tables will have this prefix except for the ones that are specifically given a prefix ‘shared_'.

3. create static links

In order to access site_1 and site_2 from web browser, you have to make static links to drupal directory. In the directory /var/www/drupal, enter the following commands:

now access ‘www.example.com/site_1' (and ‘site_2'). If you see a drupalicon and a message like ‘Unable to select database', go back to 2.2.1 of this manual and check if you have all details correct, including a single-quotation and semicolon.

If you see hundreds of messages like ‘Warning: Table 'continuu_test.access' doesn't exist', you are almost there. While this may look scary or makes you think you have done something wrong, it is just saying that it cannot find tables Drupal needs to have access to. This is simply because we have not yet finished installing Drupal. All the necessary tables will be created in the next step, which is described below.

4. install drupal

Since we have entered information for database connection, we can run the install script (install.php) straight away, instead of giving all the detail to installation wizard. From your web browser, just access:
http://www.example.com/site_1/install.php
http://www.example.com/site_2/install.php

Installation should complete within a second (or two). If you fail to install:

• read the error message and find out what is wrong (wrong DB name, username or password, etc.)
• make sure $db_url (around line 93 in settings.php) ends with a quotation mark and semicolon. ( ‘; )

If you have two separate Drupal sites and are thinking about merging them with above method, I would recommend you not to do it. Yes, it is not impossible. You can rename tables and modify values in sequence table and so on, but i tried it and had a hell of a hard time... If you have sites already setup, using CAS or other authentication services is more appropriate than merging.

Multiple domains or vhosts using different databases

Apache supports both IP- and name-based virtual hosts (vhosts). While running more than one engine (by using vhosts) can be very useful for development and testing purpose, it might even be more interesting for hosting companies. Therefore, we tried to support vhosts in the best possible way in order to make the life of any administrator easier. We do so by making it possible to run an unlimited amount of vhosts on the same physical source tree, though by using different configuration files. Moreover, you can setup multiple configuration files in your includes-directory.

The only thing left to be done is to setup the corresponding vhosts in your Apache configuration file. Note that the DocumentRoot points to the same source tree twice:

Remember that as of Drupal 4.6, you can have site specific modules and themes as well. Just create a directory under the sites/www.example1.com called 'modules' and place the site specific modules. The same applies to themes as well.

Consult the INSTALL.txt that came with your Drupal installation for more details.

Multiple domains using the same database

If you want to host multiple domains (or subdomains) on top of the same database (e.g. http://example.com/ and http://www.example.com/), simply use symbolic links to setup the required configuration files:

If your installation isn't in the root folder then you need to specify the path to the Drupal installation. For example if the URL to your installation is http://www.example.com/drupal/ you would use sites/www.example.com.drupal with a settings.php file in it.

If you want cookies to be shared between two sites, you will need to set the value of PHP's session.cookie_domain correctly. In the case above, set it to ".example.com". You can do this through Drupal's .htaccess file.

Same codebase, completely different content and users

This document assumes the following:

• You want to create more than one Drupal site using the same codebase (the same basic set of Drupal files, uploaded into one location).

• You know how to install mysql tables in your database.
• You know how to set up subdomains/folders/other domains that you want to use.
• You have already downloaded Drupal 4.7, and set up one MAIN site.

• This document contains instructions on how to create completely separate Drupal
  site, with different configurations, users and content. Nothing is shared between
  the installations except the codebase.

  Some definitions:

  codebase: the basic set of Drupal files, included in the .tar.gz
  file. the stuff that makes Drupal work.

  database: a collection of tables that stores data.

  Affected files:

  settings.php (sites/default/...)

  database.mysql

  For this example, we will assume the following:

  www.example.com: the MAIN site, where the codebase has already been uploaded,
  and settings.php has been properly configured.

  sub1.example.com; www.example.com/sub2; www.subexample.com : the other sites
  we will create.

  1. Create the following folders in your sites directory:

  sites/sub1.example.com/

  sites/www.example.com.sub2/

  sites/www.sub3example.com/

  Copy the settings.php file from sites/default into each of the above folders.

  2. There are different database files (inside the database folder). Select
  the one that is appropriate for your database version. Copy it to each of the
  folders you made in step 1. This is OPTIONAL, but it will help you keep things
  straight.

  3. Decide on SEPARATE PREFIXES for each site. Below is what we will use for
  the example:

  site
  database prefix

  sub1.example.com
  sub1_

  www.example.com,sub2
  sub2_

  www.sub3example.com
  sub3_

  4. Configure your settings.php for each site.

  This code MUST BE CHANGED FOR EACH SITE:

  $db_url = 'mysql://username:password@localhost/databasename';

  Note; if you are using the same database as the MAIN site, the $db_url is the
  same.

  OPTIONAL:

  # $base_url = 'http://www.example.com'; // NO trailing slash!

    # $conf = array(
  # 'site_name' => 'My Drupal site',
  # 'theme_default' => 'pushbutton',
  # 'anonymous' => 'Visitor'
  # );
 

  For sub1.example.com, the settings would be:
  

  $db_prefix = 'sub1_';

$base_url = 'http://sub1.example.com';

$conf = array(
  'site_name' => 'My SUB1 Drupal Site',
  'theme_default' => 'pushbutton',
  'anonymous' => 'Visitor'
   );

  For www.example.com/sub2, the settings would be:
  

  $db_prefix = 'sub2_';

$base_url = 'http://www.example.com/sub2';

$conf = array(
  'site_name' => 'My SUB2 Drupal Site',
  'theme_default' => 'fancy',
  'anonymous' => 'Anonymous'
   );

  For www.sub3example.com, the settings would be:
  

  $db_prefix = 'sub3_';

$base_url = 'http://www.sub3example.com';

$conf = array(
  'site_name' => 'My SUB3 Drupal Site',
  'theme_default' => 'marvin',
  'anonymous' => 'Guests'
   );

  6. Upload the modified settings.php files in their respective folders.

  7. Open the database file you copied into each sites folder. Find the following (don't forget the SPACE at the end!!!):
  
CREATE TABLE
INSERT INTO


  Replace each 'create table' and 'insert into' with 'create table dbprefix_' and 'insert into dbprefix_'

  For sub1.example.com:
  
CREATE TABLE >> CREATE TABLE sub1_
INSERT INTO >> INSERT INTO sub1_


  8. Upload the modified mysql files into the database you specified in your settings.php.

  9. Voila!

Setup of /sites directory for multi-site

Drupal's multi-site hosting capability is built in with any installation. This is great news for users who run numerous web sites from a single hosting account. A single Drupal installation can be used to run multiple domains, which makes it much easier to manage and maintain the code base. Even if you are dealing with only one domain, the multi-site capability may be valuable by providing the ability to run a separate domain or sub-domain for a development version.

This page describes the set-up of the /sites directory for multi-sites. The single-site basics are discussed at Basic /sites directory setup.

With version 5.x, the intended location for all non-core elements of a Drupal installation is in a separate /sites directory inside the Drupal installation.

Directory	Contents
/drupal/sites/all (used by all sites)	/modules /themes
/drupal/sites/default (used when there is no /sites/example.com directory)	/files settings.php
/drupal/sites/example1.com	/files /module /themes /tmp settings.php
/drupal/sites/example2.com	/files /module /themes /tmp settings.php

The intended best practice configuration is to create a /sites/example.com directory for each domain. It should contain a site-specific settings.php file and /files directory. Configure Drupal site settings to specify 'File System Directory' of 'sites/example.com/files' instead of the default 'files'. It's possible to do this with an existing web site, but moving file uploads around can cause a lot of confusion if there are already URLs pointing to the old locations.

Domain specific modules and themes should also be placed in /sites/example.com/modules and /sites/example.com/themes respectively.

Contributed modules and additional themes which are for use by all domains in a multi-site installation should be placed in /sites/all/modules and /sites/all/themes. Note that there shouldn't be a /sites/all/files or /sites/all/settings.php.

The /sites/default directory should contain /files and settings.php, for use if the /sites/example.com directory doesn't exist for a domain.

In addition to multiple sites, such as www.example1.com and www.example2.com, sub domains are also easily set up. Adding sub3.example2.com and sub3.example2.com/site4, the directory structure for these four sites would be:

Once you've done this, the file structure of your site will be cleanly organized:

• The main Drupal directory will contain only the standard 'core' files.
• All of your custom themes, add-ons, settings, and so on will be in /sites/example.com, /sites/all, or /sites/default.
• /sites/default/settings.php and /files will be used if there is no /sites/example.com directory.
• /sites/all/modules and /themes will be available to all sites.
• Backing up the /sites directory and your Drupal database will give you everything you need to restore the site in the event of a crash, or to move to a new server.
• Adding a domain is easy: just copy the /sites/default directory to /sites/example5.com

Symbolic links can be used for several purposes:

• Even if using default settings, a good option is to use links from /sites/example.com directory to point to the /sites/default directory. That way, if the settings and /files are ever changed from the default and actually placed in /sites/example.com, their location does not 'move' and no links are broken.
• Links could also be used to point the /sites/default directory to your primary site.
• A /files directory could easily be shared across two domains without being shared across the remaining domains.
• A non-domain-name path for /files can be setup. If it is possible that the domain name might change (say, from a development name), then you can set up a link from /drupal/sites/moniker to /drupal/sites/example.com, where 'moniker' is a short version of the site name that will remain constant even if /example.com changes.

Although the /sites/default directory could contain a /modules and /themes directory, these elements should usually be placed in /sites/all or /sites/example.com. Similarly, although contributed modules could be placed in /drupal/modules as was the practice in version 4.7, this is not recommended.

Multi-site directory setup for sub-domains, including non-standard ports, is described in the installation instructions (INSTALL.txt).

See multidomain for a contributed module that allows spanning one site across multiple domains, so that specific content types appear on specific domains or sub-domains.

Version 4.6 and 4.7: Best practice for multi-site set-up under version 4.6 and 4.7 is similar to 5.x. The primary difference is that there is no /sites/all directory. Instead, /modules and /themes that are available for all domains are kept in /drupal/modules and /drupal/themes.

General settings

The General settings area is where you configure some basic information for your site.

Name: this is where you set the name displayed for your site.

E-mail address: A valid e-mail address for this website, used by the auto-mailer during registration, new password requests, notifications, etc. You can set this to a real email address that people can reply to or to something generic no-reply@example.com that is outbound only. The email server that your site uses is set in the php.ini file and not by Drupal.

Slogan: The slogan of this website. Some themes display a slogan when available. It will also by displayed in the title bar of your sites visitor web browser.

Mission: Your site's mission statement or focus. Your mission statement is enabled in your theme settings and requires that the theme support it's display.

Footer: This text will be displayed at the bottom of each page. Useful for adding a copyright notice to your pages.

HTML formating can be used in the mission and the footer areas.

Anonymous user: Users who interact with your site without being logged in are labeled as "Anonymous" by default. Drupal gives you the option to change this to something different (e.g. "Anonymous coward"). The name you give anonymous users is used by Drupal when creating bylines for posts which typically reads something like, "Posted by Anonymous on January 1, 2006".

Default front page

This setting gives you control over what Drupal-generated content a user sees when they visit your Drupal installation's root directory. For example, you might have created a node with a large collection of links to act as a table of contents to the different sections of your site and you want this directory to be what users see first.

This setting tells Drupal which URL users should be redirected to. It's important to note that the URL is relative to the directory your Drupal installation is in. So, instead of

"http://www.example.com/node/83"

or

"http://www.example.com/drupal_installation_directory/node/83,"

you need only type "node/83". For those not using clean URLs, note that there is no need to type in "?q=" before typing the URL.

By default, the "Default front page" is set to "node," which simply displays articles that have been "Promoted to front page." Note that when you change the "Default front page" to something other than "node", nodes that are "Promoted to front page" will no longer appear on the front page. They can however, still be viewed by visiting the relative URL path "node".

If you enter a value in here that is not a valid Drupal path, the user will be confronted with a "Page not found" error. You cannot redirect users to any web documents (e.g. a static HTML page) not created by your Drupal site.

Clean URLs

By default, Drupal passes path arguments to itself via its internally generated URLs. This results in URLs that look like the following: "http://www.example.com/?q=node/83." This can make URLs hard to read and it also stops many search engines, like Google, from indexing the pages with these URLs.

You can tell Drupal to use "clean URLs", eliminating the "?q=" in internal URLs. Note that this works only for Apache servers which have the LoadModule rewrite_module configured and mod_rewrite enabled in httpd.conf configuration file.

There are two ways to enable URL rewrites in Apache. If there is complete control of the Apache webserver clean URLs should be enabled in the httpd.conf as this has better performance and security.

Warning. Enabling "Clean URLs" if your server is not properly configured can make it difficult to navigate back to administration pages to undo your mistake. If you find yourself in this situation, you can return to the administrative settings page by typing in the URL in the 'non-clean' form: http://www.example.com/?q=admin/settings.

Enabling clean URLs involves three steps:

1. Enable mod_rewrite for Apache. Please talk to your web host or consult the Apache documentation for mod_rewrite to get more information on how to do this. At a minimum, this will involve making sure that mod_rewrite is enabled for your installation of Apache. It will have to be either compiled-in or made available as a loadable module. Generally speaking, you can tell Apache to load the module by including
   LoadModule rewrite_module modules/mod_rewrite.so
AddModule mod_rewrite.c

   in your Apache configuration file. Be sure to uncomment AddModule mod_rewrite.c. Note that this may not be the case for all distributions of *nix operating systems. Consult your distribution's documentation that came packaged with your Apache software. We also recommend disabling multiviews in Apache as they conflict with clean URLs.

2. Edit your Apache configuration files for your site: the configuration information may be found in httpd.conf, a virtual-host-specific file, or in an .htaccess file in your Drupal installation directory. You can find this file usually in /etc/httpd/conf/httpd.conf. You may use
   
   find /etc -name httpd
   
   to find the file if it is located else where in your Unix system. The main configuration option which may need to be changed for your site is the RewriteBase. For example, if your Apache DocumentRoot is /var/www/ (i.e., /var/www/index.html is what is displayed when you point your browser at http://www.example.com/) and your Drupal installation is installed in the subdirectory /var/www/mysite/, then the RewriteBase should be set to /mysite. In some configurations setting
   
   RewriteBase /
   
   will allow mod rewrite to work.

   If you don't use the .htaccess that comes with Drupal you'll need to add some rewrite rules into your apache directory directive. Consult the .htaccess file in Drupal for examples of rules.
   

   <Directory /var/www/example.com>
   RewriteEngine on
   RewriteBase /
   RewriteCond %{REQUEST_FILENAME} !-f
   RewriteCond %{REQUEST_FILENAME} !-d
   RewriteRule ^(.*)$ index.php?q=$1 [L,QSA]
</Directory>

   You will also need to set the Allow Override settings in httpd.conf so that local .htaccess commands will be run for you site. If you are changing the .htaccess file in the Drupal distribution you want to set it to
   

   AllowOverride All
   
   to ensure rewrites are enabled. Read "Behind the scenes with Apache's .htacces for a thorough review of .htaccess.Here are samples of Apache 2 directives.
3. You should ensure your Drupal site has the path module enabled and the correct permissions set in order to create custom URLs. You can enable the path module in administer >> modules. You can then set permissions to administer URL aliases and create URL aliases. Enable clean URLs on your administration >> settings page. First, see if you can go to the settings page on your site using clean URLs: type in the URL http://www.example.com/admin/settings (where www.example.com is replaced by your hostname). If you get no errors and get to the same page you would have gotten to by clicking on "administer" then "settings" , then you know that you have setup the ReWriteRule rules successfully and can then click the Yes checkbox for "Clean URLs:" . If you have problem you can read the instructions to unset clean URLs. If you If you still have problems with clean URLs you can set the Drupal Settings.php $conf['clean_url']=1;.

Note: The standard Drupal installation contains a sample .htaccess file which supports clean URLs. It is easy to miss copying this file, because of the leading "dot".

Note Regarding MultiViews: The Apache webserver supports a feature called "MultiViews" (more generally: "Content Negotiation"), which allows navigation to your pages without the need for file extensions. For instance, if you had a file called "evaluation.txt", a MultiViews-enabled site could access this file with the URL "example.com/evaluation". While MultiViews can be a handy feature when used knowingly, they can cause problems when Drupal's Clean URLs are enabled. Unless you know what you're doing, you should consider disabling MultiViews if you plan to use the clean URLs feature of Drupal. Be aware that there's a good chance that MultiViews is already disabled, however; it's not enabled in a default Apache installation. Consult the Apache documentation for further information about MultiViews.

set your sites 403 and 404 Error pages

Drupal's page error messages are meant to be direct and to the point. If you want page error messages that are a little more user-friendly, Drupal allows you to customize them. Just follow these steps:

1. Create two nodes, one for each kind of page error (403 and 404).
2. Determine the id number of the node you wish to have Drupal redirect users to. One way to determine the node's id number is to visit the node and look at the number after the last slash in your browser's address bar. This is your node's id number.
3. Now enter the paths to your nodes into the appropriate boxes. For example, if the node id number for 403 error codes is "83," you would type "node/83" into the "Default 403 (access denied) page" setting.

Because you are creating nodes for this, they will show up in the tracker and popular content blocks and anywhere else real nodes would show up. If this isn't acceptable, there is a contributed module called Custom Error that avoids this problem.

Configure your sites error reporting

Where Drupal, PHP and SQL errors are logged. On a production server it is recommended that errors are only written to the error log. On a test server it can be helpful to write logs to the screen. By default, errors are displayed to the screen. You should change this to 'Write errors only to log' only for your production site.

You can tell Drupal to automatically discard error log entries older than the age you specify. This requires a crontab (yoursite.com/cron.php) to be set up. See step 6 of the install.txt for example of setup.

Cache support

Busy Drupal sites may want to consider caching their pages to lighten the load on their server and speed up page generation times.

Normally, every time you visit a Drupal page, Drupal makes dozens of queries to the database to pull out the data needed to generate the HTML that your web-browser renders. On a large site with many modules installed or with lots of content on a page, the number of queries per page could rise into the hundreds. Usually, you don't notice all the work Drupal does because computers are very fast and Drupal is very efficient. However, on very busy sites with many hundreds or thousands of page views per minute, the amount of work required to serve each page may start to slowing the server to a crawl.

Busy sites can reduce the work required to generate pages by enabling Drupal's page cache.

With the cache turned on, Drupal stores all the HTML code for any page visited by an anonymous user directly into the database. When another request for the same page comes along, Drupal knows to fetch this page out of the database rather than re-generating it from scratch. The result is that hundreds of queries are replaced with one single query, thereby significantly lightening the load on the web server.

Primary and secondary links

General Information:

In versions 4.6 and below, primary and secondary links were handled in the theme administration.

As of 4.7, primary and secondary links have been incorporated into the menu system. To have primary and secondary links in your theme, you make them menu items. A fresh Drupal 4.7 install comes with an empty menu called "Primary Links" that is set to be used to display both the primary and secondary links.

Setting Up Your Primary and Secondary Links:

There are two configuration screens that deal with these links:

On admin >> settings >> menu you choose which menu is used for the primary links and which for the secondary links. If you have added items to the default "Primary Links" menu and they are not showing up, check to make sure the option on this page hasn't been changed to "No Primary Links".

On admin >> menu you will find the default "Primary Links" menu and you should add your links to that. You can also create a menu to hold the secondary links or create a different menu for the primary links. Be sure to change the options on admin >> settings >> menu to use the correct menu(s).

Theming Your Link Menus

You can display your links in two ways:

1) You can add the menu block to a region just like any other menu.
2) You can insert this code where you want the links to show up:

You can then use CSS to theme your DIVs however you like.

Set length of trimmed posts and # of posts on front page

admin >> settings >> post

Here you can set the number of posts on main page and the length of trimmed posts. You also set whether previewing posts is optional or required.

URL Alias Optimization

Drupal 6.0 implements a new feature to enhance site-performance: a whitelist/blacklist for URL alias lookups. Database queries to find url aliases created by the path module are among the most frequent in many Drupal installations. The performance setting allows administrators to either define paths which will no be looked up (blacklist), or paths which will (whitelist).

Similar to the block visibility settings, you can use the * wildcard to define ranges of URLs.

The blacklist comes with a set of useful default urls. For many sites, enabling the blacklist will reduce the number of overall queries to the database without degrading any functionality. However, if you make extensive use of URL aliases, you should think about what settings work best for you. If you have a small number of aliases, setting them up as a whitelist may be even better.

File system settings

Drupal provides configuration settings to control whether, and how, users and administrators can upload files for use by Drupal.

Note: Unconfigured or improperly configured Drupal installations may display one or more error message at the top of the "settings" page, indicating that either the "Temporary directory" or "File system path" directories do not exist and/or their permissions are not set properly. Simply create these directories and set their permissions so that Drupal can write and read from the directory.

If you are unsure about where or how to create these directories or how to change their permissions, contact your web hosting service or software documentation for further assistance.

Date and time settings

Drupal allows you to configure how dates and times are formatted and displayed. When making the format settings, you should probably consider the culture of your target audience. Below are suggested configurations for the "Default time zone" and "Configurable time zones" options.

For sites where most users live in a small geographic region:
Set the "Default time zone" to the time zone of the region and disable configurable time zones.

For sites where most users live a region that spans a few time zones:
Set the "Default time zone" to the time zone usually considered to be the "standard" time zone and disable configurable time zones. For example, in the United States, you'd set your site's time to the timezone that corresponds to Eastern Standard Time.

For sites where users are likely to be scattered across the globe:
Set the "Default time zone" to the time zone to GMT (+0000) and enable configurable time zones.

Controlling what gets indexed -- the robots.txt file

The robots.txt file is the mechanism almost all search engines use to allow website administrators to tell the bots what they would like indexed.

A robots.txt is included with Drupal 5.x. Drupal 4.x does not come with a robots.txt file.

By adding this file to the root of your (virtual) webserver, you can quide the search engines' "bots" through your site or forbid indexing parts of your site. See for an example the file for drupal.org itself at http://drupal.org/robots.txt.

If you want to have a robots.txt file, please follow the instructions below. For more details check http://www.robotstxt.org

Create a file with the content as shown below and call it "robots.txt"

This file tells indexing robots that they should avoid pages that contain content for users only, for example the search page, or the 'Add a comment' forms for nodes.

Many robots obey the "Crawl-delay:" parameter. Since Drupal sites seem to be popular with search engines and lots of people have more aggresive bots than visitors at their site, it might be wise to slow down the robots by adding a robots.txt line like this:

Here 10 is the delay in seconds between page requests.

Both "Slurp" (The robot that is indexing for yahoo and altaVista) and the Microsoft robots for the MSN sites obey this parameter. Googlebot does not use the "crawl-delay" parameter yet but will likely do so in an upcoming version.

Change the file as you wish and save it. Now upload it to your webserver and make sure it is in the root of the (virtual) webserver. If you have installed Drupal in a subdirectory (for example /drupal), then change the URL's in the robots.txt file but place the file in the root of the webserver, not in the root of your drupal instalation.

Now watch the robots visit your site and after some time, monitor your log files ("referrer log") to see how many visitors came from a search engine.

Block configuration

Whether a block appears on a page depends on a number of factors.

• First, the block must be enabled by checking its "enabled" box on the block management page;
• Second, the block's custom visibility settings must permit the block to be displayed for a given user. You can configure a block to appear always; to be displayed by default unless disabled by individual user preferences, or to be disabled by default but visible if enabled by individual users. Individual users can select or disable optional blocks from their "my account" page;
• Next, whether the block appears on pages for a given section of the site can be configured by the administrator by setting the block's path;
• The block can be configured to appear only for certain content types;
• Finally, if the throttle module has been enabled, and the block has its throttle box checked on the block management page, then it will only appear if the site's traffic is below a given threshold.

Once you have configured a block to appear as required on specific pages and in the correct column, you may wish to adjust the block's weight to position the block vertically within its column. A block's weight is set via a pull-down selector on the block management page. Heavier blocks (those with a more positive weight) "sink" to the bottom of a column, while lighter blocks "float" towards the top.

More infomration can be found in the modules section of the handbook on block

Custom blocks

A custom block contains content supplied by you (as opposed to being generated by a module). Custom content may be either static (i.e., HTML) or dynamic (PHP generated content). Virtually all of the functionality of Drupal is accessible from within a PHP content block. The flexibility of blocks provides an extremely powerful way to customize your Drupal website.

You can create a custom block via the block management screen (click on administer » blocks). Select the new tab and complete the form.

Each custom block has a title, a description, and a body. The content within the body can be as long as you wish.

Note: In Drupal 4.6, the title of the block is used as its identifier in the database table. Therefore you can only have one custom block without a title (this issue has been fixed in newer Drupal versions).

One workaround for this is to enter a title such as this: <!--title of custom block-->. This satisfies Drupal's need for a block title but the comment markers (<!-- ... -->) prevent it from being displayed.

Share tables across instances

Table prefixing may be optionally applied to some tables and not others. This has the effect that multiple Drupal installations can share common tables. One interesting application for this is to share the taxonomy tables (vocabularies, term_data). Another interesting use is to share users across Drupal installations.

In order to use this capability, create two drupal installs in same DB using different database prefixes. In this example, one is prefixed 'master_' and the other 'slave1_'. Then edit the conf.php file of 'slave1_' so that it points some tables to the 'master_'. For sharing users, add the following:

Note: The actual tables that you will share depends on your installation.
However, the following tables contain data that is highly site specific and therefore should not be shared:

• cache
• variable

There is a limitation in that you can only explicitly specify which tables will be shared and not the other way round. The following may fail (however a recently deleted comment on this page by marcob suggests this has been fixed:

Setup tip for Drupal 5

For Drupal 5+, an easy way to get started with table sharing across instances is to run the installer twice using the same database - it will create the prefixed tables and handle all the initial INSERTS (as with the 'system' and 'menu' tables, etc) for all your different prefixes.

Using schema prefixes with PostgreSQL

This page discusses usage of PostgreSQL schemas for prefixes. "Normal" prefixes can be used in the same way as in MySQL, so they won't be discussed here.

PostgreSQL has something called 'schemas' (http://www.postgresql.org/docs/current/static/ddl-schemas.html). They can be very handy sometimes, but if you don't know what they are, you probably don't actually need them and can stop reading here.

Schemas can be used as prefixes within Drupal. That is, with a multisite setup, each site can reside in its own schema, and shared tables can reside in a "shared" schema (or even in the public schema).

There is one annoyance: the upgrade will fail. This is unfortunate, but nothing can be done as the "normal" (not schema) and schema prefixes are just incompatibile. If you are interested in the details, please see http://drupal.org/node/40034.

But, don't worry. This can be easily fixed by changing the update script (update.php and updates.inc) a bit. The problem lies in the CREATE [UNIQUE] INDEX and ALTER TABLE ... DROP/ADD CONSTRAINT statesments. When schema prefixes are used, queries like this are executed:

The prefix must be removed from the index and constraint name--that is they must be changed to:

You can easily search for CREATE INDEX, CREATE UNIQUE INDEX and ADD/DROP CONSTRAINT statements and remove the {} from index/constraint names.

The best way is to run a test upgrade. You'll see a list of failed queries and it will be easier for you to change them.

Another remark: you can't use prefix.sh to prefix the tables, it will produce incorrect CREATE [UNIQUE] INDEX queries. This, also, can be easily fixed, by changing:

to:

An alternate approach
Here's what you need to do if you want to solve it this way:

1. Add the following at the top of your database.pgsql file:

2. Edit drupal/includes/database.pgsql.inc, replacing the function db_connect() with:

3. Finally, use a db_url akin to such in your settings.php file(s):

• Not thoroughly tested, but works for me (on 4.6.3).
• This also fixes the inability to specify a Unix socket as the host - the +tmp gets replaced with /tmp for pg_connect().

Define shared variables for all sites

When you create a multi-site installation, an important table to duplicate is the variable table. However, by duplicating this table, you will also duplicate some variables that you might prefer not to. To force a set value for these variables, for all of your websites, you can do the following.

First, you will probably have a settings.php file for each site in your installation, like sites/example.com/settings.php. Edit each file and add the following to the end.

Now, in the default directory, add a file called sites/default/shared_variables.php containing the following.

The element names (eg. 'site_name') correspond to a variable in the variable table. So no matter how many copies of the variable table that you need, each site in your multi-site installation will defer to the variables that you define in the $conf array in your shared_variables.php file.

The disadvantage is that these variables cannot be edited via the Drupal admin pages.

Modules

Modules

You enable a module at Administer>>Site building>>Modules. The non-core modules are listed farther down. With 5.x, they now show you some of the inter-module dependencies. I turn them on and "Save configuration" in order of the dependencies. For example, "Views UI" requires "Views", so I turn on "Views" first, save the configuration, then turn on "Views UI." and save again.

Ah, now the real work begins. Go to Administer>>User management>>Access control to select who can use the features of the new module.

If the module introduced new content types, go to Administer>>Content management>>Content types and configure them. Don't forget this may also affect your "Input formats" (Administer>>Site configuration>>Input formats) and "Categories" (or taxonomy, Administer>>Content management>>Categories); you'll have to check those too.

Okay, now you can start using the new module.

This Site

My documentation site is a relatively "vanilla" implementation of Drupal.

Core Modules Enabled	Contributed Modules in Use
Blog Book Comment Contact Help Menu Path	Codefilter - Provides tags for automatically escaping and formatting large pieces of code. Meta Tags (Nodewords) - Allows users to add meta tags, eg keywords or description. Site Documentation - Documents and cleans up your configuration.

To get some idea of what modules are available, check these links: module handbook and contributed modules handbook.

Themes

Themes

You enable a theme at Administer>>Site building>>Themes

If it has never been enabled on this site, you will have to check the "enable" box and then click the "Save configuration" button at the bottom.

To set up how the theme works, click on the "Configure" link (not the tab at the top).

Fill in the fields.

Save the configuration.

Don't leave the page yet.

Logo and Favorite Icon

Now use that "Configure" tab

I prefer to do this part under the "Global Settings" but it can be done theme-by-theme if you prefer.

The "Default Logo" is that little picture (usually) in the upper left corner of the page. For example, on the "Bluemarine" theme, it's the Drupal logo.

If you want to change it, here's how:

1. First, find out what size it is because you'll want your own logo to be about the same. (If you are comfortable with HTML and CSS you can also edit the theme's code to accommodate your logo rather than resizing the image. How to edit theme code is not covered in this beginner's guide.)

2. Theme Name	Width	Height
   Bluemarine	48	55
   Chameleon	49	57
   Garland	64	73
   Minelli	64	73
   Pushbutton	144	63
   Fancy	80	80

3. Under "Logo image settings" either type in the path to your logo, or upload it from your PC.
4. Note: Neither one of those options turns off the "Use default logo" radio button. You must select the correct radio button yourself.
5. The "Shortcut icon" (a.k.a. the favorite icon, or "favicon.ico") is the same way. If you want to change this, you must specifically say, "Hey, Drupal, I'm changing this."

Now you click the "Save configuration" button. If you did this in "Global settings" it affects all themes (assuming they behave properly); if you did it for a single theme, then only that theme is changed.

For a list of all available themes, check Themes.

---

HINT: Going to make a few (or a lot) of changes to a standard theme? Think about copying it over to your /sites/sitename/themes/ folder and renaming it. Then you can do anything you want and still be able to undo it easily by recopying. If the changes ae a bit bigger, think about contributing it back to the community (with your name, of course).

 

G1. Creating a Page

A page is probably the simplest content, other than maybe a blog.

Click on "Create content" in the menu, then select what kind.

The title and body are pretty self-explanatory. Below these are a number of collapsible fields. "Input format" controls what you can put into the page; I'm assuming you are the "super-user" (user/1), so give yourself the priviledge of "Full HTML."

If you have Nodewords installed, the next section is "Meta Tags." It's pretty well documented.

I have no idea why you'd use the "Log message" but I'm sure someone has a reason.

Hopefully, you already set your default "Comment settings" but the front page rarely deserves comments, so you can disable them.

If you turned on the "Path" core module, you'll have URL path settings next. You can enter a "normal" name here rather than being required to use "node/2" when you refer to it later on. Hint: if you are converting a site that was static pages, you might want to go ahead and add ".htm" or ".html" to the name so that the search engines will continue to find the page.

"Menu settings" is the next section. "Title" is what will show in the menu normally. "Description" will show when the user hovers the cursor over the menu item. "Parent item" allows you to create multi-level menus that collapse and expand. "Weight" allows you to set a relative position within the menu; unfortunately, some Drupal core items are hard-coded at 0.

Chances are you won't need "Authoring information" unless you want to attribute the page to someone else. The other use for this section is to control the page or story order when they are based on the time and date it was created.

Finally, "Publishing options," which you set defaults for earlier, right? You want the page "Published" so it will show up. If this is your "Welcome" page, you'll want it "Promoted to front page."

"Submit" it.

Congratulations, you now have some content on your site!

G2. Creating a Story

Most of what goes for a page is also true for a story. You can largely consider the two types to be interchangeable, and it is goodness to have at least two content types because conflicts can arise in the way content types are used (for example, taxonomy "collisions").

Stories have a "teaser" or opening statement intended to grab the reader's attention. The length of the teaser is set in one of two ways:

• In Administer>>Content management>>Post settings. The default there is 600 characters. You can change that.
• By specifically identifying a break point with ``< !--break-->'' in your content (before the default limit; leave out the space).

• Note: You may see some places that tell you to use ``<break>'' to set a teaser point. This was originally changed in 5.0 and created a considerable controversy, so it was backed out.

A story probably shouldn't have a menu entry. If you use the general "convention" that a "page" is for static or generated content that stands alone, and "story" is for collections of related content (e.g. RSS feeds, newsletter articles, press releases, etc.), then a story is usually going to be displayed with other stories, so which one would be the menu item? Generally the menu for a set of stories will be a description of how they are selected for display.

You may want to promote the story to the front page. For your ``Welcome'' message, you probably also want to make it ``Sticky at top of lists.'' Alternatively, you can give it a lighter ``weight'' so it "floats" up the list.

---

What's a Teaser?

This is from a post by zoon_unit on January 10, 2007.

A ``teaser'' is essentially a snippet of text designed to tell the user the content of a post without reading the entire post. Since most writers have embraced the common journalistic style of explaining the nature of an article in the first paragraph, teasers work well for most articles.

Here's what happens:

1. A node contains an entire article.
2. Drupal's ``teaser'' function, ``node_teaser,'' strips the first x number of characters from the article and makes it available as content. The exact length is determined by the value set in Drupal's Administer » Content management >> Post settings.
3. So, you list a bunch of articles on a page. You want the articles to display only a snippet of text from the full article, so that you can fit a bunch of articles on a page without requiring the user to page down through tons of text. If the user likes the ``teaser'' content of the article, they will click on the article's title and see the full content of the article on its own page. In a sense, teasers function like summaries of an article, except that the software decides where to cut off the text. If you want to determine where a teaser article ends, you can insert the comment tag to instruct Drupal exactly where to fashion the break between full text and teaser text.

---

NOTE: There is a bug in the core Node module. Check the issue status. It is a simple change (can be done manually) and must be applied in order for some modules to render teasers correctly. By the way, you might want to add your own experience to that bug report in order to increase its attention by the developers.

 

G3. Creating a Book Page

Generally, I only create one book page for each book. This is the first one, usually the introduction. All other pages will be added as "Child pages" (to be accurate, child pages will still have the "book page" content type set for them).

In addition to the things I said about pages, a book page has a "Parent." For the first page, this will be "<top-level>." If you use "Add child page" the "Parent." selection should be already filled in with the book's name. If you create another book page, you would need to make sure you properly select which book or page teh new one is to be made a child of.

The top page of the book probably deserves a menu entry. The rest do not, unless they are really special. Remember, a book has its own navigation.

You are currently reading a "book."

 

G4. Creating a Blog entry

Blog entries are a little different. Assuming you enabled the "Blog" module, you should see a "My blog" entry in your navigation menu. When you click on that, there will be a "Post new blog entry" link on that page.

If the blog is a diary, you probably want to use the date for the title.

If it's a collection of thought, give it a meaningful title.

Type in the content of the entry.

Your blog will always show the most recent entries on the beginning page when visitors view it.

Backup Process with phpMyAdmin

Backup Process with phpMyAdmin

The screen shots here are from phpMyAdmin 2.9.2, which I have on my local computer. My web hosts have 2.9.0.2 and look very similar. They certainly produce exchangeable results.

1. 
   
2. Log into phpMyAdmin on your server.
3. 
   
4. Select the name of your database - or your Drupal database if you have several databases.
5. 
   
   
   
6. The next screen will show you all the tables inside your Drupal database. Ignore those, and click the "Export" tab on the top set of tabs.
7. 
   
   
   
8. Look at the left box at the top of the Export section. All the tables in the database you selected are in that box.
9. 
   
   • 
     
   • If you have other programs that use the database, then choose only those tables that correspond to your Drupal installation.
   • 
     
   • If you only have Drupal installed, in the left column, click "Select All."
   • 
     
   
   
10. Ensure that the SQL button is selected too.
11. 
    
12. In the Structure section tick the following boxes: Structure, "Add DROP TABLE," "Add AUTO_INCREMENT," and "Enclose table and field names with backquotes."
13. 
    
14. In the DATA section leave the boxes inside this section unticked, but make sure to keep the check box next to the "DATA" heading checked.
15. 
    
16. Tick the "Save as file" option, and leave the template name alone.
17. 
    
18. For now, select "None" for compression.
19. 
    
20. Now click "Go" and you should be prompted for a file to download. Save the file to your computer.
    Depending on the database size, this may take a few moments.
21. 
    

You have now backed up your database! (Not so bad, was it?)

Once that download is complete, you may check the "zipped" option, click "Go", and download the next file. If you want, you can download a backup in each of the compression formats. Your choice.