Using Agility CMS for Multiple Sites

James Vidler

August 18, 2020 19:58

With Agility CMSs flexibility, we make it easy to architect a content model that can be used to power multiple websites.

There are different approaches to take, each with their own benefits so we recommend reviewing these options to see what is the best fit for your case.

Approaches to Managing Content for Multiple Sites

Channels

Channels are unique sitemaps that you can manage within Agility CMS.

Each site can have different pages but utilize the same underlying architecture such as page templates, modules, and content definitions. They are designed to support multi-tenancy where each site has its own unique domain.

Page Folders

Page folders are ways to organize a set of pages within one of your Channels.

This allows you to create folders in your sitemap to represent each site you have. This model works great for microsites when all your pages can live on a single domain.

Languages/Locales

While not designed for this purpose, you can utilize an additional Language locale to represent a new site.

This works well for when you have pages that will be identical in layout across all your sites. Simply initialize the content in the other language and you can pull that into your website.

Separate Instances

An instance represents your Agility CMS project.

You can create as many instances as you'd like. They are designed to be used for distinct properties where content and your models cannot be accessed or shared across instances. Instances have their own list of users that are granted access to them, making it easy to manage security across teams.

Access vs Permissions

An Agility CMS instance grants access to users. This is managed by admins. If a user has access to an instance, further permissions may be applied to that user so that they either can or cannot modify specific content lists, pages, or groups of pages.

It's important to note that users that have access to an instance can see all content and pages listed in the CMS, but depending on their permissions may not have access to view or edit them. If you need to separate different teams from seeing each other's content, consider using separate instances.

	Channels	Page Folders	Languages/Locales	Separate Instances
Site Creation	Add a new Channel, its pages, and initialize its content	Create a new Page folder in your Channel, its pages, and initialize its content	Create a new language, then initialize the pages and content for that language	Create a new instance, create definitions, initialize pages and content
Flexible Sitemaps per Site	Yes	Yes	No	Yes
Shared Content grouped by Site	Yes	Yes	No	No - each instance has its own list of Shared Content
Security Applied per Site	Yes - via user permissions	Yes - via user permissions	No	Yes - via user access per instance
Shares same Website Deployment/Host	Yes	Yes	Yes	No - must be a separate web app
Shares same Page/Module/Content Definitions	Yes	Yes	Yes	No
Reference global or site-specific content across sites	Yes	Yes	Custom - logic must be written to pull from specific languages	Custom - can only be accessed using the Content Fetch API
Content API is Secured by Site	No - the API is able to query all content	No - the API is able to query all content	No - the API is able to query all content	Yes - each site has its own API permissions
Domain Mapping to Site	Yes - each channel is mapped to its own list of domains	Custom - logic needed to rewrite paths without the site folder name	Custom	Yes
Dedicated Preview for each Site	Yes - each site has its own Preview URL	Custom - logic needed to redirect a preview URL to the appropriate site domain and rewrite path	Yes	Yes
URL Redirections	Yes	Custom - logic required to handle rewritten paths without the site folder name	Yes	Yes
Supports Editor URL Page Picker	Yes	Custom - logic needed on the site to rewrite URLs used by editors to exclude the folder path	Yes	Yes
Licensing Impact	Yes - Channels can be added to subscriptions for $100	N/A	N/A	Yes - Requires a new subscription plan per instance