It's possible that a Drupal site that was once configured to run with clean URLs later on stops doing so. After that, almost all content is inaccessible, because the paths being generated are not supported by the hosting platform.

This occasionally happens

Drupal 6 and later supports sharing a database with other web applications with the table prefix, also known as $db_prefix from settings.php.

The table prefix is defined in your Drupal site's settings.php file, and when it is present Drupal will place the prefix before each table name in the database. So if the table prefix were 'mysite_' then Drupal would look for tables named 'mysite_access', 'mysite_actions', and so on (instead of the default tables names 'access', 'actions', etc.) This allows more than one Drupal site, or even Drupal and other products, to share the same database, because the table names will not collide with one another. You can have another Drupal instance with table prefix 'mysite2_' sharing the database with 'mysite_' and indeed many other instances as long as each one has a unique table prefix.

If your hosting company only provides you with one database, then sharing it between multiple Drupal sites with table prefixes can be a cost effective alternative to paying for extra 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 is most useful for hosting companies. Therefore, we support vhosts in the best possible way in order to make the life of all administrators easier. We do so by making it possible to run an unlimited number of vhosts on the same physical source tree, through using different configuration files. Moreover, you can setup multiple configuration files in your includes-directory.

$ ls -l sites/*/*.php
-rw-rw-r--    1 drupal   drupal      sites/www.example1.com/settings.php
-rw-rw-r--    1 drupal   drupal      sites/www.example2.com/settings.php

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

NameVirtualHost 127.0.0.1

DocumentRoot /home/www/drupal
ServerName www.example1.com

DocumentRoot /home/www/drupal
ServerName www.example2.com

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 in it. The same applies to themes as well.

This information is superseded by newer tutorials:

• Create new content-type for Drupal 5.x
• Create new content-type for Drupal 6.x

The Blog API module, included in Drupal 5 & 6 and available via the separate BlogAPI contrib module for Drupal 7, enables a post to be published to a site via external GUI applications. Many users prefer to use external tools to improve legibility and posting responses in a customized way. The Blog API module provides users the freedom to use the blogging tools they want but still have the blogging server of choice.

When this module is enabled and configured, you can use a variety of programs to create and publish posts from your desktop. Blog API module supports several XML-RPC based blogging APIs such as the Blogger API (outdated) (new Blogger Data API, MetaWeblog API, and most of the Movable Type API.

For more information on using software with the Blog API, see the Creating new content section of the End user Guide.

Note that starting with Drupal 6.x, Watchdog has been replaced by the dblog and syslog modules. Dblog is similar to watchdog; Syslog allows Drupal's logging to be integrated with the server's syslog facility.