Updating a Multisite with separate databases

Events happening in the community are now at Drupal community events on www.drupal.org.
hellomobe's picture

I've structured my multisite to share modules, core, and themes, but the databases are completely separate. User created content doesn't need to be shared.

Being new to this process, how do I go about updating "database" structured items across all the databases. For instance, how could I add/change a view? Or add a field to a content type? Or add a taxonomy term?

Comments

databases are separate

eporama's picture

Since the databases are separate, and this is generally where the views, content type definitions, and taxonomy terms are held, you would need to manage this as you would for completely separate installations.

The views, content type definitions both have "export" capabilities where you can put the definitions in code and then make the new modules available to each site. If you're new to all of this, you might try the Features module which can help you get these pieces out of the database and into code that can be shared.

Since you have two completely

rpsu's picture

Since you have two completely separated databases, you need to updating on both sites separately. So if you only update for example a view and want to do the same update on both sites, you need to either do same stuff on both sites or do items on one site and export+import to the other.
There is also Features module http://drupal.org/project/features to help you export+import process. It may be helpful you if you have more than two sites. With only two sites it will just create more hassle, IMO.

When you do update code, you need to update (run update.php) on both sites. I suggest you put both sites on maintenance mode, update code, run update.php on both sites, make sure both sites are functioning properly and put them out of maintenance mode.

--
Perttu Ehn

Maintenance of Multisites in Drupal

shyamala's picture

From a maintenance perspective using a multisite installation could be a hazard, as any code update you do gets updated in all your instances. Which means you can not Schedule your updates for all your instances separately. You may want to take all your sites offline before the update.

Read more at Acquia's post on Maintaining Drupal Gardens:Minimizing maintenance time while updating...

Webinar on Multisites: http://www.acquia.com/resources/acquia-tv/conference/reduce-cost-each-ne...

I suggest to use features

kannan@kiluvai.com's picture

I suggest to use features (http://drupal.org/project/features) module + strongarm (http://drupal.org/project/strongarm) module as Strongarm provide exportables of Drupal variables. But when you use features module actually your views and field to a content type will reside in the module generated by features module ( i.e. code ) not in the database.

Kamalakannan S
Global SoftLab
I love programming

Thank you for the feedback.

hellomobe's picture

Thank you for the feedback. Yes, I will definitely take a look at Features and Strongarm. Thank you for the webinar link too.

Let me explain a little more on what I'm doing. I'm setting up a niche multisite for use similar to Ning or Drupal Gardens (template sites) where there could be thousands of sites. Say that I want to add another field to a content type for all the sites. How would I have to do this?

Would I make the change in the master database (meaning the database I use to create the site templates), export with Features and do an update.php on all the sites?

If there is a better way to do this, I'm open to suggestions.

Would I make the change in

Garrett Albright's picture

Would I make the change in the master database (meaning the database I use to create the site templates), export with Features and do an update.php on all the sites?

Well, making the change in the database and exporting might not even be necessary. Once you have your mind wrapped around how Features works, you can just change the code directly. In some cases, update.php is necessary; sometimes, just a cache clear will do the job. (Not that you should use update.php literally; for multi-site installations, using Drush to run database updates or cache clears across all sites at once will make your life much easier.)

Have you considered Domain

Lakeside's picture

Have you considered Domain Access?

On the project page there are some videos well worth the time to get a better idea of what the module can do for you. This is one module where you MUST read the install files.

In the videos he demonstrates why its easier to maintain several sites that DO NOT share content.

*_*

beautifulmind's picture

The only advantage I see in a multisite enviroment is sharing the core files and common modules. Otherthan that, it would be quite cumbersome to keep all the sites in sync. You may some updates from your developers to be uploaded on a site and you want to upgrade few modules on other site which are shared by all the sites!

Regards.

Specifically what are you

Lakeside's picture

Specifically what are you referring with "cumbersome to keep all the sites in sync"?

If I'm reading you right the modules from your developers can be uploaded to specific sites. So, for development purposes a multisite is going to be no different than if each site had its own core files. If you are running a dozen or more sites updating one site core install is far easier than repeating the process countless times.

Multisite

Group organizers

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds:

Hot content this week