Month: September 2017

Posted on

Journey with Helix

Hi There!  With new project I am getting an opportunity to work with Helix patterns, along with leading a team who is awaiting instructions and pointers from me, I am re-inventing and looking at sitecore from a totally different perspective.  Since, the whole sitecore world is moving towards Helix and embracing it, I was bent to take a step forward as well.  I am subtly nervous about this, but, hey, we got a a great team both internally and in community who would pitch in to help us take some decisions.

As I roll along, I plan to share what I learned and how we solved each question/concern that came up while implementing Helix for the first time ever.

Two of them so far.  Below are those noted and steps I took based on recommendations of my fellow super stars.  Do you agree? Do you have some totally different direction that we could lean towards.  I would look forward to getting some different thoughts around this.

  1. Helix does not support base page template and advice to have the page templates inherit from several interface templates instead.
    • Pain point – This would mean, every time there is a need for Global interface template to be added to all page templates, some one has to go to each template and add that in.  Hopefully, if architecture is planned correctly, this should not happen very often, but, yeah, I might have to install powershell for sure to do bulk operations very soon.  I can totally see it.
    • I had no option left at this time other than manually adding couple of those sections that are Global to all templates.
  2. Helix proposes to use a different project per feature/module, but, I guess I agree to use grouping instead to group tightly related siblings(I think you may call it that) in to one project instead.  For example, you have similar looking Hero Slider modules, but, we all know that there is not just one Hero on your website, you will have different flavors for this kind of modules.  So, instead of creating one feature project for each Hero, we tend to group them in to one Feature project instead.  Keeping this balanced, like not abusing it, but, at the same time judging each module case by case basis.
    • In this paradigm, I feel a little confused once in a while especially when Client says any module could be used any where on the site, well technically you could use any module any where on Sitecore, assuming not too many restrictions are placed using placeholder settings, but, saying all modules are Global kind of puts the categorizing in terms of Helix in jeopardy or confused state.
    • What I did to overcome this is – Think about different ways of grouping a module based on name of the module, fields/sitecore items in use for the module, where this module is likely to be used, what is the generic purpose of this module.  Few such questions I answered to myself to give clarity on naming the feature projects.  If the module seems to be really generic and not fitting in to any category, we would then plan to drop it under Modules project.  Again, being careful to not abuse this.

Will definitely bump in to more. Also, cool find, I see that the unit testing feedback provided on Helix/Habitat is pretty cool if you wanna check out

http://helix.sitecore.net/devops/testing/unit-testing.html

Posted on

Performance is the Key

Imagine yourself building an excellent functional website, but, it does not load fast enough, would people actually use the awesome functionality you pulled off.  The answer would be no! People are impatient and busy with their hectic lives and they would not care to wait 3 seconds that the functionality might take to load.  So, performance is a balancing act to make wise decisions when coming to impeccable functionality.  Asking the right questions and following the best practices around everything as much humanely or scope wise possible is the way to to go and key to success.  In the past, i did write a blog about performance gain in few steps which was more web site page load speed driven.  You can see it here

A different paradigm to bump up your site performance

This time around, I will highlight few key things you could do in improvising your Content management experience.

When building a sitecore site, considering the routine and daily chores of content author are the most important to ensure we are using full potential of what Sitecore has to offer with it’s platform.  But, often times this is forgotten along the way and more attention is given to how the website looks, feels and functions.  It is important to ensure the content author experience is still taken in to consideration while pulling off an amazing looking site.

Couple things to keep in mind while coming up with Architecture and Sitecore content structure for the site –

  1. Placeholder settings
  2. Insert Options
  3. Experience editor support
  4. Available renderings
  5. Compatible Renderings
  6. Standard Values

I will drill more on to how each of the above when thought and configured correctly would be of great help to ensure content author has seamless experience.  For now, jumping on to performance.   I have seen many folks complain that their content authoring is slow and sometimes take a while to load.  This could be due to customization done, but, we should not forget to try the below things first to ensure we have basic foundations covered.   They do not take long time to do, but, could be that it is often given least importance because again end user experience is given more weight  than content author experience. 🙂

Below is the drill that could be done to instantly bump up your content author experience.

  • Clean up Databases :  It should be either done regularly via control panel or a script that could be scheduled to run from SQL server to help mitigate performance issues.
  • Maintenance Plans: Sitecore performance tuning guide screams that this is important, it is simple to do, but, I noticed this is almost always ignored and not done.  This is important and critical for content authoring performance
  • Ensure there are less than 100 items within a node, this is a best practice suggested by sitecore, so, the content author does not click on expand and wait few seconds before he see’s the list load.
  • Few critical settings that could help content tree load would be those mentioned on performance tuning document, below are the two for reference, both have good gain of performance
    RenderCollapsedSections
    CheckHasChildrenOnTreeNodes
    Check tuning guide for more information:  https://sdn.sitecore.net/upload/sitecore7/70/cms_tuning_guide_sc70-72-usletter.pdf
  • Limit number of versions: User version manager to ensure you have upper bound to number of versions on your implementation.
  • Ensure workbox and draft versions are cleaned up frequently for better maintenance and quicker load.
  • Clean  up broken links
  • Rebuild your indexes
  • Use publishing service if you are on newer versions of sitecore.
  • Go cloud – So, nearest available node would serve the content avoiding any network delay
  • Ensure you set cache limits and not use limitless cache option that sitecore provides on CM
  • Check your logs for any errors and fix them.

After doing all the above, if your content authoring is still slower then look into any overridden code in Sitecore pipelines and do some performance tests.

Happy Sitecoring and Have a great weekend!