When it comes to building websites using a CMS, Sitecore is definitely the way to go! I have been building the frontend of websites in Sitecore for over five years and have not found any other platform yet that gives the flexibility to a frontend developer that Sitecore provides.

For me, building the frontend for Sitecore websites helped me realise the benefits of breaking your frontend code into modular components and smaller chunks, so I thought I would create a blog post to share the knowledge I have gained over the years.

1. Don’t write any code… (Just yet)

Thats right before you start writing a single line of code take a step back.

Look at the available assets you have.

Take into account the wireframes, how the Sitecore content is structured, the hierarchy of data, the designs, style guideline, typography and any other assets you have available to you.

With these assets you should be able to get an idea of how to break up your assets into logical functional areas which will ultimately form your Sitecore components.

I find sketching each component helps me decide:

What data and attributes are required informing the component’s object creation
How this should work in Sitecore’s Page Editor aka Experience Editor, do I need to create custom Experience Editor buttons so the component can be edited easily
What the widget should look like in different placeholders i.e in different location of the page

Are there common styles or functionality I can create using a single class or Javascript function

These are just a few of the things that I find useful to help me map out my frontend Sitecore build.

2. Everything is a component. All components are a module.

Everything you build in Sitecore is a component which can be added to placeholders in any location you define.

When creating a new component in Sitecore I find it easier to break all of my component assets such as LESS / SASS and Javascript into modules in my solution.

For example, if I have a Sitecore component I would have:

  • banner.ascx or banner.cshtml
  • _banner.less / .scss
  • banner.js
  • Here is a brief example of how I would layout my solution

Code snippet

As you can see from my Gist snippet, everything has a matching file of “example component” or whatever we decide to call our component.

Some files have underscores e.g “_file-name.ext”, this is a standard way of indicating this is a partial file which will build into my app.less / .scss and bundled into lightweight CSS file. The same thing would apply to the Javascript files.

By breaking out our component assets into separate modular files, this makes things easier to manage, update and package to different environments or even add to another solution to speed up the development process.

The same can be done with Sitecore packages. We can create our Sitecore package to include:-

  • Sitecore objects with all component Sitecore dependencies using “items statically” objection
  • Component files from the solution using “files statically”

By doing this we can pretty much install this components like you would a component from the Sitecore Marketplace.

3. Pick a CSS naming methodology

Over the years developing the frontend of many Sitecore websites I have found that sometimes you can get your pre-processor files or stylesheets pretty messy and unorganised.

Unorganised preprocessor files or stylesheets can lead to a world of hurt later on in a website lifecycle.

Enhancements, support and maintenance become a nightmare to manage as a website grows.

I found that using a CSS naming methodology can help massively.

At my current work place Kagool we have adopted B.E.M (Block Element Modifier) naming methodology, this helps us keep our CSS specificity low when building Sitecore components.

Everything is self contained and easy to maintain. This makes things such as support, enhancements and code readability easier than not having a CSS naming methodology.

If you currently don’t use a naming methodology I highly recommend trying one out, there some good CSS naming methodologies out there and these are just a few of them, OOCSS, SMACSS and B.E.M.

4. Build for Page Editor experience

Optimising for Page Editor, renamed to Experience Editor in Sitecore 8, can take some additional time right? Not if you build for Experience Editor first it won’t.

Some simple steps can help to reduce the time it takes to make sure you website works correctly in Experience Editor.

I find the best way to do this is to simplify your workflow and build with “progressive enhancement” in mind. You maybe asking yourself what do I mean by “progressive enhancement”…

Simply put build your component in it’s simplest form with base HTML and CSS and enhance the experience with Javascript if required.

For example, If I had a task to creating something as common as “clicking on an element to expand hidden content”

I know this is going to be an accordion which requires a show / hide feature, Javascript to function correctly and needs to fit to any placeholder that the accordion is allow to be placed in.

My challenge is not creating the accordion and its features, my challenge is how will the content editor create, update and modify the accordion in Experience Editor as the content is hidden by default.

This is when you add a little bit of backend magic into the mix and detect Experience Editor mode (if your not to sure how to do this there is an excellent blog post by Martina Welander you should check it out).

With Experience Editor mode detection in place this will allow me add a simple line of Javascript

This will allow me to disabled all accordion Javascript functionality in “Experience Editor” and simply stack all the content and show all of the things to the content editor.

When the content editor then switches to “page preview mode” they will see the accordion in all its glory.

5. Beware of Sitecore 8 prototype.js

Sitecore 8 uses prototype JavaScript library which uses the same “$” symbol as jQuery. This can cause quite a few problems with legacy code or simply bad code.

I have fallen into this trap when upgrading from Sitecore 7.x to Sitecore 8.x and it has caused me a mountain of pain and annoyance. However once I realised the problem it was easy to fix and made me think about how I write my Javascript to tackle this problem.

I simply applied the jQuery noConflict mode which resolved majority of the issues for legacy code to a degree, However I had to tinker about with some projects more than others).

Using “self invoking functions” and protecting the “$” in another method that can be used for example:

Code snippet

I have coupled this with the “Revealing Module Pattern” as outlined by “Addy Osmani” in his book “Learning Javascript Design Patterns” which is an excellent book to read. And if you want something quick to read you should checkout “Todd Motto’s” Mastering the module pattern.


So let’s recap at some of the stuff you just read (unless you skipped to the summary!)…

First I take all available assets and break out what things are reusable in terms of “data structure”, “look and feel” and “functionality”.

Then I create my Sitecore data structure (while drinking some good british tea) for the components I need with associated LESS / SASS files and Javascript files (this bit I normally do at the end so I have a no scripts fallback).

Use a naming methodology like B.E.M or SMACSS or any other preference you have in mind. This will help your code to become more readable and lighten the load on selectors.

Never underestimate the power of Sitecore’s Experience Editor. Building things well for the Experience Editor will go a long way, not only for your customers, but will help you understand the true power of Sitecore and help on your journey to becoming a true Sitecore master!

Beware of the “prototype.js” and protect your $’s with a noConflict, write your code in self invoking patterns and everything will be awesome!

So some very quick bullet points:

  • Don’t code, think patterns
  • Think modular code
  • Do code
  • Experience Editor power!
  • Beware the prototype (use a noConflict)

Hope you enjoyed the read 🙂


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s