Sitecore Recommended Practices

Recommended practices.  Why?

I apologize for the length of this up front, but this is a big subject and I have way too much first hand knowledge of the consequences of ignoring these things.  To start with, let me give some context to this.   I just came on board with XCentium having left a position with Sitecore's technical services team.  One of my duties included doing site reviews for Sitecore clients.  This gave me a lot of insight into different development practices. Basically, I assessed the client sites against Sitecore's recommended practices and write up my analysis and suggestions for them.  Naturally, no one wants someone to look at their site if everything is running smoothly, so I usually found lots of areas for improvement.  I understand this.  A college teacher told me his goal was to do as little work as possible by having 100% code reuse. It comes down to, if it isn't broke, don't fix it, but examining and implementing best practices when possible will improve site performance, keep project managers and content authors out of your hair and get you back to the new Battlefield 4  (when it comes out).  If you haven't read the best practices and tuning guides up on the SDN, I strongly urge you to do that.  However, because there a couple of them, I'll save you even more time and go over some points that I think are important and more important yet, easy to implement (often with minimal effort that can have a substantial impact in performance/productivity).

Templates and Standard Values

Inheritance: Templates are one thing that really needs to be done right the first time, so fixing bad templates is difficult at best to do in an existing site.  However, for future reference, let me just say that  if you aren't using template inheritance, You're doing it wrong! Do yourself a favor and read up on how this works. You'll definitely find out that development efforts are much less work, more flexible and easier to maintain. This brings up another point, however.  The school of thought seems to say to reuse and inherit templates when possible.  This is true mostly.  Keep in mind that it's perfectly acceptable to create templates that have NO fields and simply inherit from another template just so that they can have their own standard values.  Its always easier to create a new template and write a script to change the template on a subset of items than to write a script to change field values for a subset of items every time you need to change something because they can't use template standard values.  Also, be aware that your base templates standard values will cascade down to all child templates... and there's no need to inherit a template that is already inherited via a parent template.  Such as having a component template inherit your Base template and then inheriting both the base and the component templates.  Oh and even if you don't  know how you can use it to start, you should ALWAYS have at least one base template that ALL your templates inherit from. Template Folder Structure:  Another helpful tip is to keep templates organized in such a way that makes their purpose clear.  Specifically, this can be important in distinguishing metadata templates from component templates from page templates.  A good example is implementing a workflow.  Since you really only want a workflow on those items that are stand alone or will be used for content creation, this is really helpful... and as above, use inheritance if possible! Icons: Use UNIQUE ICONS for your templates!!! For the sake of your business users, this is such an easy thing to do and makes such an impact.  Just because we, as coders, are often times logical minded, those marketing people that create the content are usually much more visual and that little visual queue makes a world of difference to them, including that the Insert Options menus also show the item icons.  This also goes beyond the content authors. Think about the new developer who has never used Sitecore and is trying to wrap his head around how the content tree works.  They open the content editor to try to understand the structure of the existing site and find a content tree of plain white document icons.  Taking the extra step to set icons on your templates actually helps suggest site structure at first glance.   Looking at the image below, you can easily see the effect of icons vs. no custom icons. Which is more helpful? custom Template Standard Values:  While it doesn't seem like a big deal, its amazing how automated you can make maintaining a site if you simply set up the standard values right. There are a few that I'd like to point out that are, at times, critical and often completely neglected:

  • Insert Options: Since business users do not have the option to Insert from Template, if you don't set Insert Options, they can't create child items for that item.  Setting insert options along with placeholder settings really has a substantial impact on how amazingly flexible Sitecore can be.  We'll get to placeholder settings later, but in the mean time, don't forget to set the insert options!! 
  • Workflow: Workflow needs to be set on a template standard values.. and it needs to be on the Default Workflow field ONLY.  Do not set this value on the "Workflow" field.  This can have some pretty serious consequences on existing content as well.. especially if you have more than one workflow you're using.  Workflow, however, is a whole different subject that I'll cover at a later time.  
  • Layout values: This is a critical field!  There are very few instances that items should ever not be using template standard values for their layout and the key to all of that is by making sure this field is set on the template standard values correctly and then don't touch it again.. even if it means adding a new template that inherits from the existing template and then changing your content items template.  Think of this in the same way you do setting a CSS stylesheet. 

Standard Fields:    So.. do yourself a favor and take a second look at the standard fields.  Many of them can be very helpful and field many of those silly questions.  There are 3 different help fields that can give a field context or specific instructions (you can even put a thumbnail up!)  rather than relying on a field name to communicate what sort of data is needed.  This brings up another field.. Display Name.   It works the same as Page Item naming makes items SEO friendly.  If your field names need a prefix for some business logic that confuses the content authors, Display Name is your friend.  Another field value to make sure to set is the source attribute on imagefields, but that's a whole new subject I'll cover in another installment.  For now, just make sure you set imagefields to have a source.  Little known fact is that you can also set  the field value on Rich Text Fields allowing you to set up custom profiles for certain templates (i.e. snippets can be specific to that template only or you can restrict fonts, etc. without affecting all RTF fields on the site. So I know this was long.  Thanks for reading.  You can look for the next installment in what will probably be a series of blog posts.  Until then, as always, happy Sitecoring! Next: Information Architecture.