Page Editor Experience – Add a Thumbail Image to our Presentation Component

Leave a comment

This tip, was given to me by my senior and colleague Nilesh Thakkar. He blogs about his Sitecore Journey, at

He said, some things are not compulsory to be done, but good if they are done to make it easy for the client. Like say add a thumbnail image to your presentation component. How? Lets have a look.

We already know “A Picture is worth thousand words” so yes, we got to agree upon what Nilesh Thakkar says! So, lets see, how it can be done and how helpful can it be for our clients/users.

Setting up a plot:

Lets for example say, we have a Blog to manage in Sitecore. We have already created a few presentation components for various sections of the page as below.

Header Section:

  1. Blog Header
  2. Blog Search

Left Sidebar Section:

  1. Blog Roll
  2. Recent Comments
  3. Recent Posts
  4. Featured Posts
  5. etc..

Main Content Section:

  1. Blog Article Summary
  2. Blog Article
  3. Article Share Tools
  4. Blog Comments

Why Add an image to Presentation Component?

For any Page Editor user, it might definitely be very easy if there is an image, depicting what that particular presentation component does.

Now, lets say, a user is configuring a Blog Landing page, and is confused between two presentation components — Blog Article Summary and Blog Article. So he/she can add it to a page, configure a datasource to it, and see how it looks. We developers always unit test various scenarios whenever we develop some code, to make sure it works well. So instead of, the page editor user has to configure and check, if we add an image of that component while testing, wont it be a great idea?

How to add it?

Let’s say, the Blog Article Summary component looks like as below:


while the Blog Article Component Looks as below:


To configure its thumbnail lets go to the Presentation Component (sublayout in this case) in the content tree.

Make sure that Standard values checkbox is checked in View Tab of the ribbon.


Go to the Appearance Section and find the Thumbnail field in it.


Upload an appropriate Thumbnail image, suitable to the component as well as that makes it recognizable while adding it through the page editor.


Save the item, and now, lets go to the Page Editor mode and click the Components button.


Lets click on “Add to here” so that Select a Rendering dialog opens.


As we see above, the Blog Article Summary component is self explanatory, it becomes pretty easy for the Page Editor users to identify and select it if they want to use it.

So simple it is to make someone’s life easy, by applying a very small effort,  in a right direction. And according to me, that is what a developer is for — to make the life of normal people easy, in whatever way possible, by making great technology.

Happy Sitecoring! :)

Placeholder Settings – Empower your Page Editor Users – Part – 2

Leave a comment

In the part one of this post, we saw what a Placeholder Setting is and why is it good to use Placeholder Settings in architecturing of our Sitecore Projects. In case you missed it, have a look at it here –  Placeholder Settings – Empower your Page Editor Users How to Setup Placeholder Settings? Suppose we are developing a Site with a blog. So lets configure various elements considering that blog has the following  layout:


Various presentation components that we need for the blog are as follows:


Next, lets create a Placeholder Setting item. At the location /sitecore/layout/Placeholder Settings right-click and say insert Placeholder.


Now, we can have the following components in our left Sidebar:

  1. Blog Roll
  2. Recent Comments
  3. Featured Posts
  4. Recent Posts
  5. Subscribe to Blog
  6. Blog Stats
  7. Blog Authors
  8. Blog Archive

So lets add them in Allowed Controls of the setting.


Please note, that in the above screenshot, we haven’t specified any Placeholder Key. This means, it is a Data-Template Placeholder Setting. So, we need to add this setting to the Presentation Details all the blog related items (ideally to blog related template’s standard values).

[Moving a step back from our configuration step, lets discuss why we used a Data-Template specific setting, and how beneficial can it be in our case. The advantage of making a global Placeholder Setting, is that we have the Placeholder Key already specified in the Setting and we do not need to add it to the Presentation Details of that of the item or template standard values. Sitecore identifies, where to apply it, based on the Key that is specified in the Setting. But, its good to use it only if the site follows a single main layout.

Taking our current case of that of the Blog Section of a Site, we are using Sidebar with the key leftSidebar. Lets say, we make this setting as Global, and we have the same key in different layouts for other Site Sections (say Our Services Section) , then these Blog related Presentation Components, will be available for Page Editor users, to be added  in Our Services Section, which is conceptually wrong. So to avoid such cases, whenever we have multiple layouts section-wise its always good to create Data-Template specific placeholder settings. Also, in a case where we have a website setup, and we found later that Placeholder Settings could be useful for us to use, its preferable to make it Data-Template specific instead of Global Placeholder settings to avoid major level of testing into it. ]

Coming back to our How to configure Placeholder Settings, adding the Sidebar Placeholder Setting item, to the Presentation Details of the Blog Section Template’s Standard values and specifying the Placeholder Key as “leftSidebar”.


Once added, it can be seen in the presentation details of every item of that template and when we can click on it, we can see the controls that can be added to the specific Placeholder Key, by our Page Editor Users.


Once this is done, we can start adding components to the left Sidebar. Say we have added Blog Archive.


And some of the following (Recent Posts and Featured Posts) might be added by client in future, so he/she doesn’t need to depend on us, or come to us to get it added. Their Page Editor users can do the same as follows:


As we want to add a new Component, that of Recent Posts, above this blog roll component, we click on the Add to here button above it. Note that, when we hover over the Add to here button, here’s what we see:


The Placeholder’s name is replaced by the Placeholder Setting’s name. And now, on clicking it, we get all the allowed controls.



I’ll Select the Recent Posts Component, and that’s how it looks on my page, in Left Sidebar.


Hope you enjoyed the couple of posts on Placeholder Settings? Lets make use of various things, simple in use yet very powerful features and make situations for our clients and stakeholders easy!

Good Reads:

Happy Sitecoring! :)

Placeholder Settings – Empower your Page Editor Users

1 Comment

While binding the Content with its presentation, we have two terminologies, Static Binding and Dynamic Binding. Know more..

In this post, we’ll see how Sitecore adds one more level of abstraction over binding Content with its Presentation Components, empowering both – the Developer as well as the Page Editor user – and moving to a simple and very effective solution. I have added this to my list of reasons for Why I Love Sitecore. For anything that we do, we have 3 questions in our What, Why & How? So lets start getting answers for these questions.

What are Sitecore Placeholder Settings?

A Placeholder setting is linked to a Placeholder key and adds a level of abstraction while binding a presentation component with the corresponding content.  In a Placeholder Settings item, we give it a name so that it can be easily identified — for which specific location would it be made — and specify a number of sublayouts and/or renderings in it, which are appropriate according to the design changes of the current website. They are of two types:

  1. Global Placeholder settings
    • Placeholder Key is specified in the Settings item.
    • Does not need to be attached to Presentation details of various Template’s Standard Values or that of items.
    • Sitecore by default identifies if the placeholder key mentioned here is present on the page, and allows us to add the controls allowed here to be added to the page.
  2. Data Template-specific Placeholder settings
    • Placeholder Key is Template specific.
    • Placeholder Key needs to be specified while adding it to the Presentation Details of Template’s Standard values or that of item.

Why Sitecore Placeholder Settings?

  1. It empowers the Page Editor users, to make the necessary design changes at required locations, without being dependent on the Developer.
  2. It relieves the Developer from the hassle of going back to the client site, just to make simple design level changes.
  3. The components that can be added at any location in a website, are specified in the allowed controls of it. So the Page Editors  can select the ones out of them. This not only helps them in selection for which component they want, but also makes sure that an inappropriate component is not added to a location where it should not be. (Lets say, in case of a blog, we have a left sidebar, with components of Recent Posts & Recent Comments. We can have a Placeholder setting, for left sidebar with other allowable components along with the above, say Blog Roll, Blog Archives and link it with the data template to avoid a component of main blog post to be added to the left sidebar)
  4. Ideally, Placeholder settings should be configured before various presentation components are bound to its corresponding content. But in case that’s not done, they can be easily plugged-in whenever we want to, with a little effort, by understanding the broad-level architecture of the site.

In part 2 of this post, lets see how to configure Placeholder Settings.


Happy Sitecoring! :)

Sitecore Beginner – Static and Dynamic Binding

Leave a comment

As a Sitecore beginner, we are very eager to know more and more about Sitecore.

The Content:

We first create the templates, which defines the structure of our content. — What all is needed Next, we create all the required items from these templates and fill them up with the required content. Know more..

The Presentation:

Next, we create layouts (ASPX Files) and sublayouts (ASCX User controls) defining the structure of the pages of our website. Sitecore, offers us the opportunity of code reuse, and hence, its always a good way to create our presentation components in such a way, that we can make most reuse of our presentation items. Know more..

Binding Presentation and Content:

Now, we know that our content is ready in the content items, and how our data will look is ready in our presentation — layouts and sublayouts.  So what remains is mapping our content on our presentation items, so that it is displayed on a page in a website. We have two ways of doing it.

Static Binding:

Static binding, as the name suggests, is something like hardcoding a value on a page. Its like knowing at compile time, what component will be rendered at which location. Lets take an example. In our website, we might have some portions on a page, which are common for all the pages, or atleast for some pages. Say a control which renders the company logo, or the search bar, or say the navigation component, or a footer with copyrights or social media icons etc. This is to make architecture of a site quite simple, in case of all those components and renderings, which are required on all the pages. Instead of taking the pains of adding them to each page individually, they can be added directly to the main layout — the main aspx page, responsible for the rendering — and thus save our as well as content editor’s time, in linking them to various content items, individually. An example of Static binding is as follows:

<sc:rendering id="Navigation" runat="server" renderingname="SiteNavigation"></sc:rendering>
<sc:sublayout id="Search" runat="server" path="/layouts/global/SiteSearch.ascx"></sc:sublayout>

Dynamic Binding:

Dynamic binding, goes by its name. Various page components, — renderings and sublayouts are bound to their respective content, dynamically, on runtime. The binding takes place using placeholders — various placeholders as per requirement are added to the layout and the sublayouts, and different required presentation components, are assigned the placeholder key as per their rendering location. This is way, the rendering location of the various presentation components, can be managed as per requirement, and changed on runtime.

<sc:Placeholder runat="server" ID="phleftSidebar" Key="leftSidebar" />

This way, Sitecore Supports better modularizing of your application as well as code reuse.  Again, to avoid adding various presentation components to each and every item of your site, its good to configure and add the bindings to the Standard Values of the respective item templates.

As far as using both the above is concerned, there isn’t a best case or worst case. Using them at appropriate locations of our site is the key and we can design an architecture which is best suited for our case.

Good Reads:

Your Sitecore Blog gets a new name – Sitecore Endeavor

Leave a comment

My dear Sitecore Lovers,

Your very loved Sitecore Blog, gets a new name today – Sitecore Endeavor.

What? You have three questions in your mind – What, Why and How? Well, lets know more about it then.

What was the name previously? What is Endeavor? What is Sitecore Endeavor?

Previously, there was no particular name of the blog, it was simply called .Net Sitecore Blog. Endeavor means, an attempt to achieve a goal. Sitecore endeavor means, an attempt to achieve a goal, in the Sitecore Community.

How Sitecore Endeavor?

I thought a lot for a suitable name the blog.  After a lot of effort and discussion with my friends Muktesh Mehta and Sandeepkumar Gupta, the word Endeavor came to be worth it.

I thank Muktesh and Sandeep from the bottom of my heart to get us with a rightful name for the blog.

Why Sitecore Endeavor?

The reason I started blogging on Sitecore and Dotnet related stuff, was with an intention of sharing as much information as possible with various developers, about any issues I face and their solutions that I find on various forums or I try to get it myself. The reason was about sharing my experiences of working with various things, and to avoid DRY (Don’t Repeat Yourself) rule, for any other developer, because a Developer’s time is very precious!

Sitecore Endeavor is, my attempt to achieve a goal, specifically, my personal goal of sharing as much information about Sitecore that I have with the Sitecore Family!

Let’s all of us say,

Happy Sitecore Endeavoring! :)

Benefits of Setting up Sitecore Developer Box Loosely-coupled

1 Comment

Hi Friends,

In the previous post we saw how to setup a Developer instance in less than 5 minutes. In case you missed it, do have a look at it here.

Traditionally, in Sitecore setups, we used to have a tightly-coupled webproject-sitecore instance relationship, wherein the Project and Sitecore instance used to exist in the same folder — with Sitecore folder inside the website folder.

But, when loosely coupled, it helps us get various benefits, but 4 main which are worth discussing:

  • Multiple website projects can point to the same Sitecore Instance.

Suppose, we have a multi-site instance, with a few websites on it, a main website, an intranet site a blog and a few country websites. If tightly-coupled, all of this would obviously be under the same webproject. But, in loosely-coupled architecture, all of these can exist as different webprojects altogether, if the need be. Also, if we have a new website to be added, we can create a new webproject instead of adding complexity to the existing projects. In this way, not only our code can remain decoupled, but we can also take advantage of multiple development projects running in parallel at the same time quite easily. And yes you are right, if one of the webproject has a build failure or some issue due to which it is down, it does not affect other webprojects or the Sitecore instance on the whole. Useful right?

Oh you want to know how can we do it? Simply create a publish profile, in each project that points to the Sitecore Solution URL as we saw in the previous post

  • No change in debugging a Web project

Debugging the Web project/s remains the same whether we use a tightly-coupled architecture or a looseely-coupled architecture. Yes, you are right, we first make the Sitecore instance up and running, and then attach the Visual Studio Web Project to the W3WP process and start debugging.

  •  Sitecore Upgrades become easy

Whenever we want to upgrade a currently running Sitecore instance, lets see how easy it is. We already discussed above, that in a loosely-coupled architecture, its good to create a new website for each webproject. So going by that, we would already have a Home item, which was added during installation of the Sitecore instance. So we would use the URL that we used to setup the Sitecore Instance instead of any webproject specific URL and upgrade the Sitecore instance.

Once the Sitecore upgrade is successful, we have two steps to perform for each of the webprojects we have configured for a given Sitecore Instance.

    1. Replace the Sitecore specific DLLs in the Libraries folder of each of the Web Project
    2. Rebuild the project.

The best thing here is, if say we have used a method/function in a project which has deprecated or discontinued, we can make changes only to that without affecting other projects.

  • Easy to debug and solve in case of an issue

Lets consider 3 cases here:

1. The Sitecore Instance is down

So we have some configuration changes to our Sitecore instance, its unable to startup and do not remember what they were?

Do not waste time in finding and reverting them. Simply, Install a new Sitecore Instance(with the required version) and create a new Publish profile, pointing to this instance. We can also uninstall the currently failing Sitecore Instance and install the new one with the same name, to avoid creating a new Publish Profile.

Oh yes, good question, what about the items that we created?

Two options: Either we use the same Databases, or use TDS (Team Development for Sitecore) to sync our items between Sitecore and our SVN Repository, get them out from there and sync them to the new instance.

2. The WebProject is down

If say, one out of five webprojects is giving an error on accessing we can identify that its an issue with that particular Webproject. Ideally, Visual Studio would give us the necessary information if the build fails for the project.
If build succeeds but still the Sitecore instance is not up with that URL, then there might be some config change which might be conflicting. To get details about the error, lets make sure that we enable Debug mode in Web.Config of the Sitecore instance (to get detailed error) and put the latest .pdb file of the webproject (i.e. click publish again, and it along with other files would be available) into the Sitecore instance bin folder and start debugging.

3. We don’t know where the issue is – Sitecore Instance or Webproject.

This is a bit tricky, but we can find a solution with minimal efforts. If say, you have five websites configured in a given Sitecore Instance, then we would try out all the URLs for our local Sitecore Instance of these 5 websites.

If none of them works, that probably means, that our Sitecore Instance is down. So, lets follow case 1 and check again.
If atleast one of them works, means for all those projects the URL gives error, has an issue and we need to check building them again, or their configuration to find out the issue.

What? You came across yet another benefit that’s worth mentioning here? Well, please do that in comments, I will add that here mentioning you.

Happy Sitecoring! :)

Setup Sitecore in Developer Box in less than 5 minutes


My dear friends,

There are so many developers joining the Sitecore community and the first question that they have is how do I get set up my Sitecore Application, and get started. I got more than 20 requests on my email and Twitter, to help do so. I thought, why not write a blog with all the required basic details that helps everyone. So here it goes!

Developers who are getting started, have two main goals:

  1. Understanding Sitecore CMS (understanding Sitecore structure, creating templates, items, layouts and sublayouts)
  2. Implementing Custom Business Logic in a Sitecore Application (Backend Code)

Lets divide the complete process of getting started into 3 steps.

Step-1: Install a Sitecore Instance

There are 3 ways of doing this:

  1. Install using an executable available from the download section – Sitecore CMS
  2. Install using a zip file again, available from the download  section – Sitecore CMS . (We might require some installation steps, and hence we can refer to installation guide available in Documentation Section.)
  3. Install a Sitecore instance using Sitecore Instance Manager(SIM). It is a standalone application, which we can use to manage multiple instances in our IIS. The link to the document explains everything necessary to configure SIM, Installing a Sitecore application, and installing required Modules if any (say we want to install DMS, or say we want an MVC enabled Sitecore application)

For simplicity, in my local box, I have configured SIM as follows:
Instances Root Folder: C:\Varun\My-Setup-Sitecore-Instances
Local Repository: C:\Varun\Sitecore-Plain-Instance-Repository

With that, our Step 1 is over with this.

Now, the choice is yours.
If we are to start understanding the basic architecture of Sitecore, we can pause for now, create a few templates and items, layouts and sublayouts, and get some basics clear and then come back and continue with Step 2 and 3.
A couple of useful links that I found for the same:

  1. Sitecore 5 Basic Simple Steps Creating First Website
  2. Sitecore Self-Study Building a Very Simple Website

Step-2 Create a Visual Studio Project

As a Dotnet developer, we all know how to create a new Visual Studio Project, so there is nothing to explain here.
Based on our requirement, or based on what we want to have hands-on, we will create a Visual Studio Web project, either a WebForms Project or an MVC Project. (Make sure that if you have installed MVC module while installing Sitecore using SIM, select MVC project, otherwise select WebForms Project)

Next, we  need to do a set of steps over here:

  1. Delete the web.config and global.asax from the project.
  2. Add a new folder, call it Libraries and add Sitecore.Kernel, Sitecore.Client and Sitecore.MVC (if you have created MVC Project) and any other DLLs or third party libraries you want to use in this folder.
  3. Reference them in your web project.
  4. Add the Web.Config, App_Config and Global.asax from your Sitecore solution to this project
  5. Build the solution once.

In my local box, I have configured a Folder, where I create all the Visual Studio Projects as follows:
Visual Studio Projects: C:\Varun\My-Projects

Step-3 Deploy Visual Studio Project code to Sitecore Instance

We can do this, by creating a publish profile for our project.
Many Dotnet developers might know this, but still I would like to go in a little detail for this.

Once the step 2 is over,

    • Go to Build -> Publish [ProjectName] Or Right-click on the Web Project and click on Publish Option.
    • A Publish Web dialog opens as follows:


    • Click on the <New Profile>


    • Give a suitable profile Name. (Generally, we should create multiple profiles and name them as per our environments, like say LocalDeploy, SandboxDeploy, StageDeploy and ProdDeploy. But still, for understanding and trial purpose, any name would do.)


    • Next, in the Connection horizontal tab, select FileSystem to be your Publish Method, Select Local IIS in Target Location and select your Sitecore Solution (the one that you created in Step-1) to be connected.




    • In Settings, lets select Debug Configuration for LocalDeploy, while for other profiles, we need to select Release. Also, we should make sure that we don’t select any other File Publish Options.


  • Click Publish, and it will build the Project and send all other required files to the Sitecore Solution folder.

Also, for simplicity, we can go to the right-click in the toolbar above, and select Web One Click Publish and this small tool appears, which is very easy to use!



With that, we have setup our Sitecore Instance, Created a Visual Studio project and then connected it with our Sitecore Solution.

There are a number of advantages of having this type of architecture in our Sitecore Solutions.

  1. Sitecore upgrades become easy.
  2. If our Sitecore solution is down, its easy to identify where the issue is, whether its the Sitecore Application with some wrong configuration or our Custom Code from the Visual Studio Project.
  3. Again, if our Sitecore solution is down, instead of spending a lot of time getting it up, create a new Sitecore Instance, create a new Publish Profile and Publish your project changes.


So, from now on, lets make it a point to host our Sitecore Solutions in this way which is quite loosely-coupled and maintainable and easily manageable.

Happy Sitecoring! :)


Older Entries


Get every new post delivered to your Inbox.

Join 352 other followers

%d bloggers like this: