Table of Contents
Chapter 1
Introducing the Sitecore ASP.NET CMS
What's in This Chapter?
Reviewing web content management systems
Separating content management environments
Sitecore product and company history
Identifying Sitecore solution components
This chapter explains the purpose of a web content management system (CMS), describes the separation of CMS environments, such as test and production, and provides an overview of Sitecore — both the company and its namesake ASP.NET (Application Server Pages with the .NET Framework) CMS, as well as the history of that product. Finally, this chapter describes the components that comprise a Sitecore instance, which is an installation of the Sitecore ASP.NET CMS product.
Web content management software enables nontechnical CMS users to maintain the content driving a web solution without the need to understand its technical implementation. Sitecore uses the ASP.NET platform provided by the Internet Information Server (IIS) web server on the Microsoft Windows operating system to provide one of the most advanced and comprehensive web content management solutions and development frameworks available today.
No web content management system delivers the solution you need without some level of input, whether in the form of entering content and choosing predefined presentation components or building an entire solution. While predefined presentation components are available for the platform, Sitecore is on the latter end of this continuum, focusing on CMS developers as much as users, providing both a finished product and a development framework.
Web content management systems are typically web applications that provide browser-based user interfaces for users within an organization (CMS users) to maintain the content and often some aspects of the presentation of one or more published websites. Web content management systems typically depend upon a web server and an application server or the Common Gateway Interface (CGI — see ). Individual content management systems provide additional specific features such as authentication, authorization, locking, versioning, workflow, audit, internationalization, and localization of the content, as well as separation of work-in-progress data from the published websites.
Web content management systems typically store structured, unstructured, and binary content. Presentation components of the system format that content as markup, such as HTML, for clients such as web browsers. That markup typically contains embedded links to media and other resources in the CMS. One primary aim is to enable nontechnical subject matter experts to maintain the content of websites without having to learn technologies such as HTML or install client-side software. Additional goals typically include consistency in the presentation of the published websites, as well as reuse of content among pages and multiple managed sites, as well as formatting that content differently for various devices (different markup for browsers, mobile devices, printers, and so forth), or content reuse for any other purpose.
There are two primary types of web content management systems. In the early days when web servers and web application servers were not tightly integrated (think CGI), the first CMS tools merged content with code in some kind of generation process run in a content management environment and then published the result to a content delivery environment as files. That result could be static markup to serve without processing (which generally required a separate architecture to manage web applications as opposed to static pages) or code to process further at runtime using a web application server. More advanced solutions stored information in database records in addition to or instead of files, often using query string parameters or other URL components to identify those records.
As application servers became more common, and especially as ASP.NET merged the application server with the web server, content management systems evolved to generate output dynamically for each HTTP request. These modern systems merge content with presentation at runtime to generate each page. While publishing static files can have some benefits, the advantages of generating output at runtime become more clear as the Internet evolves further into a dynamic, integrated, social experience personalized for each visitor.
Due in part to the incredible pace of change on the web, no CMS software can possibly generate your site automatically, or even meet all of your current expectations, let alone your potential future requirements. In fact, requirements typically change between platform selection and the time the website becomes available to public visitors. A website may have a shelf life of just a few years before it begins to appear stale, and organizations frequently acquire other organizations or go through other rebranding exercises. The solution architecture must be flexible enough to support new features and visual redesign. Consider a CMS as a development platform or framework rather than a canned solution. Think of CMS implementation as an ongoing program, not a project with a fixed duration.
Content management solutions typically involve a number of technical environments. Developers often install Sitecore on their workstations, though some organizations employ a shared development environment for multiple developers. From there, code changes should go through at least an integration test environment and then additional environments such as user acceptance testing (UAT). When complete, changes arrive in the content management production environment, where CMS users update the site; and from content management production to content delivery, where visitors access the published website. Some organizations deploy changes to a staging environment before they reach content management production and content delivery.
As opposed to code changes initiated by developers, content changes often go through a separate publishing workflow process initiated by CMS users in the production content management environment.
Therefore, there are actually two production environments: production content management and production content delivery. Content delivery is the most critical environment; if that environment is down, the published website is down. If the production content management environment is down, CMS users cannot update the site.
Sitecore is a complete ASP.NET development platform and web content management system (CMS). Sitecore is the leading ASP.NET web CMS available worldwide today. Its unique open architecture, diverse capabilities, and extensibility make it the most advanced CMS on the market. Sitecore developers generally agree that they can deliver more value on their projects in less time using the Sitecore product suite than using any other system.
Sitecore is a high-performance, scalable, extensible ASP.NET web CMS that generates all output dynamically and uses the same components and system architecture for both content and application pages. Sitecore does not limit the markup you can generate or the technologies that you can use, such as XHTML (eXtensible HyperText Markup Language), HTML5, CSS Cascading Style Sheets (CSS), and Asynchronous JavaScript and XML (AJAX).
The Sitecore CMS provides at least the following array of facilities for managing complex and dynamic websites:
Sitecore keeps content and presentation separate until runtime, when it merges the two based on the context of the user (their personal profile and access rights), the request (the content item identified from the requested URL), and potentially other criteria such as the type of device that requested the page. Based on this information, the layout engine assembles a hierarchy of presentation controls, and then determines whether to execute each or retrieve output cached previously under equivalent processing conditions.
You can think of Sitecore as providing an extension to ASP.NET itself, including browser-based user interfaces, abstract data storage facilities, complete application programming interfaces (APIs), and opportunities for configuration, extension, and customization.
To log in to Sitecore, access the URL /sitecore on a Sitecore instance in one of the browsers supported by Sitecore (generally, a current version of Microsoft Internet Explorer, Google Chrome, Mozilla Firefox, or Apple Safari (see the Sitecore Installation Guide at for information about supported browsers in your version of Sitecore). For example, the URL of the login page for the instance of Sitecore that I used while writing this book is .
If you previously logged in with the Remember Me option, accessing /sitecore may not take you to the Sitecore login page, instead taking you directly into a Sitecore user interface. In this case, you can access the login page at /sitecore/login.
To select one of the Sitecore user interfaces, click Options. shows the Sitecore login page.
This book assumes that you are familiar with all three CMS user interfaces available from the Sitecore login page:
The Sitecore desktop functions like a windowing operating system, but runs in a browser. In this book, the term desktop generally refers to the Sitecore browser-based desktop unless otherwise indicated, such with the phrase Windows desktop.
Many of the instructions in this book require that you use the Content Editor. To launch the Content Editor, use a browser to access the Sitecore login screen at /sitecore. For example, if the URL of the Sitecore instance is , access . shows the Sitecore login screen.
You can use the Content Editor as a standalone application, or you can use the Content Editor within the Sitecore desktop. To choose between these approaches, click Options on the Sitecore login screen. Login options appear on the login screen as shown in .
Enter your authentication credentials. To use the Content Editor as a standalone application, double-click Content Editor. The Content Editor appears as shown in .
Alternatively, to use the Sitecore desktop, enter your authentication credentials and double-click Desktop on the Sitecore login screen. The Sitecore desktop appears as shown in .
The photograph shown in is of a lighthouse at the Danish Trekroner Fort (see ). Sitecore initially developed and continues to engineer much of the CMS in Denmark. Sitecore desktop background images distributed with the CMS are similar to the desktop background images provided with the Microsoft Windows operating system, but are intended for use within the Sitecore browser-based desktop.
Click the Sitecore button in the lower-left corner of the Sitecore desktop. The Sitecore menu appears as shown in .
Click Content Editor. The Content Editor appears within the Sitecore desktop as shown in .
From within each of the Sitecore user interfaces, and especially from within the Sitecore desktop, you can access additional Sitecore applications. These applications include the following:
I am not aware of any task that you can perform in the Media Library that you cannot accomplish by navigating to the /sitecore/media library branch in the Content Editor. Due to (arguably) better usability, some users may prefer to access the Media Library to work with media items rather than the Content Editor.
I am not aware of any task that you can perform in the Template Manager that you cannot achieve by navigating to the /sitecore/templates branch in the Content Editor. Due to (arguably) better usability, some developers may prefer to access the Template Manager to work with data templates rather than the Content Editor.
When possible, use Microsoft Visual Studio, especially with Sitecore Rocks, in favor of the Developer Center.
Additionally, specific Sitecore user interfaces often contain further embedded interfaces. For example, when you select a definition item for a data template in the Content Editor or the Template Manager, Sitecore displays the Template Builder, which is a custom editor for items based on that data template. For more information about data templates, see Chapter 2.
This book assumes that you have some familiarity with each of these user interfaces, or can quickly learn to use them with minimal instruction and no screen shots. By following the Microsoft Windows and Office UI conventions wherever possible, Sitecore user interfaces support usability through familiarity and discoverability, and provide for application configuration at both the role and user levels.
Sitecore is an ASP.NET application that uses the same architecture and APIs that you use to develop solutions with Sitecore: the Sitecore user interfaces are in fact a website managed with Sitecore. It can take some time to adjust to this concept, so to say it another way, Sitecore uses the same technologies and its own APIs to build the CMS user interfaces that you use to build solutions with Sitecore. This benefits Sitecore developers who need to customize the Sitecore user interfaces by lowering the amount of API knowledge required to achieve such objectives.
With Sitecore, URLs on the published websites often do not correspond to files under the document root or in a virtual directory on the web server, but to items (records) in a relational database that indicate what presentation components the layout engine should use to process HTTP requests that specify those items. While mapping URLs to files can have some benefits, mapping URLs to items in a data store has tremendous value in terms of content and presentation component reusability.
Because Sitecore is a development framework, you can implement an information architecture and presentation components to generate output in any way you want. Sitecore does not provide data structures or presentation components to capture and present your solution; you use Sitecore to implement these components to deliver the exact solutions needed. The platform is incredibly flexible, providing comprehensive validation and other features that you can configure and extend to meet almost any foreseeable requirements. Sitecore's robust combination of architecture, flexibility, efficiency, and, most important, usability, reduces the risk that a web solution might not reach production or achieve user adoption, and increases the project's potential return on investment (ROI).
Sitecore provides additional software such as the Digital Marketing Suite (DMS) for advanced experience management, personalization, and web analytics, as well as additional software products and services that work with its web content management system. These include an Intranet management product, the Foundry product for dynamically syndicating numerous similar websites, e-commerce products, a framework for integrating Sitecore with Microsoft SharePoint, and numerous others as described in Chapter 10.
After working together extensively on numerous technical and other projects in and out of school, six Copenhagen University graduates founded Sitecore in 2001. Sitecore focused on its ASP.NET web content management system as its core competency, building a partner channel to deliver consulting and entire solutions to its customers. Sitecore quickly capitalized on the rise of ASP.NET from the ashes of classic ASP (Application Server Pages without .NET) and the foibles of Java and missteps of several Java-based CMS platforms, outcompeting large vendors in established markets and expanding worldwide.
Even in difficult global economic conditions, Sitecore continues to announce record business performance, including an impressive number of new customers every month. Sitecore now has more than 390 employees around the world, primarily in research, development, and innovation, and more than 750 partners that function as an extension of the organization. Thousands of organizations use Sitecore to manage tens of thousands of websites, and approximately 15,000 users can access the Sitecore Developer Network (SDN — ).
When I joined Sitecore in the summer of 2004, the current distribution of Sitecore CMS was version 4.3.2.x. I would not have joined Sitecore if my research had not lead me to believe it was the best CMS available at the time, and I think Sitecore 4.x would probably still be a viable CMS for many projects.
Sitecore CMS 5.0 through 5.3 replaced the Sitecore 4 concept of layout groups with the concept of devices, replaced a simple version approval checkbox with advanced workflow capabilities, added the extranet, security, core, archive, and Recycle Bin databases, and introduced the Sitecore desktop, built with new Sitecore UI technology. Possibly most important for developers, Sitecore CMS 5 provided a consolidated API for both the CMS and the published websites, whereas Sitecore 4 had separate APIs for each. With Sitecore CMS 5, Sitecore introduced the current Sitecore Developer Network.
Sitecore CMS 6.0 introduced standard values, branch templates and command templates (all of which eliminated the need for the concept of masters used to instantiate new items in earlier Sitecore versions). Sitecore 6 improved usability and performance in the Content Editor, replaced WebEdit (with the circular content markers) with the Page Editor, and replaced a proprietary security implementation with ASP.NET membership providers. Sitecore 6 eliminated the Archive and Recycle Bin databases by implementing tables for these features in the content databases, and eliminated the Security and Extranet databases by moving security information to the core database.
Sitecore CMS 6.1 introduced the rules engine, added the Field Editor and Edit Frames, provided a foundation for the Online Marketing Suite (now the Digital Marketing System, or DMS), and introduced rendering parameters templates.
Sitecore CMS 6.2 added support for WebDAV (Web-based Distributed Authoring and Versioning) and the File Drop Area field type, introduced the Word Document field type, and provided support for public and Sitecore Client RSS feeds.
Sitecore CMS 6.3 improved Sitecore's architecture for horizontal scalability by introducing remote events, eliminating the staging module, supporting load balancing in the content management environment, and introducing support for Sitecore Azure to deploy solutions to the Microsoft Windows Azure Internet cloud.
Sitecore CMS 6.4 improved the Page Editor and its extensibility, updated the Telerik Rich Text Editor included with the CMS, introduced compatibility with and support for .NET 4.0 and ASP.NET MVC, provided clones, the notification engine, and layout deltas, and was the first version of Sitecore to support additional browsers in the Sitecore Desktop.
Sitecore 6.5 provided the foundation for the Digital Marketing System (DMS) and hence Customer Engagement Platform (CEP), which replaces Sitecore's Online Marketing Suite (OMS), its first platform supporting integrated web analytics. In addition to simple traffic measurement and other common web statistics, CEP supports efficient marketing and engagement automation, automatic visitor origin classification, as well as analysis of the value of each visit and the efficiency of paths through the website. In comparison to OMS, DMS provides improved scalability, greater performance, enhanced report readability, improved capabilities for real-time personalization, and high-level dashboards.
Sitecore is an ASP.NET application that provides a layer between the developer and the ASP.NET framework, including components such as databases.
Follow Microsoft best practices for Internet Information Services (IIS) and ASP.NET security, performance, and scalability, load testing, hardware requirements planning, and other administrative considerations.
A Sitecore installation consists of five basic components: some number of relational databases (three by default), a Microsoft Windows Internet Information Services (IIS) website, an application pool, a corresponding filesystem for the document root of that website, and a separate subdirectory for storing data files (technically, that subdirectory can exist within the document root). Most Sitecore solutions include a Visual Studio project, and I recommend that all Sitecore developers use the free Sitecore Rocks extension for Visual Studio. For instructions to install Sitecore, see Appendix B.
Each Sitecore instance depends on some number of Microsoft SQL Server or Oracle relational databases. You can install the database server on the same machine as the web server. For production, you should use one or more separate, dedicated database servers to host the Sitecore databases.
You can use the free Express versions of Microsoft SQL Server and Oracle in development, test, and potentially additional non-production environments. Because you write code against a Sitecore API layer that abstracts the underlying storage mechanism, you can even use different database vendors in different environments, unless you write code that interacts directly with the database.
The three default Sitecore databases serve the following purposes:
Each of these databases contains very similar database schemas, but the core database typically contains tables for its additional default function. You can configure Sitecore to use different databases for each function.
You can sometimes add and eliminate databases, such as by adding one or more additional publishing target databases in the content management environment or by removing the master database from a content delivery environment. If you configure multiple Sitecore instances to write to a single database, to ensure appropriate cache clearing, you must enable remote event management on both instances. For more information about eliminating databases and sharing databases between instances, see The Sitecore Scaling Guide ().
Optional modules, including the Digital Marketing Suite (DMS) and Web Forms for Marketers (WFFM), require additional relational databases. Apply enterprise backup and optimization techniques to the Sitecore databases, including rebuilding database indexes.
Sitecore requires an IIS (Internet Information Services) website with a corresponding application pool and document root to host the ASP.NET application. For more information about IIS and ASP.NET, see and , respectively.
You can use IIS to host any number of websites. IIS bindings determine which website services a request based on the hostname, port, and protocol (HTTP or HTTPS).
Technically, the root subdirectory of the website (its document root) and each subdirectory can expose an ASP.NET application, and each application can use a separate application pool. Sitecore does not support applications in subdirectories.
Sitecore can use a single IIS website to manage multiple logical websites. While IIS can manage multiple websites, including multiple instances of Sitecore with separate filesystems, each Sitecore instance can manage multiple logical websites with a common filesystem and databases.
Each IIS website can expose an ASP.NET application, which depends on an application pool. The application pool hosts an ASP.NET application, and Sitecore is an ASP.NET application. The Sitecore setup executable creates an IIS application pool for the instance. If you install Sitecore without using the setup executable, you should manually create an application pool for each new instance.
Windows uses a process to host the application pool, typically w3wp.exe but sometimes aspnet_wp.exe. A Windows user such as Network Service or an application pool identity owns the application pool process. For information about application pool identities, configuring filesystem access rights, and other aspects of the application pool, see Appendix B.
The IIS website references a document root subdirectory. By default, this subdirectory contains the Sitecore application and supporting files. Your solution files will appear in this subdirectory. The document root subdirectory contains the /web.config file that configures the ASP.NET application at that location.
As described further in this book, features including the Sitecore configuration factory support Web.config include files. Web.config include files allow you to patch the actual /web.config file. This book describes the Web.config file in relation to features that support include files, but includes a leading slash and applies a style (/web.config) when referring to the actual /web.config file itself. Web.config include files can only apply to elements within the /configuration/sitecore section.
Sitecore uses the subdirectory specified by the dataFolder variable in the Web.config file to store data files such as its license, logs, and Lucene search indexes.
Lucene () is an open-source search engine maintained by the Apache group (). For more information about Sitecore's use of Lucene, see .
Most Sitecore solutions involve at least one Microsoft Visual Studio project. Install Visual Studio on development workstations, not on production servers. Most Sitecore developers use IIS rather than the web server built into Visual Studio. For instructions on how to create a Visual Studio project for your Sitecore solution, see Appendix B.
Developers working with Visual Studio and the Sitecore ASP.NET CMS should use the Sitecore Rocks () extension for Visual Studio. Most Sitecore developers use Visual Studio and can benefit greatly from this free tool from Sitecore.
Install Sitecore Rocks on the development workstations on which you install Visual Studio.
For more information about Sitecore Rocks, see my blog post at . For additional useful tools for Sitecore developers, see my blog post at .
This chapter introduced web content management systems (CMS), CMS environments, the Sitecore ASP.NET CMS product, the Sitecore company, and the main components of a Sitecore installation. Sitecore developers using Visual Studio can implement advanced, scalable, consistent Sitecore solutions on the Microsoft Windows, IIS, and ASP.NET infrastructure to enable nontechnical CMS users to maintain structured content to populate a website using only a browser. Sitecore is a pure ASP.NET application, and tightly conforms to the core architectural principle of the framework.
The Sitecore solution infrastructure maximizes code and content reuse, and minimizes development and maintenance costs. It also provides a comprehensive, extensible, and flexible platform for your projects and a pleasant working environment for developers. Sitecore provides a variety of browser-based interfaces and applications for various types of users and tasks, as well as tools for developers, including the Sitecore Rocks plug-in for Visual Studio and optional software modules that integrate with the Sitecore CMS.
Chapter 2
Information Architecture
What's in This Chapter?
Creating items, including item properties, definition items, and item URLs
Using data templates, including base templates, the standard template, standard values, template sections, template fields, field properties, and field types
Considering data validation, including validators and validation options
Implementing multilingual solutions, including languages, regions, and multiple managed sites
Working with binary media, including media library settings and media item URLs
Understanding clones, aliases, and wildcards
Using insert options, including branch templates, command templates, and the uiGetMasters pipeline
This chapter introduces fundamental high-level concepts and low-level constructs and techniques used to implement and enforce information architecture with the Sitecore ASP.NET web content management system (CMS). Data templates define the structure of each type of item that you can store in a Sitecore database. Some types of items represent pages, such as the home item for each managed site. Sitecore contains logic to determine the URL for each such item, and to determine the item indicated by the URL in an incoming HTTP request. Sitecore uses items to manage numerous additional types of information, including configuration data, system components, and binary media.
Each data template defines zero or more sections that contain fields to define the structure and properties of a type of items. A data template can inherit sections and fields from any number of base templates. By default, data templates inherit from the standard template, which contains fields that define system properties available to all items. You can translate each item into any number of languages, and create any number of versions within each language. You can specify that Sitecore should not maintain versions or allow translation for the values of specific fields. Standard values define defaults (“standards”) for new items based on each data template. You can use validation to enforce data entry requirements. You can import content by invoking Sitecore Application Programming Interfaces (APIs) to create items and update field values.
Insert options control the types of items that users can create beneath existing items to define a hierarchical data structure. You can create item structures to represent websites, lookup lists, metadata taxonomies, and any other kind of data that you can structure in a hierarchy. Sitecore provides a number of facilities that enable you to share items and field values among components. You can create aliases to provide alternate URLs for items. You can create clones to make items appear in multiple locations in the content tree with the ability to override field values in the cloned items without actually duplicating those items. You can use wildcards to map URLs to resources in external repositories such as relational databases rather than items in the Sitecore database.
For more information about the topics described in this chapter, including instructions to implement the various components described, see The Sitecore Data Definition Reference (), The Sitecore Data Definition Cookbook (), and The Sitecore Data Definition API Cookbook ().
All web content management systems include two major components:
This chapter focuses on the former component; Chapter 3, which describes the Sitecore layout engine and data access APIs, focuses on the latter.
You can think of information architecture as a model for the structure of the data behind a web solution. Information architecture includes both high-level structures — defining the relationships among managed sites, their home pages, sections, applications, and pages, as well as other features of the solution — and low-level details, defining individual page types and the properties of individual data elements and other features within those pages. The information architecture can describe security, workflow, archiving, validation, and related requirements, and can even specify the presentation components required to render specific types, sections, pieces, and other aspects and groupings of content.
Information architecture may be the most critical component of a web solution. You cannot implement an optimal solution without solid information architecture, let alone enhance that solution over time. The user interface of a website begins to look stale as time passes, but the information architecture of that solution can have a longer life if you can apply a new presentation layer to the existing data.
Because definitions for some Sitecore terms result in circular references (for example, items depend on data templates, which depend on items, which depend on data templates), the following list provides a quick overview of key terminology explained in subsequent sections of this chapter:
Sitecore facilitates hierarchical information architectures. Most developers are familiar with relational databases, but most websites are hierarchical — a home page contains sections, sections contain subsections and pages, and subsections contain nested subsections and pages. Hierarchical information architectures can assist in securing sections and subsections of the site; you can use security inheritance to deny anonymous users read access, or to grant write access for a CMS role to an entire section or subsection.
Items in the information architecture have implicit relationships with other items, such as the parent/child relationship and the preceding-sibling and following-sibling relationships. Items also have explicit relationships with other items, such as when an image field in a content item contains a reference to a media item.
Sitecore uses the information architecture to determine the URLs of content items. URLs include the name of the item preceded by the names of its ancestors. For example, the default URL of the /sitecore/content/home/section/subsection/page item is /section/subsection/page.aspx relative to the /sitecore/content/home item that represents the home page for the default managed site.
Most Sitecore solutions use the information architecture to drive navigation for the site. In such cases the information architecture typically matches the visual structure of the website exactly. For example, the children of the home item might represent sections that appear in a top navigation component. When the user clicks an element in the top navigation, taking the browser to that section, the items representing subsections and pages within the clicked section could appear in the left navigation. Other solutions use techniques such as faceted search, which presents a default navigational structure based on content classification characteristics along multiple dimensions, and allows visitors to navigate in a variety of ways rather than using a single taxonomy, often through the application of filters that eliminate elements in that navigational structure that the visitor deems irrelevant.
Sitecore items represent individual resources within the CMS. Items can represent any type of data, such as a page, section, paragraph, or metadata attribute. Each item contains a number of properties common to all languages and versions of the item, such as its name and ID. In addition to content elements, Sitecore uses item to manage system and configuration components.
Make item names unique among siblings. Sitecore does not require this, but provides a validator that you can use to enforce this rule.
Each item can contain any number of field values that can vary by language and by version within each language. Each item exists within a hierarchy of items in a Sitecore database. The path of an item identifies its location within the hierarchy. Sitecore assigns a globally unique identifier (GUID, or just ID) to each item.
Sitecore does not differentiate content from metadata or control data. Each item can contain fields for content, metadata, system data, and potentially other types of data. You can use items to implement metadata and other taxonomies or to manage any data that you can represent in a hierarchy.
Like files, items contain data, but like subdirectories, items can contain other items. This means that you do not have to think about whether something is a subdirectory or a file when you create it; in Sitecore, you create an item regardless of whether you need to store data or contain other items. That item might not have any children today (making it like a file), but it could have children in the future (making it like a subdirectory). Either way, each item can contain field values and other items. If you need to change the fields that appear in an item, you can add fields to the data template associated with the item, or update the item to use a different data template.
You can use the Sitecode.Data.Items.CustomItem abstract class as a base class for your classes that represent different types of items. For more information about this approach, see Chapter 3. Many solutions benefit from the implementation of .NET classes to represent various types of Sitecore items. You can use the Sitecore.Data.Items.CustomItemBase class as a base class for your classes that represent different types of items. Sitecore Rocks has features that you can use to generate classes from data templates, or you can use either the CustomItemGenerator () Sitecore Shared Source project or the CodeGen () Sitecore Shared Source project for this purpose.
For more information about many of the concepts described in the remainder of this section, see The Sitecore Guide to Reusing and Sharing Data ().
You can translate each item into any number of languages. You can register languages before you use them, in which case they are available to all items and you can configure their properties in advance, such as to specify a flag, spellcheck dictionary, and security to control which CMS users can edit content in that language. Alternatively, you can add a version of an item in any language, in which case Sitecore applies default language properties.
Sitecore does not store different values for each language in fields that you mark as shared.
When you register a language, Sitecore creates a definition item under the /sitecore/system/Languages item to contain information about that language, such as the flag to display and the spellchecking dictionary to use.
I recommend that you register languages before you use them. That way, you can iterate the language definition items even if no versions exists in those languages in your content items, and you can retrieve metadata about languages consistently from those definition items.
To register a language in the Sitecore desktop, follow these steps:
To create a version of an item in a language that you have not registered:
For an example of a presentation component that links to each registered language for which a version exists for an item, see my blog post at .
You can create any number of versions of an item in each language. By default Sitecore uses the latest available version of each item in each language. Click the number at the top right corner above the editing pane in the Content Editor to select an alternate version of an item. Click the Versions tab to perform other operations on versions, including deletion and translation.
Having many versions in any number of languages for an item can reduce performance, especially when you work with items that contain a large number of fields, or fields that contain a large number of links. For information about a solution that uses a scheduled process to remove old versions of items, see my blog post at .
You may not find the API that removes a version where you expect it. The following code removes the oldest version of the context item:
Sitecore.Data.Items.Item item = Sitecore.Context.Item; item.Versions[item.Versions.GetVersionNumbers()[0]].Versions.RemoveVersion();
Many examples in this book use the context item exposed by the Sitecore.Context.Item static property. I used this shortcut to avoid repeatedly explaining and reproducing code to retrieve a database and an item within that database. Using the context item should work, but does not always provide the most logical example. You can apply any technique demonstrated for the context item to any item (any instance of the Sitecore.Data.Items.Item class).
In addition to a version number, which controls workflow and other features, Sitecore assigns a unique revision ID to each item every time you make a change to the item. Sitecore stores the revision ID in the field named __Revision (which you can access through the Sitecore.FieldIDs.Revision property that functions like a constant containing the ID of this field) in the Statistics section of the standard template. The __Revision field is unrelated to the version number for a language of an item, which Sitecore does not store as a field value, but as a property of that version.
Instead of hard-coding field names or IDs, which can increase maintenance effort, create static classes like the Sitecore.FieldIDs class with properties to expose the IDs of your data template fields. For the same reason, you can create classes like the Sitecore.ItemIDs class to store the IDs of specific items, and like the Sitecore.TemplateIDs class to store the IDs of your data templates.
To control the data type of an item, how that item appears in the user interface, how you can refer to that item in code, and the item's relationships with other items in the database, each item defines all of the properties in the following list: