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.