Configuring multisites

Created by: Lester Caine, Last modification: 17 Jul 2008 (14:06 UTC)
There are various legacy pages relating to multisite, but no easy 'How To' guide to help set you up.
Just to keep things tidy in the process the following pages could probably be removed but are retained for historic information at present -
((Multisite (Teamsite) Configuration)) (OK that will not link but it's old anyway) and brainstorming multisite support.

Web server configuration

Following the notes on the admin page for multisites I established that I had to set up separate virtual hosts for each domain extension I am going to use. Not too difficult for a few separate sites, but this could be difficult if many are involved.
For various reasons I've got both windows and linux web servers running and to add to the fun, the SUSE and Mandriva linux servers have somewhat different methods of handling Apache setup. Since the remote server is running SUSE linux and has all of the DNS management, that is where I am currently setting things up, and actually it is a lot less problematic there.
The setup has Apache2 installed (installation and configuration notes will follow at some point), and configuration for this uses /etc/apache2 as its location for configuration. Virtual hosts are already configured in this setup ( unlike Mandriva where I will need to do a bit more work tidying up ) and there is a sub directory /vhost.d which has .conf files for each virtual host. There are templates for normal and ssl hosts, but at present I only have the normal access working. Having created and tested an vhost.enquirysolve.co.uk.conf file, all I had to do is duplicate the file as vhost.cust.enquirysolve.co.uk.conf and change the ServerName line to include the cust. information.
( Remember to restart apache to pick up any new files - /etc/init.d/apache2 restart for SUSE )
This will allow us to create a set of target sites that can be used by multisites.

bitweaver configuration

The multisites admin has two pages. The settings panel allows you to configure 'Per Site' content and add a separate tab to edit pages to allow setting these. This is currently conflicting with protector which is designed to provide the same service, and is duplicating code. The separate tab option simply shows the server list on a separate tab on the edit pages, while the alternative is to include it in the services area of the page. It would currently seem sensible to disable 'Restrict to sites' if protector is being used as well. See notes below on the diferences possible with either setup.
There is an option to display 'Number of members' but I have not established yet WHAT this relates to.
The second page - Edit Sites - allows the identification of the sites configured in apache to be added and accessed. There are three tabs, the first of which displays a list of the configured sites and has links to allow data to be edited or an entry deleted. Simply create a new site by adding it's ServerName details and follow up with a description of that site. Save Settings will create the entry, but it is worth looking at the other two tabs to change the site title, and search details for this 'virtual' site, along with the home page and theme to use.
Having now got things set up, for a simple setup, the trick is how to handle the situation before someone logs in. This has been achieved by creating a home page for the target site which must be available to be displayed by anonymous users. However this highlights the problem with restricting access to content. While we can restrict content to a particular virtual site, and can manually set the permissions on every content item, this becomes somewhat difficult to manage, so protector may well still be required to fill the gap.
There is a bug in how home page data is inserted into bit_index by the multisites admin page. There can be an incorrect path if packages are called directly.

To be investigated

The problem with using custom permissions to manage finer access details is that they have to be set for every item individually, and currently this is not available when adding content as a user on a particular virtual site. Currently protector allows new content to be restricted to a particular group, if required, so new content can be flagged as 'freely available', 'available to registered users' or available to the 'group' backing up the virtual site. Each site has their own group configured, and content can be flagged to one of the groups available to a particular users. ( Even the administrator can be blocked from access to particularly private content ). The question is whether the restrict to sites is required if protector is enabled. There is probably no need to have both but restrict to site may be required in some other places. One of the facilities provided via protector is that content loaded to a gallery will use the same access level as the gallery itself, while restrict to site needs to be set manually for each item.
While the Restrict to sites tab appears on user edits, there is no button to activate the selection. Similarly, protector is not available, so other than manually updating the database there is no way to restrict visibility of users in lists.

Integration questions

One of the areas I'm still a little unhappy with is groups, but not those provided by the groups package which provides yet another way of managing grouped content. The thing that seems to be missing at present is the filtering of structure content to be visible to the group that it is assigned to. The listing of all possible galleries and the like in other packages needs a little work, so that only galleries accessible by a particular group of users are displayed. Not sure yet if multisites correctly handles this area. I have not reviewed yet how treasury handles this area, but one thing that is obvious is that lower level content should not be identified to groups that it's higher level links are disabled from accessing.

Related Items

Documentation » Tutorials

Tutorials to help you work out how something in bitweaver is done

  •    •    •    •    •    •    •    •    •    •    •    •    •    •    •    •    •    •    •    •    •    •    •    •    •    •    •    •    •  Array  •  Array  •  Array