Multiple Drupal Sites with One Monster Menus Tree (alternate configuration)

Setup

One of the downsides of using the same database as in the primary Monster Menus Multisite configuration is that many of the tables are shared and therefore many of the settings as well. This makes it difficult to, for instance, have different configurations on a per site basis. Further, as it mentions in the primary Monster Menus (MM hereafter) Multisite Configuration page, you can have prefixes for some tables not used by MM if you use the same database for both. But this often causes problems. Most notably, if the default is to share database tables then if you want to install a module on one site and not the other, it can't be done unless you set up prefixes for every table to be created by the module prior to installing it. Further, by sharing some of the key database tables (such as system) it's not possible to have differing module configurations, etc.

There is an alternate MM Multisite configuration which achieves the same goal of sharing MM between multiple sites without using the same database for most configuration items.

Step 1: Drupal setup

Create your sites using Drupal's multi-site configuration scheme. See the comments in sites/default/default.settings.php and, if using Drupal 7, sites/example.sites.php for more information.

Unlike the primary MM Multisite configuration, create separate databases for each installation and run through the install process entirely. Essentially install each as if they were their own completely separate sites. (Or, if you have an existing MM site and want to create a new slave site, you can just set up and install a new Drupal instance from scratch with a new database and then follow the remaining instructions)

Step 2: Install Monster Menus

On both sites, completely install Monster Menus. Also step through and install any desired MM submodules, such as "MM Media" to make use of the contrib "Media" module (in the D7 version of MM), "MM Fields", etc. Before proceeding, ensure there is parity in the MM modules installed on both instances.

Step 3: Pick a Master

One of your sites will serve as the master holding the MM configuration and the other(s) will serve as the slave, reading the MM configuration from the master and using the master's MM database tables. Note, this procedure could be used to set up a single slave/master relationship, but it could also be used to set up 2 slaves to a master or a dozen.

Step 4: Set up database prefixes

This is where the magic happens. You now have completely separate Drupal instances set up, but in order for them to share the MM tree, you will have to tell the slave(s) to use the master's MM tables instead of its own. Look in the sites/slave/settings.php file and find the $databases variable. It likely looks something like the following:

$databases = array (
  'default' =>
  array (
    'default' =>
    array (
      'database' => 'slave_database',
      'username' => 'database_user',
      'password' => 'database_password',
      'host' => 'localhost',
      'port' => '',
      'driver' => 'mysql',
      'prefix' => '',
    ),
  ),
);

Note the 'prefix' key. Essentially, what this does is set up a series of key/value pairs that Drupal looks at whenever there is a call to a particular database table. Right now it's empty, so there is no prefix given but we will fill it out to essentially tell the slave instance that, whenever it's looking for a table used by MM, it should look to the master MM instance instead of its own tables.

Again, ensure you have installed all MM modules on the slave instance PRIOR to taking this step. By doing this, you are ensuring your slave database has everything else set up appropriately and already thinks MM and any submodules are installed. Then you can safely use the prefix to point to the tables on the master instance without any issues. However, if you have not yet installed any of these modules on the slave instance, it may try to OVERWRITE THESE TABLES ON THE MASTER INSTANCE. This may not be an issue with 2 (or more) brand new MM sites, but if you are adding a slave to an existing master, this could really cause some damage. Of course, it's recommended that you BACK UP YOUR MASTER database before proceeding.

Now, edit the database to add the appropriate prefixes as follows:

$databases = array (
  'default' =>
  array (
    'default' =>
    array (
      'database' => 'slave_database',
      'username' => 'database_user',
      'password' => 'database_password',
      'host' => 'localhost',
      'port' => '',
      'driver' => 'mysql',
      'prefix' => array(
        'default'   => 'slave_database.',
        // Core MM tables
        'mm_archive' => 'master_database.',
        'mm_block' => 'master_database.',
        'mm_cascaded_settings' => 'master_database.',
        'mm_group' => 'master_database.',
        'mm_group_temp' => 'master_database.',
        'mm_media_gallery' => 'master_database.',
        'mm_media_gallery_imgs' => 'master_database.',
        'mm_node2tree' => 'master_database.',
        'mm_node_info' => 'master_database.',
        'mm_node_redir' => 'master_database.',
        'mm_node_reorder' => 'master_database.',
        'mm_node_schedule' => 'master_database.',
        'mm_node_subpglist' => 'master_database.',
        'mm_node_write' => 'master_database.',
        'mm_recycle' => 'master_database.',
        'mm_role2group' => 'master_database.',
        'mm_tree' => 'master_database.',
        'mm_tree_access' => 'master_database.',
        'mm_tree_block' => 'master_database.',
        'mm_tree_bookmarks' => 'master_database.',
        'mm_tree_flags' => 'master_database.',
        'mm_tree_parents' => 'master_database.',
        'mm_tree_revisions' => 'master_database.',
        'mm_vgroup_query' => 'master_database.',
        'mm_virtual_group' => 'master_database.',
        // Core node tables
        'authmap'   => 'master_database.',
        'block' => 'master_database.',
        'block_custom' => 'master_database.',
        'node' => 'master_database.',
        'node_access' => 'master_database.',
        'node_comment_statistics' => 'master_database.',
        'node_revision' => 'master_database.',
        'role'      => 'master_database.',
        'role_permission'      => 'master_database.',
        'sessions'  => 'master_database.',
        'taxonomy_index'  => 'master_database.',
        'taxonomy_term_data'  => 'master_database.',
        'taxonomy_term_hierarchy'  => 'master_database.',
        'taxonomy_term_vocabulary'  => 'master_database.',
        'users' => 'master_database.',
        'users_roles' => 'master_database.',
      ),
    ),
  ),
);

This will tell your slave database that whenever it uses a table that it expects MM to want, to use the table on the master database instead of the slave.

A few notes about this:

• It should be possible to just prefix the MM tables, but it is also recommended that you prefix other tables such as node, block, user, etc. as in the above example so the two can share content, users, and blocks. If you only prefix the MM tables, the two sites should be able to share any MM specific items like groups, etc. but will not be able to share content. It will also likely wreak havoc if MM is trying to reference users that the slave doesn't know about. So using the master's tables for users, etc. is a good idea.
• I have left some items off of the prefix above which are likely a good idea. For example, if using the MM Media submodule, it's a good idea to also prefix the Media tables (media_type, media_list_type, media_filter_usage). There are likely countless others that may need to be prefixed for your specific instance, so it may take some trial and error to get the slave working correctly.
• Likewise, if you want to share content types across sites, you will want to prefix the field_* tables. Note, this can get messy as you'll have to add a new prefix whenever a content type (or fields) are created on one site to be shared with the other. Unfortunately, there isn't really a good way around this at this time.
• As with the MM submodules, if there are any module specific tables which are being shared between master and slave (like Media in the above example), you will want to (1) install them on the slave (2) prefix them to point to the master. Doing them in reverse order or before you've installed them on the slave will make a mess as the slave needs to think they're installed.
• Note that each prefix ends with a dot. This is what tells it to look to the master database instead of the slave. So instead of using the slave database's mm_tree, any database call to mm_tree will get master_database. prepended so it will be using master_database.mm_tree in any queries to mm_tree.
• Ensure the database user is either the same for both instances or at least that the database user for both the master and the slave(s) have permission to read/write from/to the master database. If not, this configuration will not work. To ensure consistency, it's probably easiest to create a single user in mysql which has access to read/write from/to both.
• This has only been tested with the slave as a vanilla Drupal instance, so attempting to add MM like this with an existing site and tying it to a master must be done at your own peril!

Step 5: Set the homepage on your slave

Now go to the URL admin/mm/sites on your slave and you should see a single entry as the current homepage. Add a new homepage and set it as the "Current Homepage" on the slave instance. This will essentially create another branch of the MM tree for the slave instance, setting its homepage to the root of that tree.

Step 6: Check out your slave

As mentioned briefly in the notes above, you may have run into tables referenced by MM on your slave that have not been prefixed. If you come across any, just add them to the list of prefixes.

You should be able to the master's browse groups, files, etc. on the slave and assign groups from the master to the slave!