Posted by glass.dimly on August 28, 2009 at 9:49pm
Hey y'all,
I manage about 8 sites, a single organization with multiple websites/projects. We all work in the same building. Basically, I'd like to define certain settings that are shared to make the user interface consistent.
I want to be able to be able to share or easily export, say, WYSIWG settings across all the sites. I might also want to be able to manage users across sites. You can guess the sort of things that might make my life easier in this situation. I know there are different solutions, like shared tables, but I want to know what folks are doing, and what works for them. What about modules?
Does anybody have any wisdom or knowledge for a young grasshopper?
Comments
Generally speaking, any time
Generally speaking, any time the problem is "I want to share users and/or content between sites," the answer is to use Domain Access instead of Drupal's standard multi-site system. I generally can't recommend taking the shared tables approach when Domain Access is so good at what it does without having to delve into that mess. With Domain Access-powered sites, all modules and module data is also shared between sites, so your WYSIWYG editor settings problem will take care of itself.
But you say you're already managing eight sites… Do you mean you already have eight separate Drupal sites which you'd like to bring together into a single installation? That's a different problem, but not too difficult to do - using standard Drupal multisites, that is.
The Boise Drupal Guy!
Multisite / shared tables approach
We've got about 25+ sites going off of a multisite with shared tables. We're sharing the users, authmap, profile_fields, roles and some legacy tinymce tables. I'm not sure how clean Domain access is when it comes to overriding settings in the variables table but from what it sounds like you're saying you want JUST the Wyziwig settings to be standard across the network as opposed to everything. Domain Access's description says that it can do that though I've never used it.
Personally though the reason we don't do that is that I won't tie ourselves to any 1 project. From our own situation.. we were tied to several drupal 5 projects in the core of our "architecture" (if you can even call it that). When Drupal went up to 6 someone those projects went away and others changed dramatically. By tying our infrastructure of sharing users and anything else to the core of drupal, independent of any modules specifically, we are better prepared to upgrade / move in the future. Also, if the user table stays the same (don't know yet if it will) then I can start to have 6 and 7 sites running on the same shared tables architecture and users can flow between systems w/o issue and w/o me pulling my hair out about another fundamental shift in Drupal module ideology. Project 5 years out from now; how will you manage all those sites the easiest should something go away or clients want more up to date versions of Drupal. Then make a decision off of that mindset; that's my advice anyway :p
"Plaguing the world with Drupal; One Plone, Moodle, Wordpress, Joomla user at a time since 2005." ~ btopro
http://elearning.psu.edu/
http://elearning.psu.edu/projects/
http://elearning.psu.edu/drupalineducation/
Ex Uno Plures
http://elmsln.org/
http://btopro.com/
http://drupal.psu.edu/
Thanks for the useful advice..
@Garret Albright,
I inherited 8 Drupal sites on different versions of Drupal, on separate Drupal codebases. I'm in the process of upgrading them all to D6 and standardizing the themes (make them all subthemes of Earthen).
I'd like to manage them centrally, share users, share various module settings, WYSIWYG is just an example. I don't need to share CCK, views, or content. Though we actually do share content between sites, we just use FeedAPI right now, with a canonical version of the content.
It seems geared towards a single site with logical subsections. ("... from one Drupal installation and a single shared database...") Can it also be used to share settings in a multisite environment, with separate databases and a shared codebase? Migrating all the sites into one Drupal install is a difficult process, if you want to preserve old URLs. If that doesn't matter...
...But it does. On another project, I'm doing exactly this, and it's a big job. Is it worth it?
So the question is, Domain access: useful for multisites? And if not, is there another module for multisites?
@btopro
Intriguing. Do you recommend a new, separate database for shared settings? Are you just sharing tables in a standard, Drupal way, or are there any tricks of the trade? Are there any pitfalls you could briefly mention? I've been reading the docs, but some advice would be nice.
I guess I just want to get a sense from you how difficult this is, and if its worth it for 5-6 sites (I'm axing a few of 'em).
Not too complex
Complexity is rather low for what you gain. As long as they're all within the same version you can share tables w/o issue and there's a lot of different tables known to be safe to share (the ones I mentioned before). What you gain is standardization of user accounts across your sites (useful if they're related in anyway, even if it's just the admin staff). You can also standardize your roles which is nice because then if you do anything hacky at a module level you can say things like if user role is 6 (a "student" in our system) then do x,y,z. Saves on data replication (not super advantageous).
We have 1 database that uses the centralized tables directly and then 1 database per site in the network (which points to the central one for it's users, ect). Pitfalls? Haven't run into any yet other then that connecting D5 sites in a D6 central network isn't possible so those sites always have lived outside the network. Also, if you set things up the right way it'll play nicely w/ the other projects I write that usually have that connotation :)
Ex Uno Plures
http://elmsln.org/
http://btopro.com/
http://drupal.psu.edu/
I'll get back to this thread
As I test out shared database tables this coming week.
More info?
btpro,
If you paste some of your settings for shared database tables from your settings.php file, I'll create a handbook page for it.
Right now, the only shared table documentation is for tables shared within the same database, not across databases, so it'd be great to see that syntax.
Thanks,
glass.dimly
Sounds great
Here's the $db_prefix for most of the branched sites in our network
$db_prefix = array(
'default' => '',
'users' => 'CENTERALSITE.',
'authmap' => 'CENTERALSITE.',
'profile_fields' => 'CENTERALSITE.',
'role' => 'CENTERALSITE.',
'tinymce_settings' => 'CENTERALSITE.',
'tinymce_role' => 'CENTERALSITE.',
);
Authmap, user and role are all good ones to do. Profile_fields is so that the fields are standard but each site can have it's own values for those fields. We're phasing out tinymce usage as it's a dev build from before so... for right now those are the ones we use. I've seen talk of centralizing sessions but our sites aren't related so if your sites aren't I'd recommend against that. Here are some other ones I've investigated centralizing but haven't at this time...
files - since they're tied to a user you could see all the files a user has submitted across the infrastructure
filter_formats - May do this in the near future so that our input formats are all the same settings as they should really align with roles as to who can submit what types of code
filters - same reasoning as above
node_type - this way you'd have the same types across the network so lexicon would all be the same but you could still use different fields in each sub-site
views tables (all of 'em) - I've been looking into the prospect of doing this because we use the same visualizations of data across most of our sites. It's not to say most should do this but it should be possible so that you're basically just connecting to a different database to view data in the same way. If you don't use a view in every site it shouldn't matter. Probably only a good idea for small groupings of related sites.
watchdog - should be safe to centralize. Could get ridiculously huge so that might not be a good thing but at least you could see everything going on in all your sites if you need that kind of high level view of everything
One other thing to point out is that we have different tables shared in each of our settings.php files. MOST are the ones listed at the top in the db_prefix but we have a few that share other tables or less tables so that they can have local / specific instances of things. Also be careful that if you "delete" a user or role or content type or whatever in one site you're now doing it in all of them :) That's the only buyer beware of this whole thing. Don't delete, just stop using :)
The only thing we do in our CENTERALSITE that's any different is add another db_url to the information_schema $db_url['information_schema'] = .... This isn't required but then allows you to be able to do cross site queries in a much more flexible way cause you can do system level queries to see what drupal sites there are in the network generically :).
Ex Uno Plures
http://elmsln.org/
http://btopro.com/
http://drupal.psu.edu/
why not share a single database?
What's the advantage of having each branch site having it's own database as opposed to prefixing table names in a single db? Is this in case one of the branched sites ever need to be on it's own drupal installation?
You nailed it. There are a few reasons for doing this...
All in all our approach is just for flexibility going forward to keep us nimble
Ex Uno Plures
http://elmsln.org/
http://btopro.com/
http://drupal.psu.edu/
updating each site...
In this type of config, you'd have to run the update.php script for each branch site? It seems like a fair compromise for the flexibility gained.
Correct
Correct, that's one of the trade offs. Another is changing settings like clean urls across all sites cause you need to go to the same page on every stinkin site to do it. But then again....that's why this was born -- http://drupal.org/project/network_manager
There are also drush / scripts that can be run to perform all updates on your sites. I'm looking for a good one if anyone has one. Preferably something that is a drush-less solution because I don't want users to have to understand how to install that to get a one-click update of all sites. I have a jquery / script solution that i've used for static publishing but i'd rather do it backend if possible.
Ex Uno Plures
http://elmsln.org/
http://btopro.com/
http://drupal.psu.edu/
You may remember I posted a
You may remember I posted a thread about using Drush to do tasks like running cron and updating the database for every subsite of a multi-site installation.
But you're saying you don't want to use Drush. You'd rather use a browser-based solution? I think Drush will work better for something like this, and it's really not difficult to install or use at all - I encourage you to give it a try.
The Boise Drupal Guy!
Generalities
I was speaking in generalities. The goal of most of my projects is to lower the cost of entry to Drupal to as close to 0 as possible. I need to distribute this architecture setup around campus to people that are less technically savy yet still need the management power that they can leverage from this approach w/ a few other modules configured. Love what you can do with Drush, integration is part of the roadmap of network manager but in trying to install it the other day it seemed it would take more then 5 minutes and require server access (something other admins locally won't have) so I'm trying to avoid using it if possible. Unless I'm totally over complicating how you use / install Drush but it's command line / a server install that you need to point to the right php packages in .ini files right? If I can get it setup on our test server and then production one I can give it out as the server is a distribution but still not ideal.
Ex Uno Plures
http://elmsln.org/
http://btopro.com/
http://drupal.psu.edu/
Oh, you're talking about
Oh, you're talking about wanting something clients can use. You should have said so. :P
Drush doesn't have any .ini files of itself to edit. Its main script does have a hashbang line, but it uses env, so I imagine any modern Unix-like should be able to run it. In my cases, I've never needed to edit any files to get Drush to run, though you may need to chmod it to give the script itself execute permissions if you want to run it directly.
The Boise Drupal Guy!
just to be clear...
CENTRALSITE would be in the mysql://username:password@localhost/databasename format, which would simply be $db_url for the central site with a trailing /?
Correct
Correct. Our subsites have a db_url that points back to the central one BUT, this is just for query purposes. You don't need to do that in order to utilize the CENTRALSITE.'s tables. You'll just need access to them at a DB level, Drupal doesn't care if you define the connection string stuff. Note though that the same user for DB1 will need acess to centralsite at the same permission levels in order for this to work (i believe).
Ex Uno Plures
http://elmsln.org/
http://btopro.com/
http://drupal.psu.edu/
what if I have two sites that are already established, to merge?
I have two sites and possibly a couple more in the future that I am looking to migrate into a multi site setup. Each site has different users. For example, on one site we are using LDAP to allow people to authenticate using their username and passwords from our member only site. From what I'm reading, I'm feeling like sharing user tables would be a bad idea in my case..... Also, we have different people doing different admin/content editing on each site, so do we need to share roles and profiles too? For example John B has a role on site one and a role on site 2 that is different. would sharing these two tables create conflicts? I am a little unsure of this...
Becky
No need to share
If you have sites that were created indepenedent of each other it probably makes sense to just keep them completely separate at a database level. You CAN share roles between systems as long as the role IDs are the same in the systems but that's a pretty minor thing to standardize on. Typically you start at shared user table base and then build from there instead of roles or anything else. You can still move everything into a multisite setup, just no need to worry about the DB stuff changing.
Ex Uno Plures
http://elmsln.org/
http://btopro.com/
http://drupal.psu.edu/
hmm.. ok. so if these sites
hmm.. ok. so if these sites both have super user accounts each with the same username but different password, wouldn't that create a conflict if they were sharing user tables?
Becky
it wouldn't conflict so much
it wouldn't conflict so much as grab onto the super user account of which ever database you route everything over to.
Ex Uno Plures
http://elmsln.org/
http://btopro.com/
http://drupal.psu.edu/