One Installation, Multiple Sites

Author Message

Huseyin Bilgen

Monday 14 April 2008 2:24:20 am

Hi,
Assume the following scenario:
More than one site will run on a domain and those sites will be subdomains to the main domain like;
xxx.domain.com
yyy.domain.com
zzz.domain.com

So, I've setup ez 4.0 files under www.domain.com/ez/ and started the installer;

Which path I've to follow to setup those subdomains as seperate sites and use installer?
Secondly, is there any way to setup a global user managment for those seperate sites?

regards

Carlos Revillo

Monday 14 April 2008 3:43:28 am

Hi.
take a look at
http://ez.no/ezpublish/documentation/configuration/configuration/tips_tricks/several_sites_with_one_installation

You don't need several folders for several domains. you only need to play with virtual host definition in your server and use

[SiteAccessSettings]
MatchOrder=host
HostMatchType=map

This way, you will also be able to setup a global user management for all your sites.

Huseyin Bilgen

Monday 14 April 2008 4:12:41 am

Hi Carlos,

I'm not an expert as you guess with subject. I'm hosting my site at a reseller hosting account, and so, could you please let me know how to;
- modify site.ini for my scenario
- will there be only one database for all sub domains. So, this provides single user database, but what about news, forums, wiki's. Will it possible to seperate content?
- For seach, will it be possible to search withina subdomain or whole subdomains?

regards

Carlos Revillo

Monday 14 April 2008 6:53:16 am

Hi. I will try.

If you have used the wizard installation, maybe you will have two "siteaccess" configured. Something like
http://www.yourdomain.com/plain_site
and
http://www.yourdomain.com/plain_site_admin

If you look at your settings/override/site.ini.append.php you'll probably have something like

[SiteAccessSettings]
AvailableSiteAccessList[]=plain_site
AvailableSiteAccessList[]=plain_site_admin
....
MatchOrder=uri

The trick is to change that MatchOrder value to host and map domains to any of your siteaccess.

Let's suppose you need something like www.yourdomain.com as your public site, and something like admin.yourdomain.com for your admin interface. you will have to do something like

[SiteAccessSettings]
AvailableSiteAccessList[]=plain_site
AvailableSiteAccessList[]=plain_site_admin
....
MatchOrder=host
HostMatchType=map
HostMatchMapItems[]=www.yourdamin.com;plain_site
HostMatchMapItems[]=admin.yourdomain.com;plain_site_admin

Of course you will have to ask your hosting provider to create a dns entry for the admin subdomain, and setting document root for it to the same document root as your public site. eZ will know wich settings, templates and all stuff to serve depending of the domain the visitor types in this browser.

If you need a new subdomain, you will have to create another siteaccess to map it. Let's suppose you need site1.yourdomain.com. Your settings/override/site.ini.append.php will have to look like

[SiteAccessSettings]
AvailableSiteAccessList[]=plain_site
AvailableSiteAccessList[]=plain_site_admin
AvailableSiteAccessList[]=site1
....
MatchOrder=host
HostMatchType=map
HostMatchMapItems[]=www.yourdamin.com;plain_site
HostMatchMapItems[]=admin.yourdomain.com;plain_site_admin
HostMatchMapItems[]=site1.yourdomain.com;site1

and you will have to create settings for this new siteaccess. For this, you can duplicate settings/siteaccess/plain_site to settings/siteaccess/site1. In this new folder you'll change all the settings needed to look for another design for example.

Following with your questions, the answers is that it depends on what you want. I mean, you can create several databases (one per subdomain) of you can use only one for all of them.
To separate content between domains, maybe you can have a look at content.ini.append.php
you can change rootnode in your settings/siteaccess/site1/content.ini.append.php, so, only nodes in this "leaf" of the tree node will be shown for that siteaccess...

Hope it helps.

Piotrek Karaƛ

Monday 14 April 2008 7:12:46 am

I don't think there is setup wizard's support for this kind of configuration, but the goal can be definitely achieved, including separate content branches. One question you have to ask yourself is: will that be beneficial for your project, or will that be only a source of problems - it clearly makes your project more demanding, you'll share the users, cache management to certain extent, content tree, roles... So, while the sites be connected in any way, or you're just looking for a centralized platform? This is a great functionality, but only when you really know what you're doing... that's just my two cents ;)

Good luck,
Piotrek

--
Company: mediaSELF Sp. z o.o., http://www.mediaself.pl
eZ references: http://ez.no/partners/worldwide_partners/mediaself
eZ certified developer: http://ez.no/certification/verify/272585
eZ blog: http://ez.ryba.eu

Andreas Kaiser

Monday 14 April 2008 3:35:19 pm

Piotrek is right,

all depends of your needs. For example, sometimes, we use a ezp4 install for various sites / clients. So we have more control over updates, etc. But there are some problems, even if every client has an independent database all sites have the same extensions installed and other issues...

Regards

eZ Partner in Madrid (Spain)
Web: http://www.atela.net/

Huseyin Bilgen

Tuesday 15 April 2008 2:44:05 am

Hi Piotrek & Andreas,

Thanx for your valuable comments.
What I require is a community which have sub-communities. For example site about computer, and sub-sites about notebook, pc, software, hardware,...

So, what I want is to use different theme for each sub-sites but using same portal sw

- Central User Management

is important, because don't want everyone to register to all sub-sites. Just one centralized registration. For this let me ask, which path to walk?

Tony Wood

Tuesday 15 April 2008 9:00:48 am

That is a really good question Huseyin,

If you go for the siteaccess model, you get the ease off adding additional siteaccess and a single codebase for your central eZ Publish core. This can work very well when the siteaccess projects have similar roadmaps and will not be spinning off into bespoke functionality. However, it does mean if you patch eZ Publish then you need to regression test *every* environment, this turns even the smallest patch into a large job.

If however as mentioned above your siteaccess are likely to need bespoke elements such as registration, login or shop functions, then it is safer to use their own eZ Publish environment. This gives you the freedom to change and customise each environment as you see fit.

As you can see it really depends on the long term direction of the environments you are creating.

Now you say that you want a single signon, well in the past this would have meant you would need to use the siteaccess approach. However thanks to the openID folks you can have your cake an eat it too now that eZ Publish has OpenID (in 4.5 fingers crossed)

Hope this helps you..

T

Tony Wood : twitter.com/tonywood
Vision with Technology
Experts in eZ Publish consulting & development

Power to the Editor!

Free eZ Training : http://www.VisionWT.com/training
eZ Future Podcast : http://www.VisionWT.com/eZ-Future

Powered by eZ Publish™ CMS Open Source Web Content Management. Copyright © 1999-2014 eZ Systems AS (except where otherwise noted). All rights reserved.