Multisite

Use this module when you are running multiple Drupal sites from a single code base (multisite) and you need a different robots.txt file for each one. This module generates the robots.txt file dynamically and gives you the chance to edit it, on a per-site basis, from the web UI.

Note: You must delete or rename the robots.txt file in the root of your Drupal installation for this module to display its own robots.txt file(s).

Drupal 8 status

Alpha10 has been released. It should be considered a major upgrade. See the detailed release notes regarding the upgrade.

See https://github.com/agentrickard/domain for the most current work.

Overview

The Domain Access project is a suite of modules that provide tools for running a group of affiliated sites from one Drupal installation and a single shared database. The module allows you to share users, content, and configurations across a group of sites such as:

• example.com
• one.example.com
• two.example.com
• my.example.com
• thisexample.com <-- can use any domain string
• example.com:3000 <-- treats non-standard ports as unique

By default, these sites share all tables in your Drupal installation.

Installation

Drupal 7

Module installation requires edits to your site's settings.php file. See the online installation guide for details.

Drupal 8

No changes are requires to install the module, but certain configurations need to be edited in services.yml. See the README for details.

Technical background

The module uses Drupal's Node Access system to determine what content is available on each site in the network. Unlike other multi-domain modules for Drupal, the Domain Access module determines user access based on the active domain that the user is viewing, rather than which group or site the user belongs to. For more information about Node Access in Drupal, see http://api.drupal.org/api/group/node_access/7

This module uses some advanced Drupal concepts and requires that you understand and control your site's DNS configuration. See this case-study or this more recent Row Eleven Wine Co. post for more details about using Domain Access.

You can also watch video of the DrupalCON Paris session "Managing Multiple Sites with Domain Access" (from 2009).

If you are looking for a module to provide subdomains to users and groups and do not need to affiliate content, take a look at Subdomain.

Parallel to the Services module, the Clients module provides the ability to implement pluggable clients to external web services, including external Drupal sites running the Services module, the main use case being connecting to other Drupal installs via the Services module with either the REST or XMLRPC server.

Virtual Sites offers almost the same (and more) functionality as the Drupal multi-site feature without the need for the complicated setup of that feature. Depending on conditions (e.g. requested url or user role) handled by the Condition(s) module (bundled with Virtual Sites starting with the 7.x version), you can override theme, site information, menus and more to virtually present the visitor with a different website.

Complex websites and web applications can be created by combining configurations of Modules, Content Types (CCK,) Views, Panels, Menus, Blocks, Categories, Roles / Permissions, etc. This site setup and configuration process is a very time consuming and repetitive bottleneck.

Patterns module is built to bypass this bottleneck by managing and automating site configuration. Site configuration is stored in XML or YAML (requires SPYC YAML parser, which needs to be downloaded separately from http://code.google.com/p/spyc/) called Patterns which are easy to read, modify, manage, & share and can be executed manually or as a part of an automated web site deployment.

A very small module to make requests to http://example.com/favicon.ico forward to the actual site's true favicon.

This module takes the favicon for the current site/theme and makes it available at the url example.com/favicon.ico (where example.com is your domain). The problem is that some web browsers and web applications blindly make a call to example.com/favicon.ico looking for your sites favicon. In drupal this causes an error entry to show up in the logs because there is nothing there.

If you want your icon to show at that address you can put a copy of your favicon n the root drupal directory. But, what if you have a multisite configuration with different favicons. This module will allow that address to show the current themes favicon at example.com/favicon.ico and it will work for multisite configurations.

Configuration

For this module to work properly you need to:

1. Drupal 6: enable the core 'Shortcut' module
2. Drupal 6/7: comment out #RewriteCond %{REQUEST_URI} !=/favicon.ico in the Drupal root .htaccess file

Credits

Currently maintained by Deeson Online

Bakery provides a "single sign on" feature for Drupal based sites that are on the same second-level domain (i.e. example.com, subsite.example.com, subsite2.example.com). It could also provide support for any other website that implements the same web cookie, xmlrpc, and POST methods.

Read the Bakery documentation for more information.

Note, Bakery 1.x is incompatible with Bakery 2.x. Run the same releases (including same daily development tarball) on all domains you wish to provide SSO for.

This module extends Domain Access for Drupal developers by using the CTools suite. To use this module, you must have both Domain Access and CTools installed.

The only feature currently implemented is an access control plugin for Page Manager. This plugin allows you to set domain-specific visibility rules for Pages and Panels.

Additional features should be filed as patches against HEAD.

Part of the Domain Access suite.

Provides Views integration for Domain Access.

Note that the module requires Domain Access 7.x.2.14 or higher.

I use the following symbolic links structure on our servers and wrote a bash script for handling Drupal updates years ago.

Within this structure and this drush command, it is now possible to do that via drush.

Here is the very specific structure this command deals with for multi-drupalupdate and multi-create:

drupal/
|-- 6.x -> drupal-6.14
|-- 6.x_backup
|-- 6.x_profiles
|-- 6.x_sites
|   |-- all   
|   |-- default
|   |-- example.com
|   |   |-- files
|   |   |-- modules
|   |   `-- themes
|   `-- sub.example.com 
|       |-- files
|       |-- modules
|       `-- themes 
`-- drupal-6.14
    |-- includes
    |-- misc
    |-- modules
    |-- profiles -> ../6.x_profiles
    |-- scripts
    `-- sites  -> ../6.x_sites

Commands

drush multi-drupalupdate

Updates the installation if there is a new minor release available and preserves all detected symlinks, like sites and profiles above

drush multi-create

Creates a Drupal multisite installation, supports usage of drush_make makefiles

drush multi-site

Creates a site within the installation

drush multi-status

An extended drush core status

drush multi-exec

Removed: Execute a drush command on all sites (batch mode)
@see #652778: Similar functionality is in drush core 3.x

drush multi-sql-dump

An extended sql dump

drush multi-nagios

Moved and will be removed soon: Command for use as nagios plugin to monitor Drupal sites and Drupal installations with exit status and status message.
You can find the isolatated nagios functionality at Drush Nagios (drush_nagios).