RobotsTxt
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).
Domain Access
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. The Domain Prefix module (for Drupal 6) allows for selective, dynamic table prefixing for advanced users.
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.
Favicon
A very small module to make requests to http://example.com/favicon.ico forward to the actual site's true favicon.
Domain Views
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.
Domain XML sitemap
Placeholder project for the contrib module to integrate the XML sitemap and Domain Access modules together.
This will only work with the XML sitemap 2.0 module.
Domain Path
The Domain Path module allows the creation of separate path aliases per domain for nodes created using the Domain Access module.
The module is ready for testing, but requires Domain Access 7.x-2.7 (or higher) to work correctly. For background, see this issue.
Drupal 6
The Drupal 6 version requires URL Alter and Domain Access 6.x.2.11 or higher.
Sponsor
Domain Path was developed by Palantir.net
Domain CTools
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.
7.x-1.3 and higher
Provides compatibility with both the 7.x.2 and 7.x.3 versions of Domain Access.
If you have previously exported access rules to code, you are encouraged to re-export your access rules. The user interface will prompt you when it is recommended to do so.
Developer Note
This project is deliberately not part of the Domain project download, to encourage faster adoption of new CTools features.
Apache Solr Multisite Search
Integrates with Apache Solr Search Integration to search across multiple sites.
Multisite search is made possible by having many sites share an index. Because each "document" is stored in the index with a site and a hash field, it is possible to filter by site or hash, and thus return results from just one site, or from all of the sites sharing an index.
This module adds a "Multisite search" tab to the search page. Normal Apache Solr search works as before.
The list of facets available to multisite search is different than those available to normal Apache Solr search, but includes created and updated dates, user name, taxonomy terms, and very importantly, site. Thus you can do a search on Site A and then filter your results to show just those on Site B.
Drupal 6 and Drupal 7 Multisite?
Drupal 6 and Drupal 7 can be mixed when using the 7.x-1.x branch and 6.x-3.x branch. Installing the module in each site is sufficient.
Compatibility
The 7.x-1.x branch of the Multisite Search module is compatible with the 7.x-1.x branch of the Apache Solr module
The 6.x-3.x branch of the Multisite Search module is compatible with the 6.x-3.x branch of the Apache Solr module.
The 6.x-1.x branch of the Multisite Search module is compatible with the 6.x-1.x branch of the Apache Solr module.
Domain Menu Access
Domain Menu Access is an extension to Domain module, allowing administrators to configure visitors' access to selected menu items based on current domain they are viewing.
It lets administrators decide whether a specific menu item should be hidden on selected domains (regardless of it being enabled by default using standard Drupal functionality), or should it be displayed on selected domains even if disabled by default.
Bakery Single Sign-On System
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.
Vagrant and Chef setup for testing Bakery
Development credits
The original design and code are by David Strauss. The module is currently maintained and developed by some members of the Drupal.org infrastructure team and some people who use it on their sites or their customer's sites.
Significant work for Bakery has been sponsored by Examiner.com who funded much of the Drupal 7 port and features related to sharing data between sites. Growing Venture Solutions also supported work to improve the feature-set of security.drupal.org. Acquia provides on-going support.
Domain Variable
This module aims to be a replacement variable handling module for Domain Access, allowing mixed variable realms (domain x language) to be configured.
In other words, it allows setting different variable values for each domain and for each language at the same time.
This module supports almost all of the functionality provided by Domain Configuration, Domain Settings and Domain Theme. Differences are listed in the documentation.
This module requires the 7.x-2.x branch of Variable module and also at least version 7.x-1.6 of i18n if you want to use mixed domain and language variables.
Original story here: #1307058: Use new Variable API for different variables per domain.
Virtual Sites
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.
It is by no means limited to that, but one common example of where to use Virtual Sites is the mobile version of a site, intended to be viewed on mobile devices like smartphones or tablets. Using nothing else but Virtual Sites, you can set up all possible combinations of required functionality, like checking for:
- a mobile browser (using the Browser condition);
- a secondary hostname, eg. m.example.com (using the Hostname condition).
If any of the conditions above is met, you can:
- switch the theme to a mobile-friendly one (using the VS Themes module);
- even if the visitor used the regular URL, redirect them to the secondary hostname m.example.com (using the VS Common Settings module).
What it can do
Domain Menu Block
Provides a Menu Block that can be registered across every active Domain on an installation.
Requires Domain Access 7.x-3.0 or higher.
The module will create a new menu for each registered domain and allow you to define a common menu block that can be used once in the theme layer. The contents of this block are then dynamically generated based on the current domain.
Note: this module will create new menu blocks. If you want to restrict access to existing (menu) blocks, please check out the Domain Blocks module, which provides domain-specific visibility for blocks.
Sponsors
Domain Menu block was developed by Palantir.net for the Public Interest Network.
Domain Rules
Adding Rules module actions related to Domain Access module.
Allowing automation of different actions needed to create/modify/delete domains.
Web Service Clients
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 ingesting content from other Drupal installs via the Services module with either the REST or XMLRPC server.
Clients module allows you to create connections to remote services with an admin UI. These handle fetching a result from a remote service. Different types of connection are provided for different types of services. There is a Drupal client connection type for different versions of Services (5.x-0.92, 6.x-2.x, 7.x-3.x), hence Clients can be used to connect to sites with different versions of Drupal.
Resources can be defined on top of connections, which provide an abstraction layer so that other parts of Drupal can work with remote data without needing to know anything about the connection. An example module for remote Views blocks is included.
Connections and resources can be exported to Features. The UI also provides a system for testing connections are correctly set up and functioning, which can be extended to provide site-specific tests.
Requirements
3.x branch:
- Entity API
- CTools
2.x branches:
- CTools
- Autoload (Drupal 6 only)
API
Domain Fields
This module adds additional domain based settings to control a number of field settings, including field display and editing access, required flag, label and help overrides.
Domain Access Taxonomy
Assign taxonomy terms to all or specific Domain Access sites. You can set access per vocabulary.
Feature Server (fserver)
This module allows you to share features and custom modules on your own website. It lets you create projects and releases, and it produces an update XML feed compatible with the update module in core. In a way it's a highly simplified version of the project module.
Basic Documentation
- Distributed Feature Servers in Drupal (describes basic concepts/idea behind feature servers).
- Pushing Public and Private Updates From Your Feature Server (presentation of module, including screencast)
D7 Release
Please dont use the D7 release, its pretty buggy yet and we dont have an active maintainer for the branch, which is already pretty far behind the patches on the D6 branch. I will consider completly removing the current D7 port, reinitiating it once again from the current D6 branch, if time comes / maintainer arrives.
For now, you can also host D7 modules on a D6 based FServer!
Main improvements and fixes
- Supports building release based on the new tags ( 6.x-2.x for example)
- Added support for SCM information in the update feed
Multisite wizard
This module simplifies the process of converting single site to multisite, make sure that the site administrator did all folder-files steps (see Multisites Using Drupal 7) and ending of auto copying and creating tables with new prefixes in same database. So you don't need to use any phpmyadmin or sql works... just click on a button!
Features:
- Very simple to convert single site to multisite;
- Tables with new prefix will be createn inside current database;
- Module doesn't drop or rename the tables of current site;
- Module copy and add prefix to ALL tables of current site (you cannot share some tables between multisite through admin panel - TODO);
- Module doesn't allow to create 2 settings.php files with same prefixes in it;
Dependencies
Required
Sponsored by Archer software
Global Avatar
Overview
The Global Avatar module is useful in multi-site environments where the user table is shared and avatars should be consistent across the network of sites. Specifically, it is designed to solve the issue raised in the post Multisite with shared user table, but how to share user pictures? This module is compatible with the ImageCache Profiles project.
Maintainer
Global Avatar is maintained by Chris Pliakas. The original development of this module was sponsored by CommonPlaces e-Solutions, LLC.
Follow Chris on Twitter: @cpliakas
Installation
In order for the module to work, Global Avatar must be enabled on all sites that share the users table. In addition, the {global_avatar} table must be shared by all sites it is installed on. Other than that, Global Avatar is installed just as any standard Drupal module. Please review the Installing contributed modules tutorial for more details. No extra configuration is required after the module is installed.
Domain View Modes
This module creates additional view modes for all entities. There is one view mode created per domain per existing view mode.
If a corresponding view mode for a domain is enabled on a content type, this will be automatically used to regenerate the content items (nodes) view. This option can be turned off in the domain settings page (see warning below). Other entities are not set up to automatically use these additional view modes.
Warning
Overriding view modes should be done early in the entity processing, but (for nodes at least) Drupal 7 does not support dynamically altering of the view mode. So these are rebuilt using hook_entity_view_alter(). This means that all node views are generated twice and could potentially be a performance issue.
Lodge your support to #1154382: View mode no longer can be changed to help resolve this issue.
You must have the Entity API and Domain Access modules enabled to use this module. This has only been tested against the latest Domain Access module, version, 7.x-3.3.
Portable path
Input/output filters to store/restore paths using either stream wrapper notation or a managed file ID token. This module does two things:
- when content is saved, it will store URLs in text fields in a portable fashion.
- when content is rendered, the input filter will replace the stream wrapper URL or file ID token with a relative URL.
This can be easily used with the Insert module which inserts an absolute or relative URL. On save of the content, this module will replace the URL with a path using stream wrapper notation or a file ID token.
The motivation behind this is to store URLs in text fields (e.g. node body) in a portable fashion so that a database can be ported across environments and domains. For example, if the environment consists of development, stage, and production URLs like:
- foo-dev.example.com
- foo-stage.example.com
- foo.example.com
with files stored in the public files directory which may be named the same as the domain like:
- sites/foo-dev.example.com/image
- sites/foo-stage.example.com/image
- sites/foo.example.com/image
This would be a typical setup using a provisioning system like Aegir which, during site creation, allows for specification of the domain name but not the directory name.
Admin Alert
This module was created specifically to fill some needs for the Local Baha'i Community Website Incubator distribution, but I felt that it might have a wider application so I'm contributing it. It currently has two functions:
1. Optionally alters administrative emails so that they are sent to all users who have administrative roles, instead of to the site email address. Many of our sites have a no-reply address as their site email; with this module, the proper site administrators will be notified of things like new accounts created.
2. Provides an API for on-site and emailed administrative alerts, so that we can notify our administrators when there is new functionality or some task that needs their attention. It functions like an administrative checklist, and we can, in code such as hook_update_N, decide on messages to be sent to all administrators of Incubator websites everywhere (if they leave the module enabled with the default settings).
This module is still in the early phases of development, and although released versions will be used on a number of production websites, there are several ideas for further development, and now is a good time for feature requests and consultation on implementation. So please make use of the issue queue.
Domain RobotsTxt
This module allows you to add additional lines to each domain's robots.txt file. The most frequently used scenario is probably to exclude a certain domain from being indexed by search engines entirely. You would use:Disallow: /
Requirements:
The admin settings form is at:admin/structure/domain/robotstxt
Bakery Optional SSO
This module allows the single-sign-on system provided by the Bakery module to be optional, rather than required for all users.
Users who first create an account on the Bakery master site will be able to visit the slave sites have their account information and sessions propagated (just like they normally can on sites using Bakery). However, users who try to register on the slave site will be allowed to create a completely local account.
This is useful in situations where, for example, site administrators are required to have shared accounts spanning multiple sites, but regular end users should only be able to create accounts on a single public-facing site. It is similar to other optional single-sign-on systems (for example, OpenID) in that respect, but the user experience is simpler all around.
How to use it
- Configure the Bakery module as you normally would. (This module depends on Bakery being enabled and configured correctly in order to work.)
- On the slave sites where you intend to enable this module, grant all authenticated users the Bakery module's "Bypass Bakery" permission. (Make sure you are aware of the implications of doing so; for example, users with shared accounts will not be automatically logged out of the slave site when they log out of the master site.)