multiple sites on 1 install

[Bad Intentions]

Is it possible to set up multiple sites using 1 install?

domain/dept1
domain/dept2
domain/dept3

all running off of 1 installation of cmsms.

[Ted]

No, there is no way to share 1 install across 3 separate sites.  But you can share 1 database by using different table prefixes.  Almost as good. 

[nuspace]

This should be possible if you use the HTTP_HOST env variable. We're planning to use the following method to implement a multi-site installation ourselves.

First you need a separate subdomain for each site:

dept1.domain
dept2.domain
dept3.domain

Then in config.php get the value of $_SERVER['HTTP_HOST'] and use that in your url settings instead of the hardcoded domain.

e.g.
$MYHOST = $_SERVER['HTTP_HOST'];
$config['root_url'] = "http://$MYHOST";
etc

You can strip off '-' and '.' from the hostname and use that as your database name and in your uploads path so you have a different upload directory for each site.

[trick]

Yes, as nuspace said, it should be possible. I'm just thinking off the top of my head, but here's some ideas on how to work it. Remember, this only works in theory, don't expect it to actually work quite right.

Easiest -- subdomians:

for example

sub1.domain.yours
sub2.domain.yours
etc.domain.yours

now make sure they all point to the same place on your server (were you installed CMS, probably called htdocs) and then go the the first url. CMS will guide you through the installation. Just do things as normal if you were installing that CMS. When you are done, go to the config.php file, it will look something like this:



note that some of the options will work for all sites, and some need to be customized. To do that do this:





Of course I left stuff out, but I hope that's enough fo you to work off of. The other method would be to use as you seed and have it like

domain.yours/sub1
domain.yours/sub2
domain.yours/etc

You would have to perform a fair amount of magic with mod_rewrite though to get it working properly, so I won't try and explain it here.

[nuspace]

I didn't even think of using a switch. You're right, your treatment is more thorough. But if you're happy to have settings such as use_bb_code and use_smarty_php_tags the same for each site, here's a shorter way to do it:

$MYHOST = $_SERVER['HTTP_HOST'];
$MYSUB = preg_replace('/\..*$/', '', $MYHOST); // haven't tested this regexp but I think it should be right

$config['db_prefix'] = $MYSUB . '_';
$config['root_url'] = "http://$MYHOST";
$config['previews_path'] = "/var/www/localhost/htdocs/tmp-$MYSUB/cache";
$config['uploads_path'] = "/var/www/localhost/htdocs/uploads-$MYSUB";
$config['uploads_url'] = "http://$MYHOST/uploads-$MYSUB";
$config['image_uploads_path'] = "/var/www/localhost/htdocs/uploads-$MYSUB/images";
$config['image_uploads_url'] = "http://$MYHOST/uploads-$MYSUB/images";

[trick]

I just realised a flaw with my example from reading http://forum.cmsmadesimple.org/index.ph ... 455.0.html

The modules will all be shared, however, the module configurations will not be. This will probably not be a problem, but if you want to use a different template for a part of a module (most modules store tempates under the modules directory) than the other guy, it will be. There are work arounds though.

[rebaf]

I've been an interested bystander on the multisite discussions with several CMS. It seems to me everyone is trying to meet this requirement from the same direction - one database but use separate prefixes for all or some of the tables.

An alternative approach is to add a "site" field to every table and modify the sql instructions to handle this field. To me, a major advantage of this approach it could be easily adapted to provide default values. For each current sql "select" statement prime the site value with the specific site value. If that is successful use the values retreived if returns an empty recordset change the site to the default value and try again.

This default value arrangement could be extended to provide groups of centres that all share the same characteristics and yet still provide individual settings. The sql would become possibly 3 layers. First set the site value to the specific site, if unsuccessful, set it to the group value and if that's unsuccessful, set it to the default value.

Anyway, it's just an idea.

[ceilingfish]

As an advancement of that idea, you could include something like that in the cms_db_prefix() function.

If at page initialisation the domain being accessed was detected it could return something like:

cms_example.com

if it recognises the domain as in it's list of acceptable domains, and then if the domain wasn't recognised it could just return

cms_

which would be a database template containing all the default material.

It would avoid having to rewrite all the sql queries.

[ceilingfish]

Come to think of it, when is the first call to the module architecture made? Would it be plausible to write a module that manages the list of domains to recognise. It might be somewhat monstrous, but I can't see why it (in combination with lots of calls to $_SERVER['SERVER_NAME']), could also manage allowing users access only to specifc sub domains for administration.

[Ted]

I'm in favor of making it all in the same tables.  That allows us to not have to force people to setup anything extra on our end to add a new site.  Just create it and it goes.

However, that does mean that site id has to be added to most tables and a lot of stuff is going to break.

I'm kind of holding off on these big ideas until after 1.0 comes out.  And then the sky's the limit on what we can make better.  Lord knows there is enough that needs it. 

[iNSiPiD]

I can't help but feel that for large sites it woul dbe better to use a new DB for each. This would also avoid the issue of multiple tables for modules et al.

I'm thinking a new 'multisite admin package' that allowed you to administer multiple domains. Select the site you want and then you end up at the current CMS admin panel.

People would still need to enter requisite information for each site (domain, ftpserver, username, password, db_prefix etc). And then perhaps, one day, it may even be possible to deploy a new site from here by copyng the 'core file' across to the new site location, set permissions, and create the tables (and even the db given permission).

Hope that makes sense. I tend to ramble at this time of day.

[lemkepf]

I can't help but feel that for large sites it woul dbe better to use a new DB for each. This would also avoid the issue of multiple tables for modules et al.

I'm thinking a new 'multisite admin package' that allowed you to administer multiple domains. Select the site you want and then you end up at the current CMS admin panel.

People would still need to enter requisite information for each site (domain, ftpserver, username, password, db_prefix etc). And then perhaps, one day, it may even be possible to deploy a new site from here by copyng the 'core file' across to the new site location, set permissions, and create the tables (and even the db given permission).

Hope that makes sense. I tend to ramble at this time of day.

This is definitly the better idea. It wont require a major re-write of code/modules to use it. My hosting company is actually looking for something very close to this to offer to our clients. (more of a central install of the files, and each user get's the DB.)

I think this would be cool, but not on my high priority list. (i'd love to see some tuning changes first)

[lemkepf]

OK... so i have a question for you all....
My hosting company would like to install CMSMS for our clients. You know like a "one click install" type thing. I think this will be easier than what most of you are trying to accomplish.

1. They will all be on seperate domains.
2. They will all have seperate DB's.

The issue i have is we dont' want to copy all the files to their accounts, we want a central location for them all. So we plan on using symlinks to put the files under their account.

If we were to do that am i right when saying that these folders shouldn't be sym'ed?
/config.php
/tmp/
/uploads/

Correct? Or am i missing something?

I read somewhere that some modules store their templates on the filesystem and if people want to modify the tmplates... so i might have to copy the "modules" directory too.

What do you think?

[Ted]

Yeah, you're correct.  There is no reason why it shouldn't work. assuming apache is setup correctly to follow symlinks.

You can probalby get away with using the same modules directory if they all want to use the same version.  Any changes to modules files (like templates) go into the database or into tmp somewhere, so it shouldn't be an issue.

The only problem will be when you update a module, you'll have to go to each individual system and hit the upgrade button.

[alby]

If we were to do that am i right when saying that these folders shouldn't be sym'ed?
/config.php
/tmp/
/uploads/

Correct? Or am i missing something?

Maybe there is a problem with fileloc.php [dirname(__FILE__) is the absolute filename path]

Alby