Why Migrate to Sites?
Tuesday, August 23rd, 2011 at 4:00pm -- Charlie Holder
Although Cascade Server 6.x has been out for over a year now, we still get questions about migrating to Sites. Since the list of advantages to using Sites grows with each release, we wanted to share some reasons why we think Sites are the way to go.
Targets were Confusing
Before Cascade Server 5.0, Targets were used to organize content and define a "website." Targets were both a relational and functional entity that defined the scope of a "site." The scope began with a selected folder and included all of the assets beneath it. During the content development process, a Target was to be chosen for every Template that was created. And as a limitation, each Template could only be used by one "site." With the Sites model, the idea of a Base Folder that stores a Site's content is a much more logical asset than a generic folder asset. And by having an asset in the CMS that is specifically designed for tracking what Site an object belongs to, you are able to freely share more assets, like Templates, across different Sites without needing to create multiple copies.
Administration Area Asset Organization
Depending on the size of your deployment, the lists of Asset Factories, Configuration Sets, Metadata Sets, Data Definitions, Content Types, etc. might be a bit lengthy. Couple this with systems that are not using Content Types at all and your System Administrators could have a wealth of assets to wade through every time they log in. Sites afford you the ability to create certain assets inside of each Site when they don't apply to any other. Because Administration Area assets can be shared across Sites, you won't need to worry about duplicating every asset in every Site either.
Site-specific Publish Queue
With the release of Cascade Server 6.8, publishing was greatly improved -- the Publish Queue concurrently process two jobs per Site now. This means that each Site is able to publish two jobs at a time and the system as a whole can process jobs from multiple Sites at the same time.
Individual Recycle Bins
As a temporary holding area for deleted assets, the Recycle Bin helps prevent the loss of content. All Home Area assets (Pages, Files, Folders, Blocks, Formats, Templates, and Links) are sent to the Recycle Bin before being permanently deleted. The real benefit comes when you couple this with a user's abilities within the system. These abilities dictate which assets they can see in a particular Recycle Bin and even which Recycle Bin a user can interact with in general. Users only interact with content they manage and content in other Sites remains safe from accidental changes by unknowing parties.
Faster Database Queries
The application arguably performs better when you make queries to the database using "site Ids" instead of having to query across all data in the database. Quick and easy.
Site Roles
Users can have elevated permissions in one Site and more restricted permissions in another Site. This concept is much, MUCH harder to reproduce in the Global Area. Take the ability to "Modify the Content Type of pages" as an example. If a User has this ability, they have it for all assets in the Global Area, whether they work with each "site" or not. In Sites, you determine what Roles you want available on that specific Site and then choose which Groups inherit those abilities. Users now "Modify the Content Type of pages" only in Sites to which the Groups they belong to are assigned.
Simpler Access Rights
Sites offer another level of granularity as to how you would like to manage the Users within each Site. They are great for decentralized environments where you may have different people managing different areas and groups of users. Each Site's available Role and Group assignments are separate and customizable. Furthermore, assigning access to content through Groups and changing end-level user account access is faster and more easily managed.
Cross-Site Linking
Cascade Server provides users with a number of different ways to manage links in content. Managed links are tracked within the system so that one is updated automatically when the linked-to asset moves or changes names. In Cascade 6.2, it is possible to create links in content to assets existing on different Sites. This is particularly useful when linking between pages on different Sites or when linking to centrally managed support assets like CSS and Javascript files.
This becomes impossible when you begin to publish assets that exist within the Global Area to different Destinations. Content that is contained within a Site has an extra element associated with it for tracking what Site the asset belongs to. This element is used in conjunction with publish information for each asset to allow Cascade Server to manage the links regardless of what server or domain the content is pushed to.
In addition to being able to link to assets that are maintained in different Sites, it is now possible to link to a specific Page Configuration, even if that Page asset is published to a different Destination. The Web URL field grants you the ability to cross-link assets that are published to different domain names while still managing those assets within one Site.
Connectors
This is an example of a Site-centric feature that is not available in the Global Area. Connectors are simply a means by which to (pardon the pun) "connect" third-party applications and tools with a Cascade Server instance. They allow users to take advantage of other applications, like WordPress, Facebook and Twitter, for pushing content that is managed within the system to external locations.
As you can see from this short list, migrating content into Sites provides a variety of benefits to the system itself and to the users. I would love to talk more in depth, about any of these points as well as points I may not have listed here, to anyone that wants to continue the discussion.
Category
- Resources
- Commentary