By slane00 on

I posted earlier about my need to create an intranet/extranet combo, where internal users have wide access to content, and external/client users are in effect "jailed" into their own site, with their own forum and file sharing areas.

It sounds like multiple sites (not multiple installs) could solve my problem. But I need to understand something.

Are multiple sites generally intended to each have their own database? That gets created using the prefix_ logic? This could look fine, except that my internal users need to be able to be added to any or all of the client sites, so a centralized user table plus a table that maps users to sites would be best.

Oh, here's a crazy idea -- what if I point each client site, not to a user TABLE, but to a user VIEW, that in turn creates a correct query against a single master user and user/site tables? (user table, I assume, is stock Drupal, user/site mapping table I would have to create and maintain using my own tools).

so, to summarize, 2 questions:

1) Do multi sites generally get run off multiple dbs?
2) Could it work to point individual sites at user VIEWS, not user TABLES?

-- SGL

⋅ Categories: Drupal 4.7.x

Comments

brenda003’s picture

brenda003
she/her
commented

Multisites can use either one database or several databases, or a combination of both. I don't quite understand the user views point you make, but you can definitely share tables across databases. For example, I have a several websites that are multisite installs using one codebase, but they all have seperate databases. They share many of the same tables, though, including the users table, so that users can log into any site.

Some of the sites even share the content, but it is displayed differently on each site.

I'm not sure if multisites is quite what you even need. You could simply have the memebrs area invisible to any clients, and clients could be forced into their own organic groups. That would all they know existed. It may require some moditifcation, though - I'm unsure, it's been quite some time since I've used organic groups.

slane00’s picture

slane00 commented

I did look at organic groups, but it seemed to me it wasn't set up to isolate people into single groups -- that by default it let you see and subscribe to multiple groups -- and that model would never be right for our clients, who would only ever have access to a single group. Would organic groups work for that?

My point about views was this. Say I want to use a single users table across all my sites. But many users (those who are clients) do NOT have access to all content by default. I could create a separate user table for each of my multi sites, if I use multi sites. But then, I need to copy my employee users into the new table for each client site they can access, and then I have multiple copies of each employee record. What I really want is a master table of users, plus a new table of user->site mappings that assigns each user to one or more sites (the more sites they can access, the more records they have in this table). Then, in the settings file for each site, I describe the users table as something like client1_users, client2_users etc. This is just what it would look like if I were using completely separate user tables for each client site. The difference is that these are not tables at all, they're just views, that look like this:

CREATE VIEW client1_users AS SELECT u.* from users u, user_sites us where u.id_user=us.id_user and us.site = 'client1';

It would be up to me to create an interface for creating those views and assigning users to sites, but this is something I could easily tack on to the main Drupal install.

Anyway, my main question is whether organic groups would work well where I want to create many sites where each is effectively walled off from the others.

-- SGL

fallacious’s picture

fallacious commented

I'm using them for fine-grained access control on one site.

There's content that anonymous users don't see and even registered members only have a partial view. Specifically, unless they are admins they do not know what roped-off areas there are. I don't know if they support exactly what SGL has in mind or how much work it would take to make it happen.

If it's of paramount importance to keep content visible to designated users, then running a shared codebase with separate databases is probably the way to go. I haven't used this myself, but it looks feasible to have users register at the default site and use drupal.module on the private multi-sites to share accounts. If it's indeed possible to share the default site's users table, so much the better.

Success’s picture

Success commented

I am checking out multi site configuration also.

How to have multiple database?

And, how to have the setting file, themes and modules on the individual domains? I don't want my files directories of all my sites to be on the same site as the codebase.

goo13’s picture

goo13 commented

Multi site setups:

1) Have a config script for each domain

The INSTALL.txt actually has a bunch on this.

Additional site configurations are created in subdirectories within
the 'sites' directory. Each subdirectory must have a 'settings.php'
file which specifies the configuration settings. The easiest way to
create additional sites is to copy the 'default' directory and modify
the 'settings.php' file as appropriate. The new directory name is
constructed from the site's URL. The configuration for www.example.com
could be in 'sites/example.com/settings.php' (note that 'www.' should
be omitted if users can access your site at http://example.com/).

2) Each have their own DB or own unique set of tables (using table prefixes)
It kinda stinks, but thats just the way it works.

- Cory
Nexation

Salman_Rahma’s picture

Salman_Rahma commented

I have several domains parked at my shared virtual server; /www/ (default) and /www/site2 . Now I have created a drupal installation for my site1 directly in /www and sites now resides in /www/sites and it has /www/sites/site2 with its own settings.php pointing to its own database and db username/password.
when I type in the browser: site1.com it works but site2.com doesn't. There is something else missing.
I tried to remove /www/site2 and make it symlink pointing to /www/ (where the default, first site1 index.php is) using:
ln -s /home/user/www/ /home/user/www/site2/
but no file or directory, although somehow, I don't think this is the right thing to do.

Please advice

Salman Al-Rahma
mishkah

Salman_Rahma’s picture

Salman_Rahma commented

The mistake was in the last trailing slash:
ln -s /home/user/www/ /home/user/www/site2/
Should be:
ln -s /home/user/www/ /home/user/www/site2

and it works. I have bothe www.site1.com and www.site2.com working. I am not sure though that this is the best method to use, but it works :-)

dgorton’s picture

dgorton commented

Here's a related discussion on setting up OG to do this task.
http://drupal.org/node/77264

Also, this very interesting screencast covers upcoming node access and jquery functionality... very cool
http://mixel.be/?q=node/18

Drew Gorton
Gorton Studios
Some of our Drupal Sites