Deleting or Renaming the Home Item

When beginning a new project, developers sometimes delete the /sitecore/content/Home item in the spirit of "starting from scratch." While this impulse makes sense, it should be avoided in the case of the Home item. Sitecore uses the Home item for system-related features and configuration changes are required if the Home item is deleted or renamed: http://sdn5.sitecore.net/Articles/Administration/Configuring%20Multiple%20Sites/Adding%20New%20Site/Internal%20Links/Case%201.aspx

If you would like to rename your Home item, an easier solution may be to simply change its Display Name. To do this, click on the Home item, then select Display Name in the Rename chunk.

Hiding and Protecting Items

If business users are logging in to the Content Editor, confusion may ensue. Sitecore provides the “Hide Item” and “Protect Item” features to reduce confusion and prevent accidental errors.

Hiding items prevents items from appearing in the content tree (if “Hidden Items” is unchecked in the View chunk). To hide an item (or an entire branch), click on the item, then click “Hide Item” in the Attributes chunk on the Configure tab. Note that only users in the Sitecore Client Configuring role can access this functionality.


Once an item is hidden, it can be unhidden using the following steps:

• Check “Hidden Items” in the View chunk.
• Click on the hidden item in the content tree.
• Click “Make Item Visible” in the attributes chunk.

Protecting items prevents anyone from modifying a content item (unless they first unprotect it). The intention of protecting items is to prevent the accidental deletion of system functionality. Imagine, for example, the possibility of accidentally deleting the /sitecore/system section of the content tree. This would cause major problems for Sitecore’s functioning and should be avoided at all costs. To reduce the chances of this kind of error, many Sitecore nodes are protected by default. Protected nodes cannot be modified – even by Administrators – without first being unprotected.

When navigating to a protected item, users will be alerted:


Administrators or users belonging to Sitecore Client Configuring may unprotect items by clicking “Unprotect Item” in the Attributes chunk:

Using Security to Simplify the User Experience

In general, Sitecore recommends that business users and power users access WebEdit mode to the greatest degree possible. For a variety of reasons, however, this may not always be possible. Administrators, for example, may prefer sorting from within the Content Editor rather than in WebEdit mode. Additionally, content authors may need to edit content items for which no content markers have been created (such as look-up values, for example).

In these cases it may be worthwhile to use security permissions to limit what appears in the content tree (see also “Hiding and Protecting Items,” the subject of a future blog posting). One way to accomplish this is to deny read access to branches of the content tree for particular users. In a multi-site scenario, this may mean denying read permissions to Site A for the content authors of Site B. The end result would be that when a Site B author logs in to the Content Editor, they do not see Site A at all. This may reduce confusion and clutter in the content tree for the content author.

The weakness of this approach is that content items for which a user does not have read access do not appear in the rich text editor when a user is creating a Sitecore link. In other words, a user cannot create a managed link to a content item for which the user does not have read permissions. This applies to lookup, multilist, tree, treelist and checklist fields as well.

Formatting the Content Tree

Any item in the content tree may have special formatting applied to it. The most common example of this is to bold the root item for a site:



You may apply a variety of possible CSS styles to content items to affect their appearance in the content tree. For example:



To configure the appearance of a content item, click on the content item and select Tree Node Style in the Appearance chunk. Sitecore will present a form that allows you to enter any number of CSS styles (separated by a semicolon):



While this feature can be useful, its overuse may cause confusion for business users.

Display Names

Display names provide an alternate name for content items when they are rendered in the Content Editor or the item editor (in WebEdit mode). In the following example, Home has a display name of “Sitecore.net”:

There are a number of scenarios where this feature may be useful. Sometimes, the name of a content item is insufficiently descriptive for developer- or business-user ease-of-use. For example, the standard Sitecore installation comes with an item called “Home.” To enhance the user interface experience, you may want to rename the Home item to something else. It is easy to rename an item; however, if you have already created dependencies on the Home item, renaming may cause problems if performed late in a project. (See also “Deleting or Renaming the Home Item,” the subject of a future blog post.)

In other situations, you may want to create an item with an illegal character (such as an exclamation mark). While the item name must not include illegal characters (as this would interfere with the processing of http requests), the Display Name can include characters that are not allowed in item names.

To set the display name for a content item, navigate to the item in the Content Editor and click the Display Name command in the Rename chunk:

Massive Branches

For medium- to large- sites, customers may have large amounts of content based on the same template. For example, a news site may have hundreds of thousands of news stories or a product site may have tens of thousands of products. From a performance perspective, Sitecore will have no problem handling this volume of content; however, the organization of the content will impact system performance (see here for more information: http://sdn5.sitecore.net/Articles/Administration/Sitecore%20Performance/Storage/Deep%20vs%20Shallow%20Trees.aspx). Additionally, the business user or developer experience may suffer in certain circumstances. Consider the following:

I. Home
  a. News
    i. News Story 1
    ii. News Story 2
    iii. …
    iv. News Story 130,001
    v. News Story 130,002
    vi. …

Expanding the News node in the Content Editor would cause serious performance issues from a user-interface perspective. Sitecore would attempt to return the content structure for 100,000+ content items and the web browser may be pushed to its limits in terms of memory usage or CPU. Further, if the News item were used as the datasource for a multilist or lookup control, business users would face a difficult challenge locating content items from a list of this size.

To address this issue, some kind of organizational structure is required. Items may be organized by:

• Year, month and date
• Author
• Alphabet (i.e. an “A” folder, a “B” folder, etc.)
• Category and subcategory

Whatever organizational approach you choose, select one that will scale as content volume increases. The above content tree, for example, could be organized as follows:

I. Home
  a. News
    i. 2007
      1. 1
        a. 1
          i) News Story 1
          ii) News Story 2
        b. 2
          i) News Story 1

In this example, news stories are organized by year, month and date. The strength of this approach is that it provides a comprehensible hierarchy that easily scales over time. The challenge of this approach is that WebEdit mode will require customizations in order to add new News Stories. When a business user adds a News Story, programmatic logic will be required to ensure that the news story is created in the appropriate folder or subfolder.

Sometimes no obvious organization scheme presents itself. In these cases, an arbitrary content structure may be required to ensure that the content tree remains usable. For example:

I. Home
  a. News
    i. Folder 1
      1. News Stories 1-50
        i) News Story 1
        ii) …
      2. News Stories 51-100
        i) News Story 51
      3. …
      4. New Stories 2,451-2,500
    ii. Folder 2
      1. News Stories 2,501-2,550
      2. …

This approach provides an organizational structure for otherwise hard-to-structure content and ensures that no single branch of the content tree will overwhelm the user interface. The weakness of this approach is that the non-semantic nature of the folders and subfolders may weaken search engine optimization strategies that rely on URL paths for content categorization. It will also be difficult to locate items within the Sitecore UI itself without using the built-in search tool.

Finally, remember that this issue should only be of concern to developers and power users from a user interface perspective. Business users working with WebEdit mode will never use the Content Editor and, as such, will never be exposed to the content tree per se. If you are considering allowing business users to access the Content Editor, remember the potential confusion this may cause as the content tree becomes more complex.

Search Engine Optimization

Search engine optimization is a critical aspect of site design. While its complexity far exceeds the scope of this blog, it is worth mentioning as it regards the design of the content tree.

Two rules of thumb are useful here: 1) Search engines attribute semantic weight to content hierarchy and 2) Shallow structures may be more optimal than deep structures.

Addressing point 1), a search engine will treat /Products/Shirts/Men/Knit.aspx as more semantically rich than /Foo/Foo/Foo.aspx. Each level in the hierarchy is considered significant when interpreting the meaning and categorization of the link. Fortunately, Sitecore is designed to facilitate this kind of content organization; Sitecore’s “friendly-URLs” allow for search-engine friendly paths.

Regarding point 2), content in shallow branches may be deemed more significant than content in deeper branches. For example /Products/Shirts.aspx may be considered more relevant to a site than /Products/Shirts/Men/Knit.aspx. Most of the time, the need for content organization may trump this consideration. However, addressing categorization through metadata may be an alternative to expressing categorization through hierarchy.

Wildcard Nodes

There may be scenarios where you want to create “catch-all” nodes in your content tree, i.e. if the request doesn’t find a match, apply some default processing. In Sitecore, these are referred to as “wildcard” nodes. To create a wildcard node, add a content item named “*”:
I. Home
  a. Products
    i. *
    ii. Product A

When a request comes in for /Products/Product A.aspx, Sitecore will find the /sitecore/content/Home/Products/Product A content item. If a request comes in for /Products/Product B.aspx, Sitecore will find the /sitecore/content/Home/Products/* content item.

Wildcards may also be nested, for example:
I. Home
  a. Products
    i. *
      1. *
    ii. Product A

In this case, a request for /Products/Product B/Attribute 1.aspx will be a match for the /sitecore/content/Home/Products/*/* item in the content tree.There are varied uses of this feature. The following article describes how to use this feature to embed query string values in URLs: http://larsnielsen.blogspirit.com/archive/2007/01/09/sitecore-avoiding-query-string-in-dynamic-url.html.

Aliases and Marketing URLs

Sitecore supports the concept of an alias, a short URL that can provides an alternate and easier way to navigate to a content item deep in the content tree. For information about configuring aliases, see here: http://sdn5.sitecore.net/Articles/Administration/Aliases.aspx.

Aliases impact the content tree in that they implicitly create items in the content tree. For example, a business user can create an alias /Product A.aspx that points to an item deep in the content tree, such as /Products/Category A/Subcategory A/Product A.aspx. Implicitly, a new node under the root of the site has been created. Business users should be careful to avoid explicitly creating content items that duplicate aliases, as unexpected behavior will occur.

There are at least a few limitations to aliases: 1) aliases must always end in “.aspx” and, as such, may not be usable for marketing purposes and 2) aliases can only be children of the site root – the UI for adding aliases prevents users from creating deeper aliases, such as /Featured Products/Products.aspx. The greatest utility of aliases may be for email marketing, where lengthy urls in plain-text messages may be truncated by email programs.

Marketing URLs are a more flexible form of aliases. See here for more information: (http://sdn5.sitecore.net/Scrapbook/Friendlier%20Marketing%20URLs.aspx). Marketing URLs are handled by URL rewriting tools such as ISAPI_Rewrite. Marketing URLs do not need to end in .aspx and can be as deep as you like. Marketing URLs can be mapped to their proper Sitecore friendly url. Other solutions for marketing URLs also exist (such as including logic in your 404 page) and are beyond the scope of this document. The point in mentioning marketing URLs is to provide potentially more useful alternative to aliases that will generally not complicate the administration of your content tree.

Including Data from External Sources and Legacy Applications

Data Providers
Sitecore abstracts its data access using a data provider model. In brief, a data provider is like an interface that – if implemented fully – allows Sitecore to “plug in” to any database or other content repository. Due to the complexity of implementing a complete data provider, it is a strongly discouraged practice. There are almost always preferable alternatives which vary depending on whether your primary requirement centers on presentation, data entry or both.

We discuss the topic briefly here as developers may find occasion to implement simple, read-only data providers and because some Sitecore modules (such as the Sitecore Sharepoint Module) may leverage this architecture. In any case, data providers are rendered in the content tree and warrant mention here for that reason alone. Considerations around how to design a data provider, i.e. represent relational data hierarchically, is considered outside of scope for this document.

Data from data providers can be viewed by switching databases using the database chooser located in the lower right-hand corner of the Sitecore taskbar. Clicking on the database icon allows developers to view any of the seven standard Sitecore databases as well as any additional data providers that have been defined for the Sitecore instance. Opening the content editor will represent the data from the data provider in a familiar hierarchical view.

To represent this data within the master database, developers typically create proxy items. See the discussion above on proxy items and reference items for more information.

Legacy Applications
Another approach to integrating external data into Sitecore is relying on legacy applications that may have presentation components. Often, it is desirable for these components to be served from the same web root. In other words, /Products.aspx and /Profiles.aspx may co-exist under the same web root; however, Products.aspx is served by Sitecore while Profiles.aspx is handled by a legacy application. The standard solution for this requirement is to configure the IgnoreUrlPrefixes setting in the web.config. IgnoreUrlPrefixes allows developers to indicate that requests for certain files or directories should be ignored by Sitecore’s processors.

While this doesn’t explicitly affect the design of the content tree, it implicitly does. Any path specified in IgnoreUrlPrefixes will never be a valid Sitecore path (unless the value for the setting is changed); in other words, the system will never try to resolve the item to an actual content item. Content editors will need to be aware of these excluded paths or file names to ensure they do not create content items with identical names.