Proxy Items and Reference Items

Proxy items in Sitecore are, loosely speaking, pointers to source content items located elsewhere in the content tree. Editing a proxy item updates the source item and vice-versa. To create a proxy item, consult the documentation provided on the SDN (http://sdn5.sitecore.net/Articles/Administration/Using%20Proxy%20Items%20in%205,-d-,3/What%20is%20a%20Proxy%20Item.aspx). Note that using proxy items may have performance impacts and the documentation should be consulted closely before using this approach. Additionally, requirements should be carefully analyzed and prototyped to ensure that proxy items provide a complete solution.

Developers sometimes envision proxy items as a solution for content sharing:

I. Sitecore
  a. Content
    i. Site A
      1. Content Item A
    ii. Site B
      1. Proxy of Content Item A

While this may initially appear to be an ideal solution, at least one major problem presents itself – proxy items cannot have unique presentation settings. In other words, the proxied content item will use the same presentation settings (i.e. layout, sublayouts and renderings) as are applied to the source content item. In this case, even though the proxied item is in Site B, it will be rendered in the same manner as the source item in Site A. While it may be possible to work around this – for example by implementing a pipeline processor – this approach may become complex quickly, particularly if you deploy many proxy items.

The most common use of proxy items is for lookup values that do not require presentation settings and may, in fact, be located in different databases. Consider, for example, a requirement that business users be able to associate a content item (perhaps a site or a major branch of a site) with particular users or roles. This metadata may be used to drive email notifications within workflow actions. The Security database (containing user and role information for content authors) may be proxied to a global folder in the main content tree. For example:

I. Content
  a. Global
    i. Users
      1. User A
      2. User B
  b. Home
    i. Content Item A

Content Item A may have a multilist field whose source is /sitecore/content/Global/Users.

Another instance of using proxy items is in proxying data sourced from an external data provider. The Sitecore Sharepoint Module uses this approach. Sitecore allows Sharepoint document libraries or lists to appear as proxy items in the Media Library or elsewhere in the content tree.

"Reference items" are a simpler, but in some ways more complete, approach to referencing other content items. A reference item is an item whose template has at least one field that references another content item. Consider the following template design:

Product
Title	Text
Description	Rich Text
Reference Item	Reference

The reference field type provides a tree control that allows users to choose any item in the content tree to which they have read access.

The advantages to using reference items are at least two fold: 1) Presentation settings can be placed on reference items completely independently of the item referenced and 2) Fields in the reference item can – through presentation logic – implicitly override the same fields in the source item. Some disadvantages to using reference items are: 1) Presentation logic becomes more complicated, 2) The concept of referencing other content items may be confusing to business users and 3) Dependencies are created between content items. Presentation logic will be required to handle unforeseen scenarios (such as the deletion of the source item). When using this approach, consider pre-populating the reference fields in template standard values to simplify the configuration for business users.

Multiple Sites

In Sitecore, a "site" is just another content item in the content tree. Using configuration settings in the web.config, you can associate a <site> with, for example, a hostName (i.e. mysite.com), a startItem (i.e. /sitecore/content/mysite) and many other settings which are described in the web.config. Configuring multi-site solutions is described on the Sitecore Developer Network (SDN) (http://sdn5.sitecore.net/Articles/Administration/Configuring%20Multiple%20Sites.aspx). Sitecore also provides a user interface for configuring multi-site solutions that may be appropriate for certain environments (http://sdn5.sitecore.net/SDN5/Resources/Shared%20Source/Modules/Multiple%20Sites%20Manager.aspx).

A representative content tree may look like this:
1. Sitecore
  a. Content
    i. Site A
    ii. Site B
    iii. Site n

When managing large numbers of sites with a single instance of Sitecore, consider creating an organizational structure for your sites. This is discussed in greater detail in the "Massive Branches" section of this blog.

It exceeds the scope of this posting to fully discuss the benefits and pitfalls of managing multiple sites with a single instance of Sitecore. Suffice it to say that there are many important considerations to take into account. Most of these considerations do not affect the organization of the content tree and, as such, are not discussed herein. The reader is encouraged to consult the SDN or an experienced solution partner prior to implementing a multi-site solution.

A common requirement in creating multi-site solutions is to share content between sites. There are several approaches to this requirement:

1. Reference global items.
2. Copy items.
3. Use proxy items or reference items.

In the first approach, referencing global items, create a global folder at the same level as your sites:

1. Sitecore
  a. Content
    i. Global Content
    ii. Site A
    iii. Site B
    iv. Site n

Under the Global Content item, include all of the items that are used across sites. Examples may include a privacy policy, legal notices, a mission statement, or an entire branch of content that will be mirrored in your other sites. The advantage to this approach is content reuse – i.e. global content can be updated in one location and changes will be reflected on all sites that reference the content.

In the second approach, items are copied from one site (or from the Global Content folder) to another site. The advantages here are simplicity and transparency – the global content items are essentially starting points or stub items that take on a life of their own once copied. The primary disadvantage is the loss of content reuse. An additional disadvantage is that a power user will most likely be required to copy a branch from the source to the target location, an operation outside of the scope of typical business user activities.

The third approach, using proxy items or reference items, will discussed in my next blog entry.

Master Hierarchies

The topic of creating master hierarchies (i.e. default subitems) is covered at length in the Sitecore Certified Developer 1 training and in the Sitecore Developer Cookbook: http://sdn5.sitecore.net/Developer/Developers%20Cookbook.aspx.

Master hierarchies allow business users to create entire branches of a content tree through the same process used to create a normal content item. Consider a case where product descriptions are divided into four logical subjects, displayed on separate (or the same) web pages:

I. Home
  a. Products
    i. Product A
      1. Product Features
      2. Detailed Specifications
      3. Pricing Information
      4. Order Information

Rather than having business users manually create four sub-items for every new product, developers should create master hierarchies to automatically create the child items as well as the Product itself.

There are some system-related limitations to organizing masters (under /sitecore/masters). Specifically, developers cannot organize masters into subfolders. For example, ideally your masters could be organized thus:

I. Sitecore
  a. Masters
    i. Site A
      1. Master A
      2. Master B
    ii. Site B
      1. Master A
      2. Master B

Unfortunately, this arrangement is unsupported. The reason for this is that Sitecore uses the structure of the masters themselves to determine master hierarchies. In the structure above, Sitecore assumes that Site A is a master hierarchy with child masters Master A and Master B. Sitecore will not interpret Site A and Site B as organizing items (even if, for example, they are based on the Folder template). A possible approach to organizing masters, then, may be to rely on naming conventions, such as:

I. Sitecore
  a. Masters
    i. SiteA_MasterA
    ii. SiteA_MasterB
    iii. SiteB_MasterA
    iv. SiteB_MasterB

A shortcoming – and potentially a major one – of this approach is that it produces masters with non-business-user-friendly names. In other words, when business users right-click on a content marker, they will see the site prefix on each master. This may cause confusion and require additional training. A workaround for this is to change the display name of the master and that name -- rather than the actual name of the master -- will be displayed in the UI.

Keep in mind that read permissions can be placed on masters so that users only see masters in the UI that are relevant for their content creation purposes.

Publishing Considerations

Publishing Considerations
As of Sitecore 5.3.1, the system does not have an out-of-the-box approach for publishing dependent items. Consider the following content structure:

I. Home
  a. Promotions
    i. Promotion A
II. Global
  a. Legal
    i. Legal Notice A
    ii. Legal Notice B

Imagine that every promotion has a multilist field (with a source of /sitecore/content/Global/Legal) wherein a business user can choose which Legal Notices should be applied to a Promotion. This will work fine in WebEdit mode. When the promotion is published (for example, through a workflow action), there is no guarantee that all of the required legal notices will also get published. If a business user has associated Promotion A with Legal Notice B, both of these items will need to get published in order to present all of the required Legal Notices for the Promotion. This will happen without additional effort if the site is published using an incremental publish (assuming the Legal Notice is in a final workflow state).

If you are using the AutoPublish workflow action, you can organize your content tree to address these dependent items:

I. Home
  a. Promotions
    i. Promotion A
      1. Legal Notice A
      2. Legal Notice B

When you use the AutoPublish action, Promotion A and all of its children will get published (again, assuming that the Legal Notices are in final workflow states or not part of a workflow). Note that the AutoPublish action requires the “deep=1” parameter in order to publish child items.

This solution will not be appropriate for many requirements. For example, if Legal Notices are reused across Promotions, it does not make sense to have them be child items of individual Promotions (as this defeats content reuse). Also, if Legal Notices go through a workflow process independent of promotions, there is no guarantee that the Legal Notices will get published when the Promotion gets published.

To address publishing dependencies, you may need to rely on a scheduled task or a more complex workflow action to publish rather than using out-of-the-box workflow-based publishing.

Administering Security

Ideally, security should be administered on as few content items as possible. For ease of administration, developers should endeavor to apply security to high-level items and use inheritance to determine security for child items. It is optimal if you can administer security on just a few content items in a site with thousands of total items.

This is preferred to setting security on individual content items on an ad hoc basis. In an ad hoc scenario, large-scale changes to security permissions are impossible without scripting or manual updates.

This suggests several possible configurations for your site. In the following example, the content tree is designed for ease of extranet administration:

I. Home
  a. Products
  b. About Us
  c. Secure
    i. Secure Content Item A
    ii. Secure Content Item B

Here, all content that requires extranet login is stored under the Secure node. Administration of the site for extranet users is reduced to editing security settings on a single node, i.e. Secure.

Adding Sitecore security (i.e. for content authors and editors) may complicate things. Imagine, for example, that there are multiple categories of secure items which are edited by different roles. In this case, your content tree should be optimized for both Extranet and Sitecore domain administration:

I. Home
  a. Products
  b. About Us
  c. Secure
    i. Secure Category A
      1. Secure Content Item A
    ii. Secure Category B
      1. Secure Content Item A

In this example, extranet security is still administered on the “Secure” node, while Sitecore security is administered on the “Secure Category A” and “Secure Category B” nodes.

Consider the following additional complication: you may encounter requirements that a parent item and its children have different security requirements. Imagine in the following example that one set of permissions applies to the Products landing page and another set of permissions apply to the products themselves:

I. Home
  a. Products
    i. Product A
    ii. Product B

We can imagine that the Product Manager role is allowed to edit product descriptions themselves, but the Marketing role is allowed to edit the Products landing page. If the products are all set to inherit their permissions, they will effectively be inheriting the Marketing permissions. This can be remedied by setting permissions on each individual Product, in the Product master or in the template standard values. The most flexible solution among the three is to set the security settings on the template standard values. This prevents security settings from being placed on individual content items, which poses the greatest administrative challenge.

Another option is to create an additional sub-item, perhaps based on the Folder template:

I. Home
  a. Product Landing
    i. Products [folder]
      1. Product A
      2. Product B

Security in this case can be administered on the Products item, with separate security permissions placed on the Product Landing item.

In some cases, it becomes difficult to follow this security administration model. For example, imagine a scenario with four possible roles, any combination of which could be applied to a single content item. Specific security permissions may be entirely driven by editorial decisions. In these cases you may need to resort to masters, templates or security presets to manage entirely ad hoc security permissions.

Metadata Child Items

In order to achieve flexibility in the design of your site, you may store metadata items as children of a primary content item. End users typically navigate only to primary content items, while the child metadata items may drive the presentation of the content or other aspects of the end-user experience.

Consider a requirement for business users to add any number of sidebar items to a web page. For purposes of simplicity, imagine that a sidebar item contains two fields: a title, and a link (i.e. a field that points to another Sitecore item). To address this requirement, your content tree may look something like this:

I. Article A
  a. Sidebar Item 1
  b. Sidebar Item n
II. Article B
  a. Sidebar Item 1
  b. Sidebar Item n
III. …

If business users can edit both a left and a right sidebar, your content tree may appear thus:

I. Article A
  a. Left Sidebar
    i. Sidebar Item 1
    ii. Sidebar Item n
  b. Right Sidebar
    i. Sidebar Item 1
    ii. Sidebar Item n

The benefit of this approach is that business users can add unlimited amounts of metadata (in this case, metadata that drives presentation logic) to each content item. The weaknesses of this approach are at least three-fold:

1. The Content Editor becomes increasingly complex and, as such, may be confusing to users who access it.
2. Non-technical business users will require more training to understand how to use content markers in WebEdit mode. In the example above, each web page will have several content markers, i.e. one for the content item itself and one for each of the sidebars.
3. Sorting becomes complicated. Business users can sort the sidebar items up and down using the sort commands in the item editor; but WebEdit mode lacks a Content Editor-style visualization of the sorting. This is not unique to the metadata child items scenario, but may decrease usability in an already usability-challenged implementation.

Even given these limitations, there are times where using metadata child items is the best possible solution.

Media Library and Layout Organization

In general, the same considerations apply to Media Library or Layout items as apply to any other content item. The goal in either of these cases is to organize items in a way that makes sense to business users (in the case of the Media Library) or developers (in the case of Layout items). Media items are sometimes organized based on the type of asset (i.e. image, word document, pdf, etc.) or an asset’s classification (i.e. product images, home page images, navigation images, etc.).

Keep in mind the ability to set the source attribute of an image field. The source attribute describes where in the media library business users will start browsing when they populate an image field. Organizing your media library to facilitate business user navigation of the media library will enhance the usability of the system.

While Media Library items are typically organized based on business user usability concerns, the organization of layouts, sublayouts and renderings is driven by developer considerations (in addition to the other considerations described in this document). Developers may organize code assets by site, local vs. global or by a logical ordering. When organizing presentation objects, remember that files and metadata are managed separately (i.e. on the file system vs. as Sitecore items). The organization of the files and Sitecore items typically mirror each other, but do not have to.

Note that layouts, sublayouts and renderings may be stored in virtual directories (virtual applications are not supported) to facilitate code management and source control.

Multiple Fields, Child Items or Global Items?

Certain content types may have repeating fields. For example, on your public website, every product may be displayed with three accessories. One way to address this requirement is to include fields in your template for each of your accessories. Imagine a template with the following structure:

Product
Title	Text
Description	Rich Text
Accessory One	Rich Text
Accessory Two	Rich Text
Accessory Three	Rich Text

The advantage of using this kind of template structure is that business users will find it easy to enter content. Clicking on a single content marker will allow them to update both the product and its accessories. Ease-of-use should not be underestimated as a benefit to this approach.

There are at least two shortcomings of the approach: 1) If the number of accessories varies per product, business users will need to enter the accessory information in the appropriate fields and ignore unused fields. If the number of accessories for products increases beyond three, the template will need to be modified to add an “Accessory Four” field. 2) The reusability of the data is limited. If two products reference the same accessory, the accessory description will have to be entered twice (i.e., once for each product).

One solution would be to create a structure of products and child accessories. Consider, for example, the following solution:

I. Products
  a. Product One
    i. Accessory A
    ii. Accessory B
    iii. Accessory C
  b. Product Two
    i. Accessory A
II. …

The content is structured to allow n accessories per product. Some products may have one accessory, while others may have ten. When business users create new products, the product master will be configured to create the appropriate number of subitems.

There are several weaknesses to this approach: 1) More work will be required of business users to edit the accessories, i.e. there will be one content marker for the product and additional content markers for each accessory. 2) Deleting a product necessarily deletes its accessories, which may or may not be desirable. 3) While the solution allows the business user to create any number of accessories, the content structure is not easily reusable. In particular, if a requirement exists to render a list of all accessories, your code would need to traverse the products section of the site, looking for content items that are based on the Accessory template. In simple circumstances this may not cause problems. If accessories are distributed throughout the site, however, this query would need to traverse all possible nodes where accessories may be descendants. This would introduce some complexity and possibly impact performance.

Yet another approach would be to list all accessories in a global area and reference those in the Product template. In this case, the product template may look like this:

Product
Title	Text
Description	Rich Text
Accessories	Multilist /sitecore/content/home/accessories

Business users will create new products and then select the appropriate accessories from the multilist control. The strength of this approach is that the accessories are easily-reusable content and the business user experience is straightforward.

The weakness of this approach is that it assumes that accessories are pre-entered under /sitecore/content/home/accessories. In other words, if an accessory doesn’t exist yet, there is no way to select it in the multilist control. For business users to create or edit accessories, they will run into similar difficulties as in the child-items scenario (i.e. more clicks to create both a product and its accessories). If accessories themselves are treated in the same way as other products, this may not be a serious issue, i.e. accessories must be created as products regardless of whether they are related to an already-existing product. In any case, items must be created before dependent relationships can be asserted. This can complicate the business user experience but may be addressable through training.

Defining Taxonomies and Look-Ups

Every Sitecore implementation will require content branches that define content taxonomies and/or look-up values. Often, these branches will be placed in a Global folder at the same level as your Home item. Within the Global folder, your metadata values can be organized based on existing taxonomies or structured to facilitate the use of look-up controls (i.e. lookup, multilist, tree, etc.). For example:

I. Home
  a. Products
  b. About Us
II. Global
  a. Market Segments
    i. Age
      1. 18-25
      2. 26-30
    ii. Frequency
      1. This month
      2. Past 6 months
  b. Taxonomy
    i. …

Why put the Global folder at the same level as your Home item? The idea here is that end users (i.e. public visitors to your website) will never navigate to the Global items. The items in the Global folder will typically not have presentation settings and will sometimes be based on very simple templates. The values in the Global folder can be accessed within the UI (for example, as a data source for a lookup control) or within your presentation logic.
This approach works for many scenarios where developers need to create a data source for lookup fields. Sometimes, however, you may want users to navigate to content items that also serve as metadata sources. Consider the following:

I. Home
  a. Products
    i. Summer 2007
      1. Product A
    ii. Fall 2007
  b. …
II. Global
  a. Market Segments
    i. Age
      1. …

A content item based on the Product template may have an Age Segment field and a Season field. The source for the Age Segment field could be /sitecore/content/Global/Market Segments/Age while the source for the Season field could be /sitecore/content/Home/Products. The product seasons are both content items that an end-user can navigate to as well as a data source for the Season field within a Product item.

Architectural Considerations: Leveraging Your Information Architecture

A common approach to designing the content tree is to mirror the information architecture (IA) of your website. For example, your site’s information architecture may look like this:

I. Home
  a. Products
    i. Shirts
      1. Men
      2. Women
    ii. Pants
      1. Men
      2. Women
  b. Account Management
  c. About Us
  d. Legal
  e. …

In this case, your information architecture includes a product catalog that organizes content first by the type of apparel (“Shirts,” “Pants”) and then by subcategory (“Men,” Women”). A first pass at developing your content tree might look exactly like your information architecture. When business users add a new men’s shirt, they will add it under /sitecore/content/Home/Products/Shirts/Men.

This is an extremely common approach to building the content hierarchy, and has at least a couple of advantages:

• Presentation elements such as breadcrumbs and navigation can be easily driven from the content structure.
• Simplicity and transparency; when the content tree and the IA are in synch, it is easy to understand the relationship between the two.

In addition to the above, this is a common approach because it leverages the work you have already done in defining the information architecture of your website. Through this approach, you are able to describe relationship through hierarchy. In other words, I know a product is a men’s shirt because it appears under Shirts > Men.

The limitations of this approach come up when the site implements a faceted navigation scheme (see http://en.wikipedia.org/wiki/Faceted_classification for more information). The consequence of faceted navigation is that individual content items may be displayed in multiple sections of the site. Consider the following information architecture:

I. Home
  a. Products
    i. Shirts
      1. Men
      2. Women
    ii. Pants
      1. Men
      2. Women
    iii. Men
      1. Shirts
      2. Pants
    iv. Women
      1. Shirts
      2. Pants

Here, a men’s shirt could appear under Home > Products > Shirts > Men or Home > Products > Men > Shirts.

Even though it will appear in multiple places on the site, we don’t want business users to have to enter the content twice in the content tree. To this end, we need to define a content tree that is structured differently from the information architecture. In this case, we will define a content hierarchy that organizes products by season.

I. Home
  a. Products
    i. Summer 2007
      1. Product 1
      2. Product 2
      3. …
    ii. Fall 2007
    iii. Winter 2007
    iv. Spring 2008

Note that the content tree now looks completely different from the information architecture. Why organize products by season? This may or may not be the correct organizational heuristic, but the point remains: developers will need to create a logical content structure of some sort in the content tree. The structure of the tree in this scenario will be largely determined by other considerations.

Even in faceted schemes, developers may take a hybrid approach. While the “Products” section of the tree may be organized independently of the IA, the rest of the content tree may more closely follow the IA. Another hybrid approach could involve a mix of the IA and the faceted classification within the products section:

I. Home
  a. Products
    i. Men
      1. Summer 2007
        a. Product 1
        b. Product 2
      2. Fall 2007
    ii. Women
      1. Summer 2007
      2. Fall 2007

There could be a number of reasons for choosing this organizational approach, such as ease of generating navigation elements, security considerations or publishing considerations. There could also be considerations here that are completely independent of Sitecore – you might choose a structure that mirrors your content taxonomy, reflects your business processes, enhances developer convenience or simply makes sense within the context of your organization.

When your content tree does not mirror your IA, your rendering logic must be more complex. But that is for a future post...

The Basics of Sitecore's Content Tree

The content tree in Sitecore provides a hierarchical view of system data. Each node in the tree is referred to as a “content item” and can contain any number of content versions in any number of languages. A typical Sitecore instance stores data in a relational database (such as SQL Server or Oracle); Sitecore represents the data in memory as an XML structure. The content tree is a visualization of that structure.

This blog describes a number of considerations involved in designing the content tree. These considerations are divided into four major categories: 1) Architectural, 2) User-Interface, 3) Presentation and 4) Development. Architectural considerations address issues that are fundamental to the structure of the content tree, i.e. determining the basic organizational framework for site content. User-interface considerations explore how the organization of the content impacts the functioning of the Sitecore business-user interfaces. Presentation considerations address how the organization of the content tree affects developers’ ability to retrieve and render data from the system. Development considerations address how the content tree structure can simplify or complicate the development process.

Typically, the design of the content tree is considered early on in the project – after your information architecture and content taxonomies have been developed, but before any C# or XSL coding occurs. The following requirement areas will ultimately inform the shape of your content tree and should be understood during the content tree design phase:

• Information architecture of your website in all its presentation formats (browser, RSS, etc.)
• Content taxonomies and business rules about their use
• Major navigation metaphors for your site (i.e. hierarchical or faceted navigation, breadcrumb, sitemap, etc.)
• Content volume upon launch and over time
• Security rules for business users and public visitors to your site
• Number of sites managed within a single Sitecore instance

You may not have complete detail on all of the above requirement areas prior to designing your content tree. The less detail you have, the more iteration will be required through the design. As with any solution architecture component, you should budget time to test your design against various requirements, known and (to the degree possible) unknown.

Prior to designing the content tree, you have begun work on your template model. Your template model describes the content types on your site and their relationships to each other. Template modeling is beyond scope for this document, but it is likely that your template model will evolve in dialogue with the design of your content tree.

To view the content tree in Sitecore, use the Content Editor application. There are two audiences for Content Editor – developers and power users. For developers, Content Editor is the primary tool used for editing and adding Sitecore content. Power users may also use Content Editor to facilitate quick editing, sorting or to make changes that aren’t available in WebEdit mode.

In general, business users and power users should be directed to WebEdit mode for all content changes. If business users or power users are using Content Editor, usability considerations will heavily come into play in the design of your content tree. These usability concerns are not discussed in this blog and instead, Sitecore recommends that business users and power users be directed to WebEdit mode.

Taxonomy and Hierarchy in Web Content Management

Welcome to my blog on taxonomy and hierarchy in web content management! The focus of this blog will be on designing the content tree in Sitecore CMS.

Why focus on designing the content hierarchy? The content tree is the backbone of your Sitecore solution and will fundamentally determine the ease-of-use, flexibility and scalability of your project. For new Sitecore developers, desigining the content tree can be a daunting task. Because best practices in the design of the content tree are project-specific, there is little general advice to be found on the Sitecore Developer Network or through other resources.

I'll try to post frequently to this blog to help navigate the waters of this critical aspect of your Sitecore project.