[title sub="Written by Chris Graham (ocProducts)"]Composr Tutorial: Tools for subsites and subcommunities[/title]

Composr is designed to be able to support large websites, and a common features of the largest sites is to have subsites and/or subcommunities within the larger website. There are a number of features in Composr to support this, including:
 - [b]Zones[/b] (different zones may be created for each subsite, located under a URL beneath the main site, with their own set of pages)
 - [b]Redirects[/b] (using redirects, common modules, such as the download module, may be made to appear as if they are running from individual zones)
 - [b]Categories, and virtual roots[/b] (using a combination of separate categories [and sub-branches there-of] for different subsites, and the 'virtual root' system, it can be made to appear that each subsite has their own catalogue/download/gallery)
 - [b]Comcode pages, Chatrooms, Polls[/b] (all these support individual creating and referencing, such that different instances can be presented to different subcommunities)
 - [b]Banners, Calendar[/b] (all these support category based referencing such that a division between subcommunity interests can be created)
 - [b]Sub-forums[/b] (different communities can be given their own branch of the discussion forums, with the [concept]Conversr[/concept] 'Clubs' feature providing special support for this)
 - [b]Themes[/b] (different themes may be applied to different zones, giving subsites individual looks)
 - [b]Usergroups and access privileges[/b] (members of subcommunities may be grouped by usergroup, and permissions assigned accordingly)
 - [b]Custom profile fields[/b] [[concept]Conversr[/concept] users only] (custom profile fields can be made so that they only apply to a single usergroup: thus allowing specification of user data that applies only to specific subcommunities)
 - [i]More advanced techniques discussed in the [page="_SEARCH:tut_msn"]Advanced techniques for multi-site-networks tutorial[/page][/i]

[contents]decimal,lower-alpha[/contents]

[title="2"]Usergroup management[/title]

[media width="150" description="Managing a usergroup" float="right"]data_custom/images/docs/tut_subcom/usergroup.png[/media]
The [concept]Conversr[/concept] system has a powerful usergroup system.

{!cns:DOC_GROUPS}

Usergroup(s) is commonly abbreviated to group(s).

[title="3"]Ranks[/title]

Members will automatically enter usergroups on their rank ladder as they accumulate points. Specifically, the total points ever earned, as point spending does not impede raising through the ranks.

Their visible rank, and privileges change in accordance to their new rank usergroups.

Rank ladders are not formally codified. A member can be considered on a rank ladder if they are on a usergroup with any particular promotion path. Members may be on multiple ladders by being in multiple promotable usergroups. Usually a site will only have on rank ladder though.

There is a default rank ladder that goes:
Newbie --> Regular --> Local --> Old timer --> Local hero

It is recommended that you leave all non-staff members such that their primary usergroup stays within this rank ladder, and use secondary usergroups for the purpose of placing them in subcommunities, and granting additional permissions (a member has the 'best' permission combination out of all the permissions granted to all of their usergroups). This keeps things consistent, allowing these members to have both your main rank and other usergroup memberships.

You can attach your choice of rank image to any usergroup. A default set of images is supplied for the default rank ladder.

The Setup Wizard has an option to remove the default rank ladder and have a simple 'Members' usergroup instead.
All this does is rename Newbie, change the promotion target setting on Newbie to N/A, and delete Regular/Local/Old timer/Local hero.

[title="3"]New member status[/title]

When members join they are placed, by default, in the 'Newbie' or 'Members' usergroup.

Conversr allows you to choose which secondary usergroups a member is placed in when they join.

Setting of default usergroups allows you to give people permission "by default", but to take it away if they abuse it without having to put them onto a different rank ladder. For example, a 'debates' forum could be created and only the 'Civil Debater' usergroup given access; the 'Civil Debater' usergroup could be a default usergroup, meaning all have access by default -- however, members who demonstrated an inability to debate in a civil manner could be removed from it.

It is also possible to give members a choice from a number of primary usergroups when they join. This is especially useful for what I call 'role-based communities', where different members use the website in such a way that is distinct to their role on it. By assigning usergroup according to role, it is possible to use various Composr features in order to customise the site for each role provided.

You'll find all these options on the add/edit usergroup form.

[title="3"]Back-end[/title]

Manage usergroups from Admin Zone > Security > Usergroups.
You can delete a usergroup from the bottom of its edit form -- except you cannot delete certain default usergroups that are used for system functions or as fail-safes.

There is also a module for putting members into usergroups temporarily:
Admin Zone > Security > Temporary usergroup memberships

[title="3"]Front-end, and leadership[/title]

[surround]
[media width="150" description="Adding a new usergroup" float="right"]data_custom/images/docs/tut_subcom/usergroup_add.png[/media]
[media width="150" description="The usergroup directory" float="right"]data_custom/images/docs/tut_subcom/usergroup_directory.png[/media]
Usergroups can be browsed via the Usergroup Directory, which is part of the [tt]groups[/tt] module ([tt]site:groups[/tt] page-link, Social > Usergroups on the default menus). The usergroup directory lists all non-hidden usergroups in a clear and tidy way.

You may opt to assign a leader to usergroups, or to leave them leaderless. A usergroup leader has the ability to control who is in their usergroup (secondary membership only &dagger;), and edit the basic usergroup settings -- taking pressure away from the staff. Otherwise, only members with the "Control usergroups that member is not leader of" privilege may add users to usergroups -- unless the usergroup involved is a super-administrative usergroup, in which case only a super-administrator may do this (to avoid the potential for privilege escalation).

When a member views a usergroup they have the following possible interactions:
 - [i]If they are not already a member:[/i]
  - [i]If "Open membership") has been enabled:[/i]
   - Join as secondary
  - [i]Otherwise:[/i]
   - Apply to join as secondary (become a prospective member)
 - [i]Otherwise:[/i]
  - [i]If they are a secondary member:[/i]
   - Leave
 - [i]If they have usergroup leadership access:[/i]
  - Add members as secondary
  - Remove secondary members
  - Accept prospective members
  - Decline prospective members

When a usergroup application is made a notification is dispatched to the leader of the usergroup, or to the staff if there is no leader.

&dagger; Only members with the "Assume the identity/access of any other member" privilege may control a member's primary usergroup selection, done by editing their account.

[title="3"]Clubs[/title]

The [concept]Conversr[/concept] system provides a clubs feature (Content Management > Clubs). Clubs are a feature written around usergroups. Clubs:
 - can not have special permissions (they are not shown in permission editing interfaces)
 - may be joined and left like ordinary usergroups (via secondary usergroup membership)
 - come with their own forum with the same name as the club (privileges to this are automatically assigned when the club and forum are created and cannot be revoked through the Composr permission editing interfaces)
 - may be added by ordinary members, depending on how you have configured permissions
Clubs are provided so that members may create their own subcommunities on the website. They are not given any special permissions so as to not overcomplicate the regular permission configuration process (as potentially you might have hundreds or even thousands of clubs).

The club forum has default permissions that only allow website staff and club members into it. The club functionality provides no special moderation controls -- so by default the forum would need to be moderated by the website staff, rather than self-moderated. As it is a regular forum, additional permission changes can be achieved manually (for example, creating a new usergroup for the club's management and assigning moderator permissions over the forum to members of that).

The parent forum and forum grouping for new club forums is configurable.

You can only add a club from the Clubs module. However, once added it can be edited as a usergroup by website staff and converted to a normal usergroup by removing the special "Private club" setting you see when editing it (this is a one-way operation and removes any special club behaviour).
[/surround]

[title="2"]Zones[/title]

[surround]
[media width="150" description="To finalise the zone, FTP details may be needed so Composr can create the directory structure properly -- depending on server architecture" float="right"]data_custom/images/docs/tut_subcom/subcom_zone_afm.png[/media]
[media width="150" description="Adding a new zone for our Church Of Santa subcommunity" float="right"]data_custom/images/docs/tut_subcom/subcom_zone_add.png[/media]
An introduction to zones is covered in the [page="_SEARCH:tut_structure"]Composr site structure tutorial[/page].

You may add new zones, edit zones, delete zones, and move pages between zones from:
Admin Zone > Structure > Zones.
You can delete a zone from the bottom of its edit form.

When performing an action that will add, rename or delete a zone, you may need to provide details that tell Composr how it can do this; this is because on the some webhosting configurations, PHP does not have full access to files on the hosting account (lack of suEXEC). These details are the same as you provided when using the Composr quick installer (assuming you used this to install).

[title="3"]Zone logos (advanced)[/title]

To change the logo image for a zone, add a theme image named [tt]<zone-name>-logo[/tt]. By default zones use the logo image of the Welcome Zone.
[/surround]

[title="2"]Multi-Site-Networks (advanced)[/title]

For some sites, it is advantageous to be able to create a whole website for each subcommunity, each with its own settings, yet sharing a single member database and forums. This is possible using a Composr configuration known as a 'multi-site-network' and essentially involves separate Composr installs that are tied together by sharing a forum database. Composr provides special features for multi-site-network sites, and there is separate tutorial on them: as they involve separate installs, most of the features described in this tutorial are not necessary.

Advantages to using a multi-site network:
 - Full control
 - Cleaner administrative separation
 - Special multi-site-network features, such as the 'netlink' system

Disadvantages to using a multi-site network:
 - Overhead of additional configuration and maintenance

[title="2"]Virtual roots[/title]

[surround]
[media width="150" description="The virtualised download category" float="right"]data_custom/images/docs/tut_subcom/subcom_virtualised.png[/media]
[media width="150" description="Viewing the download category we added, we can find the virtualisation URL" float="right"]data_custom/images/docs/tut_subcom/subcom_cat_view.png[/media]
[media width="150" description="Adding a download category for the NewTown Parish subcommunity" float="right"]data_custom/images/docs/tut_subcom/subcom_cat_add.png[/media]
A number of Composr modules contain categories organised into a tree structure, including:
 - galleries
 - download categories
 - catalogue categories

If subcommunity categories are stored under a common sub-tree of the full category tree, then the root of the 'sub-tree' may be made into the apparent root of the full-tree, by picking it as a virtual-root. This is easy to do, and doesn't involve any kind of configuration other than finding the URL to enter the module with. To find this URL you just look for the link of the current category in the breadcrumbs on a category screen (it'll have something similar to [tt]keep_root[/tt] in it): this is a mouthful to explain, but really very simple. Once you have the URL, you may wish to add it to to the menu of your subcommunities zone.

Here are some step-by-step instructions:
1) Browse into the forum you'd like to be the virtual root. You need to be logged in as a staff member when you do this
2) Look at the breadcrumbs. You should see the final (rightmost) link in the chain is also a link. This might appear strange, because you're already on the page so why would a link be shown? The reason is that it is an anchor to let you create a virtual root link
3) Click the link
4) You should see now you have set a virtual root
5) Take the URL you're at and put it on your menus as required
[/surround]

[title="2"]Redirects[/title]

[surround]
[media width="150" description="Managing redirects" float="right"]data_custom/images/docs/tut_subcom/subcom_redirects.png[/media]
{!redirects:DOC_REDIRECTS}

Redirections are useful for a number of reasons, including:
 - Sharing modules between zones
 - Making short-cuts to zone/page combinations
 - Making it so obvious URL mistakes can be automatically corrected
 - When moving pages, a redirect may be placed so that links are not broken

To reach the Redirects module go to Admin Zone > Structure > Redirects.

The source page codenames of redirects are case-insensitive. This aligns with the basic sanity check that you shouldn't have pages with names that are the same except for case.

[title="3"]Using redirects to virtually move a module (rename a module)[/title]

If you want a module to behave as if it was completely moved, you can set up a transparent redirect from your desired location to the actual location, and then a non-transparent redirect from the actual location to the desired location.

Composr will sense your intent, so when you do something that searches for that module (e.g. for the Wiki+ module, doing a Wiki+ link) it will go to where you want.

[title="3"]Example: Changing your front page to a module in another zone[/title]

[media width="150" description="Adding our redirect" float="right"]data_custom/images/docs/tut_subcom/redirect_forum_simple_example.png[/media]
Let's say you want to redirect website visitors who go to your site straight to the "Forums" zone.

A normal redirect can be written from the "Welcome" zone [tt]start[/tt] page, to the "Forums" zone [tt]forumview[/tt] page as follows...

1) Go to Admin Zone > Structure > Redirects
2) Scroll towards the bottom of the page to find the "New Redirect" section
3) Create our new redirect as "Welcome:[tt]start[/tt] --> Forums:[tt]forumview[/tt]" (leave transparent unticked/unchecked)
4) Press the "Save" button

Now let's test if our new redirect works...

Go back to your home page. If you entered all the details correctly you should now see that you are immediately redirected to the "Forums" page instead of the "Home" page. Look closely at the URL in your browser's address bar, you should see this [tt]forumview[/tt] in there. This tells you the redirect took you to where you expected. There is a visible URL change as this was a normal redirect rather than a transparent redirect.

Now let's try the same for a transparent redirect and see the results. To make our redirect transparent we need to go back to edit the redirects and tick (check) the "Trs." field. Go do that and press the "Save" button.

When you visit the home page you are redirected to the Forums page just like earlier with the normal redirect, but take a look at the URL now: it doesn't reveal that the [tt]forumview[/tt] page was called. The redirect happened within Composr, not your web browser.

[title="3"]Example: Moving a module (renaming a module)[/title]

If you wanted to move the [tt]supermembers[/tt] module from the Collaboration Zone to the Site zone (with a new module name), you could set up these redirects:
1) [tt]site:super[/tt]-->[tt]collaboration:supermembers[/tt] [i]transparent[/i]
2) [tt]collaboration:supermembers[/tt]-->[tt]site:super[/tt] [i]non-transparent[/i]
Composr will see the transparent redirect as an indication the [tt]supermembers[/tt] module really has a proper home in the [tt]site[/tt] zone under the name [tt]super[/tt], and it will see the non-transparent redirect as an indication the [tt]supermembers[/tt] module really does not have a proper home in the collaboration zone; Composr will respect these indications and consistently link to the module in its new home.

Note that while almost all front-end modules support moving, not all modules support renaming because it may break references between different parts of Composr (including within the module itself in some cases).
[/surround]

[title="3"]Example: Moving multiple modules[/title]

[media width="150" description="Our redirects" float="right"]data_custom/images/docs/tut_subcom/redirect_forum_complex_example.png[/media]
Some users may prefer to have the forums run directly from the Welcome zone, rather than a separate Forums zone. This example is just like the "moving a module" example except it redirects 3 modules rather than only 1.

We can make the forum modules available in the welcome zone by setting up these transparent redirects...

[tt]:forumview[/tt] --> [tt]forum:forumview[/tt] [i]transparent[/i]
[tt]:topicview[/tt] --> [tt]forum:topicview[/tt] [i]transparent[/i]
[tt]:topics[/tt] --> [tt]forum:topics[/tt] [i]transparent[/i]

And then we set up non-transparent redirects in the opposite direction to [b]force[/b] links to the forum to open up in the welcome zone...

[tt]forum:forumview[/tt] --> [tt]:forumview[/tt] [i]non-transparent[/i]
[tt]forum:topicview[/tt] --> [tt]:topicview[/tt] [i]non-transparent[/i]
[tt]forum:topics[/tt] --> [tt]:topics[/tt] [i]non-transparent[/i]

Tada, all the forum modules are moved.

[title="3"]Example: Making a module run in multiple zones (advanced)[/title]

Let's imagine you want separate download databases in separate zones. In this example we'll have a separate database in a [tt]staff[/tt] zone using a series of tricks.

If you want to follow this example you'll need to create the [tt]staff[/tt] zone first.

Our first trick is to add our redirect:
[tt]staff:downloads[/tt] --> [tt]site:downloads[/tt] [i]transparent[/i]

Now we have the [tt]downloads[/tt] module running from the [tt]staff[/tt] zone. However, it shares the same downloads. The next trick to solve this is to deep link to the base category for our zone (from our menu link, or whatever navigation we are going to use for our zone). Let's imagine you have a download category called "Staff files" with ID#5, and want this as the root category in your staff zone -- so you'd link to that.

Obviously the above is not much of a trick because it allows users to then navigate up via the breadcrumbs. Fortunately we have another trick to adjust the breadcrumbs...

You need to edit the breadcrumbs XML file (documented in the [page="_SEARCH:tut_structure"]Composr site structure tutorial[/page]) through "Admin Zone > Structure > Breadcrumb Overrides" so that [tt]site:downloads:browse:5[/tt] maps straight back to the [tt]staff[/tt] zone front page. Do this by adding in a new substitution rule:
[code="XML"]
<substitution match_key="site:downloads:browse:5">
	<link label="Staff">staff:</link>
</substitution>
[/code]

And there we go :)!

An alternative to using the breadcrumbs XML file would have been to use virtual roots. Composr is packed with power-tools you can use!

[concepts
 1_key="Virtual root"       1_value="Virtual roots allow you to split a Composr tree based content system (such as the download system) so it appears to have multiple databases"
 2_key="Redirection page"   2_value="Allows pages to be redirected to from different zone/page combinations, either transparently, or with a redirection message"
 3_key="Club"               3_value="A special usergroup with no permissions that comes with its own forum"
]Concepts[/concepts]

[title="2"]See also[/title]

 - [page="_SEARCH:tut_msn"]Advanced techniques for multi-site-networks[/page]
 - [page="_SEARCH:tut_structure"]Composr site structure[/page]

{$SET,tutorial_tags,redirects_editor,cns_clubs,Structure and navigation,regular}{$SET,tutorial_add_date,Aug 2008}{$SET,tutorial_summary,A common features of the largest community sites is to have subcommunities within the larger community. See how.}[block]main_tutorial_rating[/block]
