Percentage Topics Number of Questions

||12% Sitecore structure & platform 6

||16% Security & user management 8

||20% Item management 10

||10% Layout & placeholders 5

||26% Components, controls, & renderings 13

||10% Sitecore Content Serialization 5

||06% Containers 3

Important Points to be aware of

50 Question 100 minutes

.net core

80% min passing mark

Review Options

==================================================================================

Topic to be aware of

Define Sitecore-specific terminology in a Developer context. Terms include Content Editor,

Experience Editor, component, rendering, placeholder, template, layout, item, and serialization.

Differentiate between Sitecore MVC and Sitecore Headless Development methods, tools, and
processes at a high level.

Identify the different deployment options for a Sitecore Experience Platform environment (e.g., on-
premise, containers, Managed Cloud).

Install Sitecore Experience Platform on a development workstation without the use of containers.

Create a .NET solution with the appropriate projects for your development method.

Execute development tasks assigned from a development plan for a Sitecore environment.

Create users and roles within the Sitecore platform.

Configure the security roles to meet the needs of the business and use cases of the environment.

Configure item security properly for existing and future items.

Manage permissions for items, roles, and users.

Identify when security rights are conflicting and resolve the conflict.

Use role inheritance to simplify role creation and management.

Use the Sitecore publishing features to publish items and sites to the appropriate databases.

Configure item workflows for Content Authors, Editors, and Publishers.

Define Sitecore-specific terminology in a Developer context. Terms include standard values, insert
options, item GUIDs, fields, field types, source values, inheritance, component definition items,
layout definition items, placeholder settings items, and package.

Add items in multiple areas within the content tree, such as templates, component definition items,
layout definition items, and placeholder settings items.

Create templates and standard values and set insert options to match the data structures outlined in
a development plan.

Recognize the differences between the standard Sitecore databases used, such as Web and Master.

Locate where search indexes are managed.

Use Sitecore packages to transfer Sitecore items and environment changes to another Sitecore
environment.

Install a Sitecore package.

Create layout definitions items within Sitecore and set the presentation details for a layout.

Create a corresponding layout file within your ASP.NET project.

Explain the difference between a static and dynamic placeholder and give the purpose of each.

Set presentation details on a template item.

Create a placeholder settings item.

Set Allowed controls on a placeholder settings item.

Define a placeholder on a layout, both dynamically and statically.

Differentiate between the different rendering definition items in Sitecore, such as view, controller,
and JSON rendering items.

Set the compatible renderings on a rendering definition item.

Control component usage by configuring the Datasource Location and Datasource Template fields.

Set up additional control properties and component parameters.

Use caching controls on a rendering item to improve environment performance.

Build components that utilize the Rendering Contents Resolver to access additional information from
the Sitecore platform, such as content tree structure and system- based templates.

================
General:

Differentiate between the different rendering definition items in Sitecore, such as view, controller,
and JSON rendering items.

Set the compatible renderings on a rendering definition item.

Control component usage by configuring the Datasource Location and Datasource Template fields.

Set up additional control properties and component parameters.

Use caching controls on a rendering item to improve environment performance.

Build components that utilize the Rendering Contents Resolver to access additional information from
the Sitecore platform, such as content tree structure and system- based templates.

Sitecore MVC:

Create view and controller renderings.

Differentiate between static component binding and dynamic component binding with placeholders.

Explain the purpose of Sitecore MVC field helpers.

Render Sitecore fields as editable in Experience Editor by using Sitecore MVC field helpers.

Sitecore ASP.NET Core Rendering SDK:

Create and register model-bound view components, custom view components, and partial view
components.

Explain the purpose of Sitecore tag helpers.

Rendering Sitecore fields as editable in Experience Editor by using Sitecore tag helpers in component
views.

================

Locate and connect to the source control location for your development project.

Install the Sitecore Command Line Interface (CLI).

Log in to Sitecore from the CLI.

Configure a Serialization module with included paths and rules.

Execute the CLI commands to push and pull content item from Sitecore.

Use serialization packages for continuous integration.

Install Sitecore for Visual Studio (VS).

Use Sitecore for VS to push and pull content items from Sitecore.
Prepare the files necessary to deploy Sitecore XP to containers.

Launch a Sitecore environment with docker-compose.

Set up a Sitecore solution with your own Docker images based on Sitecore provided images.

Develop and debug within a Sitecore environment running on containers.

Official documentations on above Topics

https://doc.sitecore.com/en/users/101/sitecore-experience-platform/the-content-editor.html

https://doc.sitecore.com/en/users/101/sitecore-experience-platform/the-experience-editor.html

*https://dev.sitecore.net/Downloads/Sitecore_Experience_Platform/101/Sitecore_Experience_Platf
orm_101_Update1.aspx

https://doc.sitecore.com/en/developers/101/sitecore-experience-manager/data-templates.html

https://doc.sitecore.com/en/users/101/sitecore-experience-platform/managing-items.html

https://doc.sitecore.com/users/93/sitecore-experience-platform/en/workflows-and-the-
workbox.html

https://doc.sitecore.com/en/users/sxa/101/sitecore-experience-accelerator/layout.html

https://doc.sitecore.com/en/developers/101/sitecore-experience-manager/versioned-layouts.html

https://doc.sitecore.com/en/developers/101/developer-tools/sitecore-headless-development.html

https://doc.sitecore.com/en/developers/101/sitecore-experience-manager/mvc.html

https://doc.sitecore.com/developers/93/platform-administration-and-architecture/en/securing-
experience-manager.html

https://doc.sitecore.com/developers/93/platform-administration-and-architecture/en/sitecore-
security.html

https://doc.sitecore.com/en/developers/101/developer-tools/sitecore-content-serialization.html

https://doc.sitecore.com/en/developers/101/developer-tools/containers-in-sitecore-
development.html

https://doc.sitecore.com/xp/en/developers/101/developer-tools/index-en.html

https://www.sitecore.com/knowledge-center/getting-started/docker-a-quick-overview#chapter1

https://doc.sitecore.com/xp/en/resources/sitecore-asp-dot-net-rendering-sdk/100/api/

Key points on above Topics

What is the use of layout service?

To provide structured data about Sitecore-based pages including components and their associated
content

.env use Docker

Default serialization – item with descendants

When using Sitecore Content Serialization, what is the sitecore.json file in your development
solution?

The configuration file for global development plugins and module locations

What will happen if you do not add the hostnames of your Sitecore environment to your Windows
hosts file?

You will not be able to access the Sitecore environment via the IP address in a browser.

When you are working with a multisite implementation, what is the recommended practice for
creating each site’s tree structure?

Create a specific site definition configuration, a folder for each site under the Content item, and a
Home item for each site within the folder.

Which two of the following statements are reasons for assigning security rights to roles instead of
individual users?

Assigning permissions to individual users can be confusing and create risk.

Roles enable you to control security access for groups of users and roles simultaneously.

When is template inheritance not recommended for fields with the same name?

When the fields require different field sources

Sitecore recommends defining an item's presentation details as part of the standard values child
item of a data template.

Why is it important to define presentation details in the standard values item?

Items created from a template inherit the standard values, including presentation details, and NULL
fields default to the template standard values.

Content Editor/Experience Editor

Validation Rules and Broken Links quick actions slow down performance the most.

Fields from the Standard template are hidden to improve performance.

Quick Action Bar can display as many of the quick actions as you like, but the performance might
decrease for every action you select.

Sitecore sorts items in the content tree by item name by default.

The sorting is case insensitive.

If you have the appropriate access rights, you can change the way the Experience Editor presents the
editable items for you.

The functionality on the ribbon varies depending on your security roles and the customizations of
the website that you are accessing.

To show the editable text fields, select the Editing check box.

To show the renderings and placeholders, select the Designing check box.

To show outlines of all the objects on a page, select the Controls check box.

To outline, with a green dotted line, all the components on a page that contain associated content,
select the associated content check box.

In both the Content Editor and the Experience Editor, an item must be in the editing state before you
can edit it.

Can have an item bucket that is a hybrid of hidden items and visible items.

When you create a new page, it is automatically locked to prevent other users from editing it.

A Sitecore administrator can have the authority to edit another user’s locked items

Locking an item does not keep it from being published.

By default, you are editing the final layout.

Use a wildcard item to create dynamic URLs.

When you archive an item, it is not deleted but stored outside the content tree. Archived items can
be restored at any time.

Some items are stored in resource files and you cannot delete them.

When you modify resource items, Sitecore creates a copy of the item with modifications in the
database and uses this instead of the item in the resource file.

Workflow

Workflows enable you to have control over the content approval and publishing process, ensuring
that only content that has been approved is published.

Workflows consist of three elements – states, commands and actions.

Workflows – the parent item, contains all the subitems that make up the workflow.

States – the basic building blocks of the workflow. The workflow states represent the different
stages in your content creation process.

Commands – move content items from one workflow state to another. When the command is
executed, the item is moved to the workflow state that is defined in the command item.

Actions – the actions that are automatically performed on the items when they are in particular
workflow states or when particular workflow commands are executed.

The Workbox gives you an overview of all items that are in workflows and enables you to manage
these items.

In the Workbox, you can see the editing history of items in the workflow, each item's workflow state,
and the number of items in each workflow state.

In Sitecore, you can implement any number of different workflows. As a minimum, each workflow
must contain two workflow states – the initial and final workflow state.

Item Bucket

Item buckets let you manage large numbers of items in the content tree.

An item bucket is a container that you can use to hide a large number of items and still easily
retrieve and work with these items

The only way to find bucket items is to use the Sitecore search engine.

All the content items in an item bucket are automatically organized in a logical format that increases
the performance of the search engine.

A single item bucket can contain millions of content items without slowing down the UI or
congesting the content tree.

You can have as many item buckets as you want. This lets you split up your item buckets into logical
containers, for example, one for products and one for articles.

An item bucket can contain both regular items and bucketable items.
Regular items (structured items) are stored in an item bucket, are visible in the content tree, and
they maintain their parent-to-child relationship with their ancestors and descendants. These items
are based on a template that does not support item buckets.

Bucketable items (unstructured items) are hidden in the content tree and do not maintain their
parent-to-child relationship. These items are based on a template that supports item buckets.

Do not store both regular and bucketable items in an item bucket. This can cause errors.

Whenever you change the bucketable settings for items in an item bucket, you must synchronize the
item bucket to make sure that all the items are hidden or shown according to whether they are
bucketable or not.

You must synchronize an item bucket when you:

Make a regular item that is stored in an item bucket into a bucketable item.

Make a bucketable item into a normal item.

Make a template bucketable.

Change a bucketable template into a normal template.

Delete an item from the item bucket.

Do not add, remove, or move content items or folders in the bucket structure. Manual changes to
the bucket structure can cause errors in indexing and publishing.

If you made a template no longer bucketable, you must synchronize each item bucket that contains
items based on the template that you changed.

Template

In Sitecore, creating the data structure means creating data templates, defining standard values,
assigning insert options, and creating content items.

A template has nothing to do with the presentation of content.

A template is an item that defines both the structure and behaviour of other items

A data template, for example, inherits sections and fields from its base templates.

Data templates support sequential and multiple inheritance.

In the Template Manager, the root item of the content tree is /Sitecore/Templates.

In the Content Editor, the root item of the content tree is /Sitecore.

The standard template uses the section names Advanced, Appearance, Help, Layout, Lifetime, Insert
Options, Publishing, Security, Statistics, Tasks, Validators, and Workflow. Avoid using these section
names in your data templates.

If a data template inherits from a single data template more than once, Sitecore ignores all but the
first occurrence of that base template.
If you select the Reset Blank check box, it resets the field value to NULL when the item is saved with
this field set to blank. NULL fields reflect the standard value for the field.

Data template sections organize fields into related groups.

Fields are always stored within a section. Sections, however, are only reflected in the Content Editor.

Use sections to group fields logically, making them easier for content authors to find and use.

Section definition items are stored under the corresponding data template definition item.

Item Management

If the item does not exist, or the context user does not have read access rights to the item, the
Sitecore.Data.Database.GetItem method returns Null.

Sitecore does compare the case when evaluating item paths.

Use the Sitecore.TemplateID class to access system data templates.

Sitecore APIs may return Null or throw exceptions if the context user does not have a required
access right.

An include can have multiple rules, and the order of the rules dictates the order they are evaluated.

Sitecore Headless Development

Sitecore Headless Development splits a Sitecore project up into a Sitecore instance and a separate
rendering host.

Sitecore Headless Development introduces efficiencies in developing, maintaining, scaling, and

upgrading Sitecore solutions.

A Content Delivery (CD) instance carrying less load, because it no longer handles the presentation
layer.
A lightweight rendering host that handles the presentation layer.

In some solutions, Content Delivery still needs to scale out to handle requests from an increased
number of rendering hosts.

Sitecore Containers eases the setup of your development environment, but it is not a requirement
for Sitecore Headless Development.

For more complex components, you might need to deploy content resolvers or write GraphQL
queries to support rendering host components.

The CD instance still handles tracking, Sitecore Layout Service requests, GraphQL queries,
personalization, and so on.

If your presentation layer is a heavy load on your infrastructure then using a rendering host, and
perhaps a solid caching strategy, can help reduce horizontal scaling costs.

With Headless, must deploy any site definition configuration patches to your Content Delivery
instances.

Sitecore Headless Development is based on a rendering host front end and a Sitecore instance back
end.

In a headless system, the front end and back end are separate infrastructures that communicate
using endpoints.

The front end contains your website code and static resources.

The back end contains your content items.

Sitecore Headless Development functions in the following way:

The rendering host translates a visitor request to a content item in the Sitecore instance.

The Sitecore instance using Sitecore Headless Services returns the content item and the
associated presentation details, and so on, to the rendering host.

The rendering host renders the content item for the visitor.

Rendering host functions in the following way:

The visitor sends a request to the web server, which activates the rendering host web app.

The Layout Service Client fetches the relevant content and presentation data (the data
model) from the Sitecore Headless Services.

The Layout Service Client passes the data model to the Rendering Engine.

The Sitecore Rendering Engine renders the data model and your code and static resources
into the final response and returns it to the visitor.

Sitecore Headless Services provides the APIs needed for the Sitecore ASP.NET Rendering SDK.

Can install Sitecore Headless Services in the following ways:

 In an on-prem Sitecore installation as a Sitecore package

In a cloud Sitecore installation as a Web Deploy Package using the Sitecore Azure Toolkit

In a Sitecore container using Dockerfiles

The Sitecore Layout Service is a Sitecore Headless Services endpoint that provides JSON formatted
Sitecore content.

We use Sitecore Layout Service Client to communicate with the Layout Service.

And we use the Sitecore Rendering Engine to render the content.

The Sitecore Rendering Engine renders content fetched from a Sitecore instance using the Sitecore
Layout Service.

Layout Service Client libraries are available as NuGet packages, and their name is prefixed with
Sitecore.LayoutService.Client.

Rendering Engine libraries are available as NuGet packages, and their name is prefixed with
Sitecore.AspNet.RenderingEngine

SitecoreLayoutRequest model instantiates to an intermediate Data Transfer Object that supports

reading and writing of arbitrary properties

SitecoreLayoutRequest Properties are - API Key*, Item*, Site name, Language.

Layout Service Client sends these properties to the Layout Service using query string keys.

Layout Service returns an object instantiated from the SitecoreLayoutResponse strongly typed
model

SitecoreLayoutResponse object consists of several parts:

Request - the SitecoreLayoutRequest sent to the Layout Service.

Metadata - response metadata such as HTTP response headers.

Content - the deserialized JSON response.

Errors - the list of errors encountered while handling the SitecoreLayoutRequest object and
building the SitecoreLayoutResponse object.

HasErrors - this is true if the Errors list is not empty.

Extension methods are available in the Rendering Engine that can help with configuring component
renderers:

AddViewComponent() - maps a Sitecore layout component name to a view component

rendering. The mapping process is case-insensitive.

AddModelBoundView<TModel>() - maps a Sitecore layout component name to the default

view component rendering using the default Sitecore view component to model bind it. The
mapping process is case-insensitive.

AddPartialView() - maps a Sitecore layout component name to a partial view rendering.

 AddDefaultPartialView() - maps any unmatched Sitecore layout component to a default
partial view.

ComponentRendererDescriptor? DefaultRenderer -

This is the default component renderer descriptor object for handling Sitecore component
rendering. By default, this is null.

We can add additional endpoints for non-Sitecore routes before the Sitecore endpoints.

Sitecore Rendering Engine renders Sitecore content using ASP.NET view components and partial
views.

Partial views are generally for lightweight components on a Sitecore page that do not contain their
own content, such as structural components that contain just placeholders.

Custom view components are intended for use anywhere you have reusable rendering logic that is
too complex for a model bound view.

Generally, model bound views are likely be the ones you use most frequently. These are backed by a
default Sitecore view component which binds component content to a provided type.

Sitecore ASP.NET Rendering SDK provides several custom tag helpers for rendering content,
placeholder data, and metadata required for page editing.

Tag helpers are available in the Sitecore.AspNet.RenderingEngine library:

Placeholder tag helper

Text Field tag helper

Rich Text Field tag helper

Hyperlink tag helper

Date tag helper

Image tag helper

Number tag helper

Your rendering host page outputs Unknown component or a similar message, because you have not
yet mapped a component to this JSON rendering in your rendering host.

The running rendering service uses dotnet watch and re-compiles automatically for any changes you
make. You can also run the rendering project directly from Visual Studio.

Navigation contents resolvers must avoid using Sitecore.Context.Item or other page-specific context

Where possible, use Sitecore Content Search instead of Sitecore Query

When creating new renderings for use on your ASP.NET Core site, do not use Sitecore MVC
rendering types such as Controller rendering or View rendering. Always use a Json Rendering
(/sitecore/templates/Foundation/JavaScript Services/Json Rendering).
To output the full structured layout of an item, the Layout Service needs to know what placeholders
are present on a rendering.

To make these exposed placeholders discoverable, the Layout Service adds this field to the Sitecore
rendering definition.

Layout Service assumes that all placeholders other than root placeholders (usually header, main,
footer, etc.) are dynamic placeholders.

Dynamic Placeholder: {placeholder key}-{rendering unique id}-0

The Layout Service does not support indexed dynamic placeholders. The final value in the key is
always zero.

To enable rendering host tracking, analytics, and personalization, you must configure the rendering
host requests to the Sitecore Layout Service to include the visitor IP address as an X-Forwarded-
For HTTP header.

When you configure output caching on JSON renderings with the Layout Service, instead, it saves the
JSON of the component’s layout in the output cache.

The Layout Service returns the cached JSON, until publishing clears the cache.

Model binding is done with IFieldReader and is case sensitive. If a model property is not mapped
through attributes, default ASP.NET Model-View-Controller model binding behavior takes over.

In ASP.NET, view components are similar to partial views but more powerful.

A view component consists of three files:

The view component class

The Razor view

The view model class

The Sitecore Rendering Engine SDK uses MVC partial views for the lightweight components that
make a Sitecore page. For example, structural components that contain just placeholders.

You find the Razor page extensions in the Sitecore.AspNet.RenderingEngine.Extensions namespace:

SitecoreRoute() - get the current Sitecore Route object.

SitecoreContext() - get the current Sitecore Context object.

SitecoreComponent() - get the current Sitecore Component object.

You must check your rendering host logs for any compilation errors.

You use contents resolvers with the Sitecore Layout Service in order to provide more complex data
beyond serialization of a component data source.

The ResolveContents method must return an object that can be returned to the rendering host as a
JSON rendering.

The contents resolver class overrides the ResolveContents method of

the Sitecore.LayoutService.ItemRendering.ContentsResolvers.RenderingContentsResolver class and
returns a content tree object.
var contextItem = GetContextItem(rendering, renderingConfig);

In Content Editor, right-click /sitecore/System/Modules/Layout Service/Rendering Contents

Resolvers and click Insert, Rendering Contents Resolver.

If possible, configure output caching for renderings that use contents resolvers. This is especially
important for renderings like the navigation example that need to access many items.

Sitecore Rendering Engine SDK offers support for globalization and localization, the same as in
ASP.NET Core.

Minimal configuration is required to add globalization and localization in a .NET Core rendering host
application built using the Rendering Engine SDK. Most of this configuration is done in
the Startup class of the rendering host application.

If you encounter an error, check the rendering host logs for compilation errors. In PowerShell, type
the following: docker-compose logs -f rendering.

For cache ability select - Vary By parameters on your JSON renderings.

Gets the ISitecoreRenderingContext from the Microsoft.AspNetCore.Http.HttpContext.

New development flow with Sitecore 10

Docker - fast to start-up/take down, lighter than VMs, Application elements in container

.NET Core rendering SDK, headless CDN, lightweight and cross platform

Docker build - to create new images

Docker compose - to create and destroy when need to

Containers are immutable, you do not have to worry about ruining your local Sitecore instance.
Use docker-compose down and docker-compose up to get up and running again.

The default Sitecore container configuration uses specific ports. To avoid any conflicts, ensure that
the following ports are not being used by another process: 443, 8079, 8081, 8984, and 14330.

docker-compose.yml and .env : Types of Docker Compose files. These are the main files necessary
for launching a vanilla Sitecore instance. Included in the Sitecore Container Deployment Package.

mssql-data, solr-data, and traefik - Supporting folders utilized by the Docker containers within your
Sitecore instance. Included in the Sitecore Container Deployment Package.

init.ps1 and clean.ps1 - Example helper scripts. Not part of the Sitecore Container Deployment
Package.

docker-compose.yml

This Compose file is the main configuration file used by the docker-compose command. It contains
information about the different containers (referred to as services) and their configuration.

.env
This is an environment file. The values here provide default values for any environment variables
referenced in the Compose file (for example SITECORE_DOCKER_REGISTRY), or you use it to
configure Compose (for example COMPOSE_PROJECT_NAME).

Environment variables are the recommended way to pass configuration settings into containers.

The repository includes a script that performs all preparation steps automatically: the init.ps1 script.

You can reuse variables across multiple Sitecore instances by setting environment variables in
Windows instead of the Docker Compose environment file.

docker-compose stop - This stops your containers, but does not remove them.

They can then be started again with docker-compose start.

docker-compose down - This stops your containers, but also removes the containers as well as any
networks that were created.

We can manually delete the files in these folders, or you can use the clean.ps1 script

When Docker Compose is handed two or more compose files, it merges them together, bringing all
the resources and configuration together into a single merged definition.

docker-compose build solution - This initiates the build process for the solution image and creates
your image

The Sitecore CLI is optimized for scripted interaction with a remote Sitecore instance. It can be used
to package items during your continuous integration process, and to install those packages during
your deployment and delivery process. Automating item deployment into a Sitecore environment
with the Sitecore CLI is no different when using containers.
MS Build and Visual studio deploy

https://youtu.be/bf28_1QebaQ

https://youtu.be/RMYGVOswIKk

https://youtu.be/cA1CMdwrNVU

Sitecore for Visual Studio/Serialization

The SCS system serializes content items into your project folder as YAML files. The default path
is \serialization relative to the module file.

The project configuration file is named sitecore.json. It has several properties, including
a modules property that references the relevant Sitecore Content Serialization modules.
{

"$schema": "./.sitecore/schemas/RootConfigurationFile.schema.json",

"modules": [ "src/*/*.module.json" ],

"variables": {},
 "serialization": {

"defaultMaxRelativeItemPathLength": 120,

"defaultModuleRelativeSerializationPath": "serialization"

}
Environments are stored in the .sitecore/user.json file under the project root.

You use environments to configure connections to Sitecore instances including authentication and
authorization credentials.

If you name the environment default, the Sitecore Command Line Interface uses this environment
unless another is specified

Synchronization operation is performed in the Push items to Sitecore and Pull items from Sitecore
windows (generally known as the Sync window)

SVS validates the serialized items in your file system against the items in the target Sitecore instance.

This is the same process as if you ran the sitecore ser validate command.

sitecore ser pull -w -v command

To let SVS attempt to fix the differences on the list, click Fix Errors.

This is the same process as if you ran the sitecore ser validate --fix command.

Developer collection feed URL is https://sitecore.myget.org/F/sc-developer-

collection/api/v3/index.json

Enabling the push operation is the same as running the sitecore ser push command at build time.

Enabling item serialization is the same as running the sitecore package create command at build
time.

TDS has the following functionality that is not available in SVS:

 File deployment into a local Sitecore instance

 Web Deployment Package (WDP) generation
 Code generation
 Validators
 Environment Validation

We single out subsets of content items for serialization with includes and rules. This is useful for
repeating the serialization of particular parts of your content item tree.

We configure what and how content items are included and excluded from serialization in a module
file such as Project.module.json. You can place and override serialization configurations in all module
files.

A content item is only included once across all modules.

Each include must have a name property that becomes a folder name in your file system and
a path property that specifies what part of your content item tree to serialize.
"items": {

"includes": [

"name": "content",

"path": "/sitecore/content/home"

The order of the includes is important. If your content items are dependent on a template in the
same module, your template include must come first.

Include properties are referred to as root properties, as in root name and root path.

Rules are used to configure the serialization of content item trees. You configure rules with a path
relative to the root path, the scope of content items to influence, and any alterations to the allowed
push operations.
"items": {

"includes": [

"name": "content",

"path": "/sitecore/content/home",

"rules": [

"path": "/products/legacy",

"scope": "ignored"

},

"path": "/products",

"scope": "ItemAndDescendants",

"allowedPushOperations": "createUpdateAndDelete"

},

"path": "*",

"scope": "ignored"

]
}

The rule system works by the first-match-wins principle, meaning that when a content item matches
a rule, all subsequent rules are ignored.

Keep the following things in mind when you configure rules:

Do not let rule paths overlap. Or, if you do, you must put the most specific rule first.

Rules for parent's paths override rules for children's and descendants' paths.

Rule scopes cannot be more inclusive than the root scope. For example, if the root scope
is ItemAndChildren, the rule scope cannot be ItemAndDescendants.

The alias property in a rule replaces the root name property (the folder name in your file system) for
this particular rule.

If you have configured an alias property and a scope property with an ignored value, the scope is
used. Content items scoped to be ignored are not influenced by aliases.

Sync operations always ignore excluded fields. So if you change those fields in Sitecore, the CLI does
not detect any changes, and pushing data does not override them. If you have excluded fields in
YAML files, they are removed only after changes in the included fields or if you manually delete that
exclusion and perform a pull operation.

The include properties:

Requ
Property Valid values Default value
ired

name Yes String None

path Yes String None

SingleItem, ItemAndChildren, It
ItemAndDescen
scope No emAndDescendants,
dants
and DescendantsOnly.

database No master or core master

maxRelativePa
No Number 130
thLength

allowedPushOp CreateOnly, CreateAndUpdate, CreateUpdateA

No
erations and CreateUpdateAndDelete ndDelete

Duplicate item names on the same level are not supported by the CLI, even if such items are under
ignored nodes.

Sitecore Content Serialization (SCS) system uses hashing to shorten paths that are too long for your
file system. It also offers human readable aliases of hashes.
The scope property configuration:

Scope Content items influenced

SingleItem Only the content item.

ItemAndChildren The content item and its immediate children.

ItemAndDescendants The content item and all its descendants.

DescendantsOnly Only the descendants of the content item.

All children and descendants are ignored except those

previously matched.

Ignored Important

Only valid in rules. Not valid in includes.

Sitecore CLI

https://youtu.be/CzQbwvKX1Cc

.NET Core must for Sitecore CLI

cd <project folder>

dotnet new tool-manifest

dotnet nuget add source -n Sitecore https://sitecore.myget.org/F/sc-packages/api/v3/index.json

dotnet tool install Sitecore.CLI

To check Sitecore CLI version dotnet sitecore --version

dotnet sitecore plugin add -n Sitecore.DevEx.Extensibility.Indexing --version 4.0.0

dotnet sitecore plugin add -n Sitecore.DevEx.Extensibility.Publishing

dotnet sitecore plugin add -n Sitecore.DevEx.Extensibility.ResourcePackage --version 4.0.0

dotnet sitecore plugin add -n Sitecore.DevEx.Extensibility.Serialization

To upgrade CLI version dotnet tool update sitecore.cli --version 4.0.0

To update json schema dotnet sitecore init

Login with this command

sitecore login --authority https://<Sitecore identity server> --cm http://<Sitecore instance> --allow-
write true

To configure a non-interactive client login

<?xml version="1.0" encoding="utf-8"?>

<Settings>

<Sitecore>

<IdentityServer>

<Clients>

<!-- used to authenticate servers with client id and client secret -->

<CliServerClient>

<ClientId>SitecoreCLIServer</ClientId>

<ClientName>SitecoreCLIServer</ClientName>

<AccessTokenType>0</AccessTokenType>

<AccessTokenLifetimeInSeconds>3600</AccessTokenLifetimeInSeconds>

<IdentityTokenLifetimeInSeconds>3600</IdentityTokenLifetimeInSeconds>

<RequireClientSecret>true</RequireClientSecret>

<AllowOfflineAccess>false</AllowOfflineAccess>

<AllowedGrantTypes>

<!--

client_credentials authenticates with client ID and client secret

which is good for CI, tools, etc. However, it's not tied to a USER,
 it's tied to a client ID.

-->

<AllowedGrantType1>client_credentials</AllowedGrantType1>

</AllowedGrantTypes>

<ClientSecrets>

<!--<ClientSecret1>SUPERLONGSECRETHERE</ClientSecret1>-->

</ClientSecrets>

<AllowedScopes>

<!-- this is required even if not a 'user' for Sitecore to like us -->

<AllowedScope1>sitecore.profile.api</AllowedScope1>

</AllowedScopes>

</CliServerClient>

</Clients>

</IdentityServer>

</Sitecore>

</Settings>

To manually validate your content items sitecore ser validate

To sort out most common issues sitecore ser validate --fix

Layout

Components are called renderings and they are listed in the Toolbox in the Experience Editor.

Variants may make a rendering appear differently or may make them show different content.

Snippet - Provides placeholders to create a reusable group of renderings.

You cannot render or edit placeholders within the Search Box/Search Results component because its
content is generated by the SXA search service.

If you are unable to drag a certain rendering to the page, this may be caused by placeholder
restrictions.

In the Select the Associated Content dialog box, select the content item you want

Click the rendering that you want to edit and in the floating toolbar, click Edit component properties
Do not change the Placeholder and Data Source properties. Changing these properties can cause the
rendering to disappear or may lead to other unexpected behaviour.

Composite renderings, such as Accordion, Carousel, and Toggle, Flip, Tabs, Snippets use all data
sources with their own layout.

SXA is based on a responsive grid layout.

By default, when you add a rendering to a page, it takes the full width of the column.

To change the default settings permanently, you must change the grid settings in the Content Editor.

In the Experience Editor, you can change this in the grid settings of the rendering.

To see the grid columns, on the ribbon, on the View tab, select Grid.

The new rendering takes the grid settings of the existing rendering.

To display renderings that are hidden on specific devices because of grid settings, on the View tab,
select Hidden components.

By default, SXA comes with four different grid systems to select when creating your site: Bootstrap 3,
Bootstrap 4, Foundation, and Grid 960.

SXA supports integrating other grid frameworks and you can also build your own.

SXA comes with different view modes to help you set up your site quickly.

A site can be put together using wireframe mode, while in the meantime the site theme is sent to a
creative agency using Creative Exchange.

When you open a site that has no site theme selected in Experience Editor, the Wireframe mode is
automatically selected.

On the ribbon, on the Experience Accelerator tab, click View Mode to switch the mode.
For some devices the view mode does not apply. For these devices you can switch the view mode
off.

To disable the view mode:

Open the Sitecore.XA.Foundation.Theming.config file, navigate to

the <devicesWithoutViewMode> section, and add the GUID of the device item in Sitecore.

Versioned layouts

Versioned layouts make it possible to specify different layouts for different versions and languages
of the same item.

In the Standard fields of a versioned item, in the Layout section, two fields are for layouts:

__Renderings – a shared field where you specify the common layout for all languages and versions of
the item.

__Final Renderings – a versioned field where you specify individual layouts for languages and
versions of the item.
When you reset a versioned layout, the final layout becomes the same as the shared layout of the
item.

By default, the enforce version presence feature is disabled. You must enable the feature on the
relevant websites and on the relevant items or item templates.

To enforce version presence on a website:

Open \Website\App_Config\Sitecore.config and set the attribute enforceVersionPresence to true.

You must enable the attribute on each of the relevant websites.

In Sitecore 8 and later, the constructor checks whether the item has a value in the versioned __Final
Renderings field. If it does, layout data is loaded from this field. If it does not, layout data is loaded
from the shared __Renderings field.
Multivariate test data for all languages is no longer stored in the shared __Renderings field. Each
version of an item can have different multivariate test data in the versioned __Final Renderings field.

The Sitecore.Layouts.MultiVariateTestingExtensions class was removed because the

shared __Renderings field is no longer used for storing multivariate test data for all languages. Each
version of the item can have different multivariate test data in the versioned __Final
Renderings field.

In Sitecore 8 and later, you should use the following method to get layout data when you want to
ignore the value of the versioned __Final Renderings field:

var sharedLayout = LayoutField.GetFieldValue(item.Fields[FieldIDs.LayoutField]);

In Sitecore 8 and later, you should use the following method to save layout data to the
shared __Renderings field:

LayoutField.SetFieldValue(item.Fields[FieldIDs.LayoutField], sharedLayout);

In Sitecore 8 and later, you should use this method to save the shared layout and the final layout of
an item:

ItemUtil.SetLayoutDetails(item, sharedLayout, finalLayout);

In Sitecore 8 and later, you should use this method to reset shared and final layouts of an item:

ItemUtil.ResetLayoutDetails(item, resetSharedLayout, resetFinalLayout);

MVC

RequestBegin pipeline is the first action of an MVC request after the request has been passed down
from the main HttpRequest pipeline.

A PageContext is created and assigned to the current thread.

RequestEnd pipeline is the last action of an MVC request. This pipeline is not currently used.

CreateController pipeline is called by the SitecoreControllerFactory to create a controller for the

current route selected by the MVC request handler.

ActionExecuting pipeline executes before an MVC controller action is executed. This pipeline is not
currently used.

Same action for these pipeline as well ActionExecuted, ResultExecuting, ResultExecuted.

GetPageRendering pipeline selects the rendering to use as the root rendering of the page for
creating the output of the current request.

GetRenderer pipeline transforms an abstract rendering definition (rendering) into an object that can
render output back to the client (renderer).

GetModel pipeline creates the model object to use when rendering an MVC view. This is typically a
ASP.NET MVC 3 Razor view.

RenderPlaceholder pipeline is called as part of the Html.Sitecore().Placeholder extension method. It

handles nested placeholders, when applicable.
RenderRendering pipeline renders the specified rendering. This pipeline handles caching and sets up
the IRenderingContext for accessing source items of the renderings. This supports nested
renderings.
If the request matches an MVC route, the request is transferred to MVC after the Sitecore context
has been set up, but before the Sitecore layout has been resolved.

If no layout is associated with the current item, but the item has a controller specified in
the Controller field, the request is transferred to MVC.

Use HTTPS across your entire website. In the Sitecore.Xdb.Remote.Client.config file, RequireHttps is
enabled by default and should remain enabled in all production environments. HTTP is not secure
enough for production servers and should only be used on local testing or development instances.

To ensure secure communication between servers in a scaled Sitecore environment, each request
from a client must be authenticated on the xDB Reporting server and the xDB Processing server.

In Sitecore 9.0.2 and later, SqlShell.aspx is disabled by default.

To Enable an administrative tool that is disabled by default - enableUnlockButton = true

Sitecore enforces the use of HTTPS by default

To enforce HTTPS for any client connecting to an XP service role with a web end point

sc.XConnect.Security.EnforceSSL.xml

sc.XConnect.Security.EnforceSSLWithCertificateValidation.xml

Sitecore Security

A role is a collection of users or a collection of users and other roles. You can use roles to assign
access rights to groups of Sitecore users by making them a member of a role.

Sitecore contains a set of predefined security roles that you can use, or you can create new roles and
give them the relevant access rights.

In Sitecore, there are also global roles that all users across domains can see. These roles are listed in
the /App_Config/Security/GlobalRoles.config file.

In Sitecore, a security account is identified by its name (domain name\account name, for example,
sitecore\Developer or sitecore\ECM advanced users) and therefore, two security accounts cannot
have the same name.

A security domain is a collection of security accounts (users and roles) that you can administer as a
unit with common rules and procedures.

A domain is used to collect security accounts that have some logical relationship.
If you are using SSL security, you must also add the following setting to the configuration file

<system.net>

<mailSettings>

<smtp deliveryMethod="Network">

<network enableSsl="true" />

</smtp>

</mailSettings>

</system.net>

Sitecore validates links by default when you save an item.

To disable link validation:

Patch the Sitecore.config file to change the mode setting of the following processor
node: <processor mode="on" type="Sitecore.Pipelines.Save.CheckLinks,
Sitecore.Kernel"/> to <processor mode="off" type="Sitecore.Pipelines.Save.CheckLinks,
Sitecore.Kernel"/>

Sitecore implements inheritance when content is retrieved. If a user does not have access at either
the user/role level or at the item/ancestor level, an item is not retrieved.

You can restrict the ability of a user or role to convert a content item into an item bucket or to
convert an item bucket back into a normal item in the Security Editor.

The history engine saves information about changes made to items in the History table.

All Sitecore content databases contain this table. The engine logs the item change data based on
Sitecore events.

Sitecore does not use the history table by default. It has been disabled for performance reasons.

Remove the example extension from

the \App_Config\Include\Examples\Sitecore.HistoryEngine.config.example file.

In the User Manager, you can:

Create, edit, and delete users

Change the password of users

Enable and disable users

Lock and unlock users

Open the other security tools

In the Role Manager, you can:

Create and delete roles.

Add or remove users and roles as members of a role.

Open the other security tools.

You can use the Role Manager to create and manage the roles that you want to assign to your
security accounts (users and roles).

You can use the Security Editor to assign the access rights that roles and users should have to the
items in the content tree.

In the Security Editor, you can:

Assign access rights to your security accounts

Protect and unprotect items

Open the Access Viewer and the User Manager

You can use the Access Viewer to get an overview of the access rights that are assigned to your
security accounts.

In the Access Viewer, you can:

Get an overview of the access rights that are assigned to the security accounts for each item
in the content tree.

See an explanation of how the current settings have been resolved.

Open the Security Editor and the User Manager.

You can use the Domain Manager to create and manage your domains.

In the Domain Manager, you can:

Create and delete domains.

Specify whether the domains are global or locally managed.

Open other security tools.

In the Content Editor, on the Security tab, you can:

Assign access rights to your security accounts.

Get an overview of the roles and users that have access rights to individual items in the
content tree.

Change the ownership of an item.

Open the Access Viewer and the User Manager.

Sitecore configuration is divided into four layers:

Sitecore

Modules
 Custom

Environment

Order of configuration execution done using <loadOrder> settings.

You can assign access rights to an account on an item level. The following access rights can be
granted or denied to individual users or roles, or they can be inherited from the parent item.

A user can be a member of many different roles, and roles can also be members of other roles.

When a role is a member of another role, the access rights of both roles are combined to give the
users who are members of these roles the accumulated access rights of both roles.

Access rights – Denied overrides Allowed.

Access rights assigned to a user account override access rights assigned to a role.

Access rights assigned specifically on an item override access rights specified for the descendants on
the parent item.

Access rights assigned specifically on an item or on the descendants of an item override

the Inheritance access right.

When an access right is not specified, it is denied.

If nothing is specified for the Inheritance access right, inheritance is allowed.

Denied overrules Allowed.

Access rights assigned to a user account overrule the access rights assigned to a role.

Access rights specifically assigned to an item for a user account overrule the access rights that are
specifically assigned to an item for a role that the user is a member of.

Specifically assigned access rights to a user account overrule specifically assigned access rights to a
role that the user is a member of.

Access rights specifically granted for an item, to either a user or a role, overrule
the Inheritance access rights and any rights assigned to the descendants of the parent item.

If you select a different domain than Sitecore, you must set the read/write permissions on
the Languages node for one of the base roles or for the Everyone role for that domain.

The Sitecore/Everyone role is assigned to all users and roles, which means that they
have Read access to all items by default.

Remove Inherit – this sets the Inherit right to Denied for the ‘*’ (Everyone) role. In this way, the item
or its descendants do not inherit any security rights from any parent items.

Require Login – this sets the Read access to Denied for the extranet/Anonymous user. In this way,
you can require extranet login to access the item and its descendants.

Protect Item – this makes the item unavailable for editing. For example, you can protect an item if
you want to make sure that a user cannot accidentally delete an important item. Only an
administrator or a user that is a member of the Sitecore Client Configuring role can protect an item
and unprotect the item again.
Remember that the user can be a member of multiple roles, which can have access rights that
overrule the access rights that you have just assigned.

In the Security Editor, you can see the access rights that are assigned to an account, but from the
Access Viewer and from the Content Editor, you can see the full result of the combinations of access
rights for an individual item.

Because items by default inherit the access rights from their ancestors, you never have to actually
grant an item the Inheritance access right.

An Inheritance access right that is denied to a role or a user overrules the Inheritance access rights
specified on other roles or users.

Access rights explicitly granted for an item, on either a user or a role, overrule the Inheritance access
rights and any rights assigned to the descendants of the parent item.

Explicitly assigned access rights on a user account overrule explicitly assigned access rights on a role
that the user is a member of.

Deny an account all access rights to an item and its descendants.

You can restrict access to the client in the following ways:

Disable IIS anonymous access

Disable Forms authentication

Deny access to the Copyrights folder

In a multi-server setup, you must manually add the new security domain to the Domains.config file
on each server.

Sitecore will add the anonymous user to a new domain only when you restart Sitecore.

You cannot change the domain of an existing account.

A security account can only be assigned to one domain.

In a locally managed domain, the users and roles are domain specific and the users can only see the
items in the domain that they belong to and not the other domains in the system.

When you delete a domain, the security accounts that belong to the domain are not deleted. To
make sure that you do not have accounts that cannot be used, you should either delete the users or
roles or make sure that they are members of another role that belongs to a domain.

Web database contains the live content of the website and is subset of the master database and
optimized for size and speed.

Master database is the authoring database - it contains all versions of content.

Sitecore uses data templates to define structures of item.

Republish will publish every item no matter whether it is changed or not. It is intended to be used
when you are publishing a new site first time.

Smart Publish works smartly by comparing each item in the master database with the item in web
database.
Incremental Publish - Every time an item is changed, it is added to the publishing queue.

In Sitecore content authors have the ability to make a piece of content version able. Each version of
an item begins as a replica of the original or of another version and are all stored in Sitecore.

Standard values are a way of having default or fallback values for fields in Sitecore, meaning that
when items are created, you can specify a field value that should be used by default.

Sitecore always stores field values as plain text in the appropriate Sitecore database.

FieldType and values stored as below

checkbox 1

checklist {E00D9E00-2582-4022-88AE-151CE3CD7C41}|{858D25B3-B8A6-4ED1-B6F8-
B52C4CC0EFDF}

date 20051003T120000

datetime 20051003T163256

file /images/extimages/outh gif

html This is some example HTML content.

icon /sitecore/shell/Themes/standard/carousel.png

image <image alt="Alternate text" width="150" height="150" hspace="4"vspace="4"

mediaid="{XXXX}" showineditor="1" usethumbnail="1" src="/upload/px.jpg"/>

internal link /sitecore/content/Home/Sample Forms

layout

link

lookup {858D25B3-B8A6-4ED1-B6F8-B52C4CC0EFDF}

memo This is a test.

multilist {632511FF-5E1D-4820-8379-CA5923328603}|{E00D9E00-2582-4022-88AE151CE3CD7C41}
password asdjlk

reference {0D45476E-F67C-4F14-9B4E-C26D53F6EC48}

security extranet|{A365D840-553C-4E76-9DFDAC3BB58E80A1}|8||extranet|{24918F00-C53F-40D9-
A8EBDD25EBB131F9}|8448||

server file /global.aspx

text Text field

tree {DB290BF5-0D3E-41FA-8C0F-DDBBE4EEF68B}

tristate 1

Droplist data type only stores the string value of the item that was chosen by the content editor,
while Droplink stores the GUID of the item that was chosen by content editor.
Pipelines define a sequence of processor that implement different functions such as handling page
requests, to uploading files and saving items through the UI.

Each processor in a pipeline contains a method named Process() that accepts a single argument and
returns void.

Sitecore separates the pipelines into two groups: those defined within the
/configuration/sitecore/pipelines and /configuration/sitecore/processors elements in the web.config
file.

Under configuration/sitecore/pipelines in web.config pipeline defines Sitecore context.

Advantage of using display name fields are:

 Display name can include characters not allowed in item names.

 Display names can vary by language while item names cannot.

By default Sitecore allows alphanumeric, $ and – character in item name. You cannot use any other
special characters in item name.

In case if you want to allow some special character in item name, then you need to change
ItemNameValidation setting value in web.config file.

Sitecore uses log4net API to log all the events and information. By default Sitecore create date wise
logs in log folder.

CheckboxField isMenuNavigation = pageItem.Fields[“isMenu”];

Sitecore.Data.Database db = Sitecore.Context.ContentDatabase;

Item currentItem = Sitecore.Context.Item;

Sitecore.Data.Fields.ImageField careerAreaImageFieldItem = randCareerArea.Fields["Image"];

image.ImageUrl = MediaManager.GetMediaUrl(careerAreaImageFieldItem.MediaItem);

Database db = Sitecore.Context.Database;

Database db = Sitecore.Configuration.Factory.GetDatabase(“master”);

How to display/render field value to support inline editing?

FieldRenderer.Render([Item],[FieldName]);

lblTitle.Text = FieldRenderer.Render(Sitecore.Context.Item, "Title");

Dynamic placeholder fix issue of repeating content when trying to use same placeholder name.

We can apply dynamic placeholder on page item using Experience editor.

Sitecore encounters a <loadOrder> setting, it loads the configuration files in this order:

 Folders and files that are specified in the <loadOrder> section load first, in the order they are
listed. In the previous example, the files in the Folder23 folder load first, then
the sitespecific.config file, and then the files in the Folder1 folder.
  Folders and files that are not specified in the <loadOrder> section load second. They load in
alphabetical order. Files that are placed in the root of a folder load before files within
subfolders.

Templates inherit from one or more base templates.

In Sitecore, creating the data structure means creating data templates, defining standard values,
assigning insert options, and creating content items.

You must create all templates in the Master database, not the Web or Core databases.

The data type of the field. This specifies which user interface control the Content Editor will display
to accept input for this Field.

Sitecore MVC Disable Web Edit @Html.Sitecore().Field("Field Name", new { DisableWebEdit = true })

Datasource Location field on the rendering definition item.

A Sitecore domain is a collection of security accounts (users and roles) that you can administer as a
unit with common rules and procedures.

A domain is used to collect security accounts that have some logical relationship, for example, all the
accounts that have access to use the Sitecore clients could be stored in the Sitecore domain,
whereas all the accounts with access to the published website could be stored in the Extranet
domain.

Extranet — this domain is a website security domain that contains the user accounts that
correspond to the visitors to the website. It also contains the customized roles that manage read
access to the content of the website.

Members of the Extranet domain that are also members of relevant Sitecore roles (for example,
Sitecore Client Authoring) can access the Sitecore domain and use the client tools to edit the content
of the website.

Sitecore — this domain is an internal security domain that contains all the users who can access the
Sitecore clients and the Sitecore Client roles that influence the functionalities that are available to
users. It also contains the customized roles that control the access that users have to items.

Members of the Sitecore domain can access the Sitecore client tools and edit the website if they
have the appropriate access rights. Furthermore, they may be able to access the Extranet domain
depending on how the developers and the security architect have designed the domain and the login
page.

Default – this is a virtual domain that only exists in memory. Sitecore is setup with Extranet as the
default domain and most user accounts will be extranet\anonymous when they visit the website.
However, if the website does not specify a default domain, then the users are set to
default\anonymous.
Sitecore expands the RedirectUri* and PostLogoutRedirectUri* node values with
{AllowedCorsOrigin} tokens to be allowed for every origin specified in the AllowedCorsOrigins list.

Source property provides information that influences the user interface control associated with the
field in the Content Editor. The behavior of the source field depends on the field's type.

The field data source item, equivalent to using a path as the field source property as described
previously.

The .NET classes and programming techniques developers use to access the field value, such as the
classes in the Sitecore.Data.Fields namespace, the renderField pipeline, and the FieldRenderer web
control.
Analytics field types are for internal use by Sitecore. Do not use the Analytics field types.

The Multilist field will fetch its values from an Item specified by the Source field property. A user can
"toggle" the Items between the two boxes and sort the elements in the right hand box as needed.

Children of the Item specified in the Source will populate the left box of the multilist field.

Sitecore.Data.Fields.MultilistField multilistField = item.Fields[sFieldName];

Fields of the type Attachment are reserved to be used internally by the Sitecore client. You should
not use fields of this type in your API code.

The simple field type, Checkbox stores it raw value as text.

Sitecore.Data.Fields.CheckboxField checkboxField = item.Fields[sFieldName];

The complex field type, Date or DateTime stores it values as raw text

Sitecore.Data.Fields.DateField dateField = item.Fields[sFieldName];

A field of type file holds a link to a file in the media library.

Sitecore.Data.Fields.ImageField field = Sitecore.Context.Item.Fields[fieldName];

Fields of the type Iframe are reserved to be used internally by Sitecore Client.

Sitecore.Data.Fields.LayoutField layoutField = item.Fields[sFieldName];

Password field are stored in plain text unless you process.

The complex field types, reference, lookup and tree stores the item the reference as text

Effective insert options control the types of items users can insert under existing items.

Sitecore determines effective insert options for an item from the assigned insert options.

Insert Option

Effective insert options include the list of data templates, branch templates, and command
templates that a user can use to insert new items under the selected item.

Administrators can assign insert rules in insert options to dynamically redefine effective insert
options for the user at runtime. Developers can implement custom insert rules for administrators to
select.

 Allow different users to create different types of items under existing items.
 Help users create a number of items with a single action in the user interface.
 Restrict the types of items users can create under existing items. This helps you enforce an
information architecture, which improves consistency.

In Sitecore, you can specify shared presentation details for all versions of an item, in all languages,
and you can specify different presentation details for each individual version of an item and for each
language.

In this way, you can present a different composition of the layout depending on the version and
language of the item. For example, in a multi-language solution, where you have different marketing
strategies or promotional offers that are relevant only for a specific language, you are not
restricted to display the same components for all languages.

When a Sitecore user's area of responsibility changes, the roles that the user is a member of
must also reflect that change. To do this, you must make the user a member of a different
and more relevant role or roles and remove the user from the role that they should no longer
be a member of.
To add role inside any existing role
Role manager -> select role -> member of -> add role
To add users on role

Role manager -> select role -> members -> add -> select user/role whatever wanted to add.

Sitecore.Caching.ItemsContext. It uses HttpContext.Current.Items to save the context Item. The

context database is in there as well.

Fields editing in Sitecore Experience Editor

In a simple text field, you can only enter text. The field automatically expands to fit the text you
enter.

In a rich text field, you can open a text editor from the floating toolbar. To open the Rich Text Editor
and benefit from more advanced editing functionalities, click Edit the text .

In an image field, you can insert various types of media. These could be animations, film clips, sound
files, and so on.

In a link field, you can add and edit various types of links, such as internal links, external links, or mail
link.

In a date or datetime field you can set and change the date and time.
Compatible renderings are renderings which have identical datasources (or no datasources) and
placed in the same module. These conventions ensure that there will be no unwanted dependencies
between feature modules from Compatible Renderings fields.