7 MUSTs for building Sitecore experience-editor-ready websites

For some years now the Experience Editor is the recommended way for editing content with Sitecore. It`s intuitive, easy-to-use, and most of the content editors prefer to use it rather than the Content editor which is more often used among the developers.

It`s up to us the Sitecore devs to make content editors` Sitecore experience better and to optimize the process of content entry end edit.
Placeholder settings item

Following the listed guidelines will make our editors` job easier:

  1. Always set meaningful name to your components!

    The names of all components should indicate their purpose. Avoid using pascal or camel case names – they are understandable just for us 🙂

    Bad examples:

    • Product
    • cookieDisclaimer
    • Meta

    Good examples:

    • Page Title
    • Rich Text With Border-Top
    • Page Metadata
    • One Column Container
  2. Don`t miss the Datasource Location and Datasource Template when creating components!

    • Datasource Location specifies where the editor is allowed to look for the data source when using the Experience editor.
    • Datasource Template specifies the types of data sources users can use.

    Both fields are required for building smooth experience for the editors and save them from traversing the entire tree while searching for suitable datasource for a component

  3. Always use placeholder settings!

    For each of the placeholder you define in your code you should create a placeholder settings item under “/sitecore/layout/Placeholder Settings”. Placeholder settings items indicate which components are compatible with your placeholder. Not every component is compatible with a given placeholder so this setting will save your implementation from rendering errors and not expected layout behavior.

    Placeholder settings item

  4. Set a Thumbnail!

    The image in the Thumbnail field is shown in the “Select a Rendering” window when adding a new component to a page. This field usually has an image showing how the component looks like. For that reason, you can use “Take a screenshot” function and directly make a picture of the component on the page. Using that field helps editors to intuitively choose the right component for the current placeholder.

    Thumbnail field

  5. Don`t be afraid of using Rendering Parameters!

    You should use Rendering Parameters to control the way a component shows on the page – to change its shape or layout. If you have a component that needs to support different sizes or background colors for example, Rendering Parameters are the best way to implement it. It`s conceptual mistake to use the datasource item to manage the way a given component looks. The datasource items should only manage the data (the content) while the Rendering Parameters control the presentation.

  6. Use the field title!

    In many cases your template fields` names are prefixed with a namespace or are too short and not so descriptive. In this scenario, you can use the title field of each field to give a really meaningful name which will not confuse the content editors.

  7. Define compatible renderings if there are any!

    The Compatible Renderings field is used to connect two or more components that are compatible in the same placeholders and may have the same datasource type (if the component uses datasource). This feature is widely used for scaffolding components. If a component has compatible renderings set, the editor can switch between them with just s single click.

10 Things You Should Know About Sitecore Upgrades


Almost every Sitecore developer needs to perform Sitecore upgrade at some point. Unfortunately, the process is heavy and there are lots of failure points and tricky parts.

In that blog post I will share some of the most important things that I learn while performing Sitecore upgrades.

  1. Do not start without an upgrade assessment and an action plan!

    Sitecore upgrade can take between 20 and 300 (or even more) hours depending on many things like how far is your
    current version from the target version, how many Sitecore customizations are in place,
    how much data is stored in the Analytics database etc. Every single thing matters, so do not start an upgrade before having
    a good action plan.

  2. Upgrade incrementally!

    Always perform Sitecore upgrades incrementally: you should go through every single revision between your starting and your target Sitecore version. Do not try to use shortcuts.

  3. Patch the configuration files!

    Following the Sitecore best practices every single change that you have in the Sitecore section
    of web.config (or Sitecore.config in the later versions)
    should be applied via
    Sitecore Include Files.
    This is good but not every project follows that guide and in some cases the changes are
    applied directly to the web.config which makes your upgrade process a nightmare.
    It`s always better to spend some time on applying the changes under the Sitecore section using patch include files before starting the actual upgrade process!
    Try to keep your web.config (Sitecore.config) as close to the original one as possible.

  4. Always back-up!


    You never know what can go wrong while upgrading Sitecore! You should have this in mind and create a backup of your files and database on every single revision that you go though.
    On top of that keep your backups a certain time after you finish the upgrade process – some problems can appear when the users start to exploit the upgraded system.

  5. Each server counts!

    When upgrading Sitecore you should perform the upgrade steps for each server: CD, CM, DEV, QA, STAGING etc. If you want to reduce the upgrade time you have the option to
    try to make some of the servers equivalent: for example, if you have CD, CM, DEV and QA servers you can try to merge the content of the DEV and QA instances. In this way, your
    QA and DEV instances will be pretty much the same: having the same content. In this scenario, you will need to perform the upgrade for DEV and QA just once.

  6. Check the pipeline processors!

    When customizing Sitecore pipelines always play a main role. If you have custom pipeline processors you should check if they are still compatible. You also may need
    to change the pipeline that you are using to apply your customizations.

  7. Check the search implementation!


    Sitecore offers different search options Lucene, SOLD, Coveo etc. Each of them hides compatibility problems that should be covered prior to starting the actual upgrade process.
    Have in mind that some parts of the Sitecore Content Search API are different for the different Sitecore versions. It`s the case for the search configuration as well.
    In some cases you may need to implement your search functionality from scratch! This should be added to your upgrade estimate, right?

  8. Check third-party services integrations!

    Sometimes Sitecore is just a piece of the whole puzzle. You may have Geo Location, Translation, CRM, eCommerce services integrated with your Sitecore solution.
    Check all of them and especially the Sitecore API each of them uses for integration. You should be able to predict compatibility/integration problems in advance!

  9. What about the modules!?

    Go through every single Sitecore module installed. Some modules need to be upgraded as well, other are deprecated. For instance, Sitecore Social Connected, Language Fallback and
    GeoLocation modules come with Sitecore out of the box for the later versions.
    You even may need to implement a functionally that was covered by a module which is not available for your target version.

  10. Plan content freeze period

    In a perfect case scenario, your content team should stop entering content while you are performing the upgrade. Cool but in many cases this is not possible.
    Imagine a news website to stop showing news for a week or even a month. Not good, right. In this scenario, you should evaluate content migration strategy.
    With some clients manual copy/paste would fit but usually it`s not the case.
    The tool that I use in situations like this is RAZL. RAZL allows side-by-side comparison and merge between two Sitecore instances.
    The two Sitecore instances do not need to have the same Sitecore version so the tool works out perfectly for content migration.

  11. Enjoy!

Hedgehog ist ein Berliner

Hedgehog was invited to participate at the #SUGDE event on 29 September 2016. The only available speaker was me so I started packing my bags.

We took off together with Stefan Ivanov our Business Development Manager. It was the first journey to Berlin for both of us and we were very exited about it! The flight went smoothly and we arrived in the capital early in the morning. Of course we did not miss the opportunity to take a selfie in front of the
Reichstag building


We had some time to walk around and buy souvenirs and presents for our friends. Berlin is a really beautiful city and the time that we had was not enough for me. I will definitely go there again!

We arrived at the #SUGDE event place at about noon where we met Chris Wojciech – one of the #SUGDE organizers and the person who invited us.

After some snacks and of course Sitecore discussions, the event began.

The first session by Sebastian Winter was about Sitecore upgrades. It was a very interesting war story about the upgrade case that he had with the complicated infrastructure of Metro Sebastian shared some good practices that he followed during the upgrade process.

Just after Sebastian it was my turn. The topic of the session was “Continuous Integration and Continuous Delivery ” with our products TDS and Razl.


Most of the people at the event already were actively using TDS but Razl was pretty much new for them. I went thought TDS new features that came with the latest version and how Razl can be used for moving content between different Sitecore instances.


I think that the presentation went well since I received good feedback from the public.

The next presentation was about NitroNetSitecore by Lars Schilling. It was a very interesting session about a new paradigm for building Sitecore components.

Just after, Christopher Huemmer walked us through Sitecore Multisite implementation best practices.

The last session for this #SUGDE event was by Friederike Heinze. She did a recap of the Sitecore Symposium in New Orleans. I did not have a chance to go to the Symposium and I found out that I`ve missed a lot. Next year I will definitely go there. It will be in Las Vegas which makes it even more interesting!

By tradition just after the event we all headed to a German beer house where I tried German homemade beer – the taste was really wonderful.


There Mark Cassidy received a plushy hedgehog.


On the next day we joined October fest just for a beer


Just after, we took off back to Bulgaria full of good impressions and memories!

Sitecore Taglist Field

Recently I had the task to build a Sitecore Content Editor field which will be used for tagging content items.

The requirements for the field were:

  • Easy-to-use
  • Search-friendly (especially when working with large collections of items)
  • Autocomplete support

After certain time spent in research I found a jQuery plugin which pretty much satisfies the requirements: jQuery Chosen

The clients accepted the proposal and I my final task became: Integrate jQuery Chosen into Sitecore Content Editor.

The first thing that I had to do was to include jQuery Chosen source files (JavaScript and CSS) into Sitecore Content Editor.

My original idea was to add the files dynamically while rendering the field itself. Unfortunately this plan failed: The files were added dynamically but I introduced a bug as a side effect: When you click on a content item that has my custom field, the content editor was blinking 2 – 3 times before rendering the fields.

This behavior is unacceptable and I had to switch the strategy.

Then I found a really good blog post by Pavel VellerInjecting Resources into Sitecore Content and Page Editor. This approach was adopted and finally I had the source files included into the content editor without any side effects:


The next mission was to write the field`s back-end. I tried to inherit from multilist field but this did not work out well. Finally I used “Sitecore.Web.UI.HtmlControls.Control” as a base class and decided to render the html select element myself. This time the plan succeeded and finally I had everything in place!:


I don`t like how I have to evaluate HTML/CSS/JavaScript code from the back-end but this is the way to go when building Sitecore Content Editor custom fields.

Now I was almost ready: I had just to add the field in the Core database and register the assembly in the section of Sitecore.config:



This all story resulted in a multilist-like, good-looking, autocomplete field for Sitecore Content Editor!

The source code is available at GitHub: https://github.com/Bilyukov/SitecoreTaglist
You can find it on Sitecore Marketplace as a module as well:


Sitecore Publish Status Module

When you work with many items in the Content Editor in Sitecore sometimes it is difficult to track which version of a particular item is published. It becomes even more difficult when you have many languages in the current Sitecore instance.

This problem inspired my colleagues Alex Kamburov, Nikola Gotsev and me to develop a module that simplifies the content editors` work.

Publish Status Module adds a panel in the Publish ribbon of the Content Editor. When you select an item in the Sitecore content tree you can immediately see the current publish status for the English language and also there is a button to see the publish status for all languages.

There are 6 different statuses for an item:
1) Latest is published
2) Not latest revision
3) Not latest version
4) Not published for language
5) Not published to database
6) No publishing targets


Publish Status screenshot



The module supports Sitecore 7.0 and above including Sitecore 8.




You can download the module form Sitecore Marketplace:


The source of the module can be found at GitHub:



ASP.NET MVC 5 Route Attributes

Step by step Microsoft has switched their main web technology during the last few years. Web Forms with its component model is now replaced by the Model-View-Controller design pattern. Web Forms is not deprecated yet, but my personal opinion is that it is just a matter of time. The main reason of keeping that technology alive is the fact many CMS-es are built on top of it. Once these systems fully support MVC and switch their main stream to it, Web Forms will follow the faith of it`s fellow WinForms.

Continue reading “ASP.NET MVC 5 Route Attributes” »

JavaScript Prototype Based Inheritance – Magic Revealed

JavaScript becomes more and more widely used language – not only for front-end but back-end (Node.js) too. Almost every web project contains thousands lines JS – layout and animations, AJAX calls etc. Talking about web we cannot skip the modern single page applications where all the user flow and server calls are controlled by the script language.

When we have so much logic implemeted in JavaScript we need a really good code structure, readability and reusability, don`t we?

Nothing can do this job better than the object oriented programming!

In JavaScript the object oriented concept is realized using JavaScript prototype. The simplest and probably most understandable explanation of prototype is:

In JavaScript the prototype is a shared object withing all the instances of a given class.

So we use this “shared object” to achieve inheritance.

In the image bellow I defined a class Animal


The constructor takes a config object with age and name fields. Age is kept as a private class variable and name is stored as a public class field. Private scope in JS is achieved using var keyword. In this way “_age” lives just in the scope of constructor function Animal and behaves like a private class field. I defined two functions getAge and setAge to manipulate the private field “_age”. Have in mind that you can add functions and properties to the prototype of a given class outside it`s constructor:


Note: Using this approach we do not have access to the private class field (in our case “_age”).

Now we have class Animal with one private and one public field and 3 functions.

Let`s inherit the Animal Class:

The key of inheritance here is the line:

Cat.prototype = new Animal();

Another words the prototype of the class Cat becomes and instance of the Animal class and in this way it has all its fields and functions.
One very important part of all the magic here is to pass the configuration object to the Animal constructor:

Animal.call(this, config);

I added function sayMiau and breed field just to show that Cat can have it`s own functions and fields.

Let`s do some tests of the written above:


In JavaScript we can even modify the prototype of native objects.
In the next example I extended the String prototype by adding the c#-like format function:


You can see the code of all the examples here: