One Installation, Multiple Sites

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.

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.

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/

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