Sites vs Subsites Pros and Cons

Sites vs. Subsites – Pros and Cons

An introduction to this fundamental design issue was given in the Sites and Subsites Overview section, above. Here the topic is discussed more fully.

CommonSpot is flexible enough to allow two distinct architectures for building sites. In most cases, a single top-level site with multiple child subsites will produce the proper architecture to successfully maintain content within a site. However, in some circumstances it may be necessary (and more beneficial) to produce multiple top-level sites. Listed below are some pros and cons to top-level sites and multiple subsites.

Advantages of a Multi-Site Environment

Base Template Design - In general, separate sites simplify base template design and more easily separate look and feel approaches. A large, single site with multiple subsites that contain varying designs may create a complex base template, requiring extensive ColdFusion logic to allow for separate designs. Having separate sites may avoid this problem. This is especially advantageous if the separate sites do not share any common design elements. In general the more similar the sites, the more advantageous it may be to use subsites. However, with proper structuring of templates built using shared ColdFusion code, it is possible to implement shared template structures across sites.

Search Collections Management - In a multi-site environment, search collections are kept completely separate, making collection management easier. Typically, the more content you have, the more you may need to create multiple collections, to avoid large collections that can lead to performance problems. Re-indexing is handled more smoothly from smaller collections.

Domain Branding - In an environment where multiple domains will be used, Web server management complexities can be avoided in a multi-site environment. Multiple sites will make Web server management much less complex when applying unique URLs to each site. CommonSpot sites are expected to have separate URLs while subsites are not.

Less Overhead per Site - A single large site can create authoring-side performance issues in the situation where templates are being changed often. With content separated into separate sites, some authoring performance issues caused by larger sites are avoided. Page and Element caches will not have to be cleared as often or on as large a scale.

Separate User Datasources - Where desired, separate user datasources can be set up for separate sites using hosting customer keys. This allows separate management of users and groups.

Sites Can Be Easily Separated - For large content, high load environments, multiple sites can be split between multiple servers, thereby sharing the workload. Subsites of a single site will all need to reside on the same server. While this may not be an issue in initial implementations, it allows for more scalability down the road.

Sites Can Have Different Configurations - Site-wide configurations, Elements, etc. can be kept separate from site to site. This means that sites can have separate metadata definitions, custom render handlers, separate Custom Elements, RTE settings, etc.

Self-Contained Replication - CommonSpot replication is done on a site level. A replication can exclude subsites, but is designed to replicate an entire site and not single, individual subsites. Multiple sites allow for more granular and targeted replication.

Disadvantages of a Multi-Site Environment

No Content Sharing - One of the major downfalls of a multi-site environment is that content and Elements cannot be shared from site to site. This will mean that content authored on one site cannot be reused on another site without custom coding. CommonSpot currently provides no facilities to reuse content from one site to another. Future versions plan to support syndication of content through XML consumption and publication.

No Element Definition or Template Sharing - CommonSpot does not currently support sharing the definition of any Custom Element or any template layouts (outside of base-templates or custom CF code) across sites. As such, you will need to recreate these in each site. PaperThin plans to support importing and exporting of Custom Element definitions in a future release.

Multi-Point Authoring Environment - With multiple CommonSpot sites, a multi-point authoring environment is created. Shared content must be created and managed on each site. In addition, all site templates will have to be managed separately.

No Task Aggregation - With a multi-site set-up, a user who is tasked with managing content in multiple sites will have to log in to each site to see and act on any Pending Actions (Work in Progress, Approvals, Content Expiration, Broken Links, etc.). Other authoring tools, like work requests, My Pages, and usage statistics will not share from site to site. However, users will receive notification emails for many of these tasks.

Web Server and Database Management - With more sites, and thus more corresponding databases, the task of creating and managing the Web server and databases is expanded. The availability and expertise of your resources, as well as your IT operating procedures will dictate whether this is a significant cost.

Advantages of a Single Site with Subsites Environment

Content Sharing - Content and Elements can be shared. Sharable content in a subsite environment, that cannot be shared in a multi-site environment, includes

Custom Elements and the reuse of their content

Images

Templates

Subsite properties and security settings

Keywords and other configurations

Uploaded documents

Registered external pages

Search collections

Subsite Creation - Because administrator permissions can be managed on a subsite-by-subsite basis, root-level administrator rights are not necessary for new subsite creation. This means that should a new ‘site’ be necessary, its creation would be far simpler as a subsite than the creation of a full site.

Single-Point Authoring Environment - Managing shared content is much more efficient. Uploaded documents need only be uploaded once; Custom Elements and their content can be created once and shared around the site. Templates are created or edited once, in one location. Site design changes, re-branding of logos, etc., can all be accomplished through one base template. Reporting tools, such as Pending Actions, encompass all of the content for a contributor or administrator in a single view.

Disadvantages of a Single Site with Subsites Environment

Complexity of Design - In an environment where multiple subsites require multiple designs, base template design can be complex. Logic must exist in the base template that includes the proper design Elements for the proper subsites. This is not a large disadvantage for slight changes in design, but grows as the variance in design grows.

Large Full-Text Indexes (Collections)- With a single site, full-text indexes can grow excessively large very easily and cause performance problems in both content publication and searching. Verity collection management requires more attention, to prevent performance issues. Collections may need to be separated by subsite and optimized regularly.

Performance Overhead - Large sites with heavy Custom Element or page index usages may suffer from authoring and read performance issues. This is because during the publication process, the cache is cleared for these Elements, slowing authoring and read mode performance until the cache is rebuilt. Alternative configurations of the site’s caching may need to be tried. In addition, any changes to the site’s templates, even if only for the benefit one of the subsites, may clear the cache for the all sites and cause temporary performance hits.

Larger Replication Overhead - A large single site can create more overhead during the replication processes, as the process will have more directories to scan, more page records to check, and more images to manage. This may cause author-mode performance delays and longer replication times.

Domain Branding - Supporting multiple domains under a single site/multi-subsite environment has significant shortcomings:

You will not be able to generate static pages using CommonSpot’s Static Content Generation facility, as this facility produces pages with fully qualified URLs, and as such, only one domain can be supported.

Under a ‘normal’ non-static generated site, links rendered by CommonSpot are server relative. Thus, the domain under which the user enters the site will be the domain used throughout their visit to any subsite. Any bookmarking, etc., will use that domain. Domain switching based on subsite is achievable, but would require custom coding and a browser redirect. Also, the URL is made more complicated as each URL must include the appropriate subsite directory to differentiate the site.

Related Links

You can download PDF versions of the Content Contributor's, Administrator's, and Elements Reference documents from the support section of paperthin.com (requires login).

The following guides are available locally on your CommonSpot Server:

You can also download these other guides from the support section of paperthin.com (with login):

For technical support:

http://www.paperthin.com/support/