Large communities sometimes need to be sub-divided. Multi-forum management provides solutions to better manage large forums.
Vanilla’s cloud solution offers a number of configuration settings for enterprise-grade deployments.
Single Community
This is a classic forum setup. It is the equivalent of 1 installation of forum software. It can have any number of categories arranged in a hierarchy.
Each Single Community needs a domain or subdomain assigned.
Hub & Node
The Vanilla Hub is intended for cases where dozens or hundreds of separate self-contained communities are required. New instances of Vanilla can be spawned within seconds through the Admin Dashboard or via the API.
This type of implementation allows you to set up one community as a template, then create Nodes that are copies of this setup.
For most purposes, each Node is a Single Community with the added ability of being synced with changes made on the Hub. Each Node is otherwise independent - separate user lists, private message exchanges, and activity streams
Read more about Hub and Node:
You can read more about Hub and Node custom domains here.
Read more about the Hub Sync here.
Subcommunities
A subcommunity artificially divides a Single Community or a Node into different areas by making each of the top level categories into subcommunities.
Subcommunities are particularly useful for creating a sub-community for a language or product line. Unlike categories, Sub-Communities can have their own home page, locale and announcement messages. Members can easily navigate from one Sub-Community to another without losing their reputation points and Ranks.
Each subcommunity (and its' top level category) must have a unique URL path prefix. For example, an English language subcommunity will have the the URL prefix of /en/. So the english subcommunity of forums.example.com would be available at forums.example.com/en.
While in a subcommunity, categories and discussions will be filtered to that subsection of a forum. Category Lists, and the Recent Discussions page will be filtered to only show content from that subcommunity.
All subcommunities are still part of a single “instance” - the user list (and therefore moderators / admins), private messages, and activity stream are shared across all subcommunities. For a more detailed list of what is and is not shared across subcommunities see the Shared Content list in our Subcommunities document.
A common way of combining this feature with the Hub is to create a Node per product, and use subcommunities for each locale within that product.
See main subcommunities article.
Architectural considerations
Cluster management
Our physical server assets are arranged into clusters. Each cluster can hold many Single Communities, or a single Hub + its Nodes. They cannot be mixed.
Scaling capabilities
Because each Node is a separate entity, there are significant scaling advantages to choosing a hub setup over a single community + subcommunities setup.
Member Authentication
Another consideration is how to setup forum member registration and login. Here are the three use cases we typically see:
- Members authenticate via single-sign-on (SSO) to any of the forums
- Members authenticate via SSO only to some of the forums
- Members authenticate manually using Vanilla’s login page or with social logins
In most of our multi-forum implementations, authentication occurs via single-sign-on where members are already authenticated to your website or application and are able to access Vanilla seamlessly.
If SSO is not required, members will register and sign in to each community using Vanilla’s registration or a social login such Facebook Connect of Microsoft ID. If you are not using SSO, subcommunities may be a better option for you if users need to sign in to multiple sites with 1 set of credentials.