Helix Principles Architecture: Part 2

How to setup your project for front-end developers.


In my last post, I have mentioned some thoughts on how to create a simple solution structure using Helix Principles. In this post, I would like to drill down a bit further. We will talk about where to store your CSS/JS for every feature and how to store them in your solution.

We are living in a totally different space where you have all the dedicated team around yourself to provide you the HTML/CSS/JS files. If you look at the Habitat site and solution structure, you will see that all of the assets are stored under Theming. Basically, Habitat provides us a single instance of the project to store all the required CSS/JS.

However, if you are working with a team of frontend developers, they will be checking out the whole solution along with Habitat.Theming project. They will be working daily on that project or at least setting up a gulp builds to create a main.css or any .css files.


There has to be a better way, right? After all, we are geeks. Our job is to make it better.

In my experience, I have created all the features under the website project under project folder. Something like this:


As you can see that for the frontend developers, all they have to check-in the files in this project itself. They can focus on the features listed here and push all the HTML/CSS/JS in. In this way, they are focused on one project only. So, does for the fonts for common and for each website:


Some of you might argue that why don’t we create a separate project for it? You can do it, but it will create another dependency on the project itself. For the website project, all the assets live at one place (even the default HTML file).

Let me know what will you change and how I make it better?

#sitecore #helix

Helix Principles Architecture: Part 1

Setting up your solution structure.

Nowadays there is a new facade of Helix principles and how to implement a solution based on it. Just to give you a brief, this is up and coming in Sitecore solution structure. The basics are these:

  1. Look at your website and broke it down to components (I am sure by now what I mean by components).
  2. These are going to be your features in the Helix solution architecture. However, there will be different views for this feature. So for example, if you have a Navigation, then this navigation can have:
    1. Primary.cshtml
    2. Secondary.cshtml
    3. Breadcrumb.cshtml
    4. Visual:
    5. 2017-05-17_1253
    6. You get the gist! Right? Good! Moving on…
  3. Now you have to look at the solution and decide what will go in Foundation Folder. Like this: 2017-05-17_1253
  4. As you can see there is a LocalDataSource project in which all the dependencies are listed which pertains to access the DB: Pipelines, Getting Item, ItemExtensions, you get it.
  5. Basically, you need to figure out what are the different way you can conglomerate various data points into one.
  6. Foundation layer does not suppose to change frequently. Heck! Why would you change the logical structure of getting the item from Sitecore DB?
  7. Lastly, there is a project folder which consists of all your sites. Even if you are creating one Sitecore site, it is a good practice to have a common site as your base site and a separate site. In this image, you will see the Common &Habitat project layout structure:

2017-05-17_1253   2017-05-17_1253

To wrap is up (been a long day), Helix setup might take some thinking to do and what really you want to achieve. But at the end of the day, it is a modular & clean architecture.


Sitecore DB Tweak

Some simple adjustments to the configuration of SQL Server can greatly improve the performance of the database environment.  Keep in mind that some of these settings may impact the backup approach you employ for MS SQL.

  1. Set the compatibility level to SQL Server 2008 (100) to take advantage of the latest optimizations.
  2. Ensure the auto-close property is set to false. This ensures that a page will only make one connection.
  3. Ensure the auto shrink property is set to false to avoid costly dynamic resizing.
  4. Ensure the recovery model is set to simple to avoid the high overhead of transaction logs.

Sitecore Helix Knowledge Base

I am trying to consolidate links for the Helix approach that Sitecore folks have created:

http://helix.sitecore.net/index.html (You should definitely start here!)





http://habitat.demo.sitecore.net/ (Habitat demo site)

https://github.com/Sitecore/Habitat (Habitat Git)

Feel free to add your links in the comments section.



Sitecore 8.2 Cheat Sheet

There are some posts out there which tell you about useful links in Sitecore. Such as here:




But, did you know Sitecore added few more tools in 8.2?

Support Package Generator

URL: /sitecore/admin/supportpackage.aspx


URL: /sitecore/admin/logs.aspx

Dependency Injection Configuration

URL: /sitecore/admin/ShowServicesConfig.aspx

Hope you bookmark these (:

#Sitecore #Success

Sitecore Indexing Issues

Part of the indexing configuration in Sitecore includes indexing strategies that you select from. These are C# classes that run at indexing time based on how you want the system to behave. The default strategy in a stock instance for the “web” database is onPublishEndAsync. This strategy uses the event queue to subscribe to the publish:end event. When raised, it triggers an incremental index update (i.e. not a full index rebuild but small deltas directly on the index).