Community & Support

Multisite: which specifics modules and themes?

Hello,

it's my first time installing a drupal multisite.
how to determine if a module should be site specific or not? in all/ or specific folder relative to a specific site ?

  • is it because it is used by only one site?
  • is it because its configuration is different for each site?

Let me explain with some examples:

  • I want to use advanced_help, I shall then certainly in all/ directory
  • but pathauto, I want to use it in all my sites, but with different settings ... what to do?
  • Ubercart? I'd like to have a console common to all sites. I have to put in all/?
  • facebook for drupal api requires a code provided by fb, then I put in all/ but could have different configs?
  • and taxonomy_image?
  • ...

Thank you for your wise guidance :)

Comments

I put most in the all/modules folder

I've only been running a multisite for a little while. It will likely depend on HOW you set up your multisite. If you use the symlink method or if you use the Domain Access module and supporting modules or not.

http://drupal.org/project/domain

The only ones that I have set up independent are themes only so that they can get some custom changes.

I use Domain access and a low tech pathauto fix which is simply to create different content types and then only enable them to be used by roles on specific sites then I can use one install of pathauto and just give each one the url I want. It works ok but could get very cumbersome if there are a lot of very specific paths that you need but I find that I keep most standard, as users are used to seeing things like blog / forum / gallery etc so for most I can share them across most domains.

If you use the domain access route you can find quite a few snippets to give you control over things like twitter etc.
You can easiely setup your content to be site specific while sharing the things you want to.

It already has contributed modules for

Contributed Modules

The following modules have been contributed by other developers to extend the features of Domain Access.

* Domain Locale by nonsie. Provides custom language sets per domain for Drupal sites using Domain Access and core Locale module.
* Domain Access Advanced by gordon. Enables multiple node access modules to work together by moving Domain Access rules into db_rewrite_sql() instead of using the node access API.
* Domain Actions by gordon. Provides integration for Domain Access to allow actions to be taken based upon the domain. Works with core actions and the Rules module.
* Domain Blocks by nonsie. Enables domain specific visibility settings for blocks, eliminating the need to prefix the blocks table. [Drupal 6 only]
* Domain Geolocalization by jhedstrom. Allows domains to have associated locative information. When combined with the Domain User Default module, this module uses the Google Maps API to geocode users zipcodes for domain proximity searches.
* Domain GMap by jk@arsum.com. Multi-domain support for GMap module.
* Domain Login Restrict by jk@arsum.com. Restricts user login by domain affiliation.
* Domain Menu by canen. Allows each subdomain to use separate primary and secondary links. This feature is native to 6.x.2.0.
* Domain Node Type by Pasqualle and zserno. Gives privileged users the ability to set default domains for content types.
* Domain Nodequeue Tab by awolfey. Provides each node with a tab where users can assign that node to a domain-specific queue.
* Domain Relationships by nonsie. Adds relationships/grouping capability for domains.
* Domain Taxonomy by xanderz. Extends Domain Access functionality to taxonomy objects, by filtering terms by their assigned domain.
* Domain Toggle by falcon. Introduces open and private domains. In private domains users are forced to be assigned to a domain in order to view content on that domain. In open domains everyone can view the content. Replaces Domain Strict for some use-cases.
* Domain User Default by jhedstrom. Provides methods for users (and unauthenticated site visitors using the Session API module) to select a default domain. A version of this feature has been added to 6.x.2.0.
* Ubercart Domain Access by longwave. This module provides a basic integration of Domain Access for Ubercart, allowing an Ubercart store to span multiple domains, storing the originating domain when an order is made and displaying the correct store information on invoices. [Requires use of Domain Configuration module.]

Keep in mind that the modules

Keep in mind that the modules page loads all modules, irrespective whether they are enabled or not. If you have lots of sites with many different modules all residing under all, at some point your module page might run out of memory and show up blank. In addition to increasing the allowed memory in php.ini this can be resolved by moving modules to the site specific directories.

I tend to put generic modules such as cck and views in all and move more 'obscure'"modules in the site specific directories.

Mark

Oh, and settings are normally

Oh, and settings are normally stored in the database, so each site can use its own settings. So that is not an issue.

Mark

thanks all for your answer i

thanks all for your answer
i understand now ;)

nobody click here