Lots of Websites, One eZ Publish Installation - Adding Siteaccesses in eZ Publish

Shared Content Classes

In this example we've used the same database and var directory for both public sites. Though the content is in separate subtrees, the content classes they use are shared. Be careful not to change attributes in a class to suit one site if they're needed by the other site. If this might become a problem, you could use a separate database and var directory—or more simply, each site could use different content class groups.

Content Sharing

Copying an object or subtree is of course a simple way of getting content into a second subtree (website) when the database is shared by two sites, but then changes to one copy will not appear on the other. In the same scenario, you can easily share content by using secondary/additional locations. That's an easy way of sharing content, but it must be done for each individual object (the children of the shared object do not automatically get shared as well). A workflow (“after publishing”) could be used to publish all articles in one subtree in another subtree (on the second site) as well. Another way to pull content from one database to another would be using an RSS feed.

Security

It is more secure to use separate databases and var directories for separate sites. It may be best to always use separate databases and var directories unless the siteaccesses need access to some of the same content or users in an easy way. If you do have a database and var directory for each public siteaccess, each public siteaccess will need a corresponding admin siteaccess.

User and access control management

A Single Sign On (SSO) capability is sometimes required, letting a visitor log in with one single set of access credentials on a series of websites. This can be easily achieved when the content is shared between siteaccesses (one subtree per site), for the users (stored as other content objects) are natively shared. When the content base is not shared, dedicated SSO solutions, such as LDAP or Active Directory, must be used. eZ Publish natively supports LDAP as an SSO system, and its architecture can make use of any SSO-plugin. The latter take the form of an extension, and can interface eZ Publish with basically any SSO system. More on SSO extensions here : http://share.ez.no/articles/ez-publish/using-a-sso-in-ez-publish.

Concerning access control, user roles can be applied with subtree limitations, and we now know each website can be a subtree. In our example, care would need to be given to ensure the node 2 is not tampered with, and that the name of the landing page nodes is not changed without an appropriate configuration file change. This can be assured by changing user roles and policies in the administration interface. Having roles applied with subtree limitations eases access control administration. This generic benefit makes a whole lot of sense in our example : the few user profiles are identified, across the two public sites we built, then materialized as roles. Typically, a logged-in user on both site 1 and site 2 can read content from the standard section, the media library, and create & edit blog posts. However, they should not be able to read or edit content from the other website (ie: form the other subtree). To satisfy this :

• One single role is crafted, containing the handful of policies described above
• Two user groups are created : “Editors site one” and “Editors site two”, self explanatory.
• The role is applied to both user groups, with subtree limitation on their respective website's subtree.