Recently I?ve been asked to audit a site for one of our clients. Overall for a fairly seasoned Sitecore developer it?s rather obvious what to look for in a site and get a feel for whether an a solution is thoroughly thought through or just put together using brute-force development. You can usually tell if the implementation is sloppy or excellent, but how do you quantify that feeling to give the objective view to the person reading your report? Looking at the Sitecore Developer Network I?ve found the following set of recommendations. This is a great help with codifying how a proper Sitecore implementation should look like, what should we pay attention to and most importantly it?s a great reference when you?re trying to prove that your feeling is something more than just nitpicking but rather an industry standard that the developers should adhere to. I recommend strongly that you look at it and think how closely your practices match those that Sitecore recommends.

There is a small problem though. Not all of them are easy to asses, at least not without some clever tools in your toolbox. for example what do I do with a statement like:

Use TreelistEx instead of Treelist when showing very big trees ? like the Home node and its descendants ? or have lots of Treelist fields in one single item. TreelistEx only computes the tree when you click Edit whereas a Treelist will compute it every time it is rendered.

It might be fine in a small site to verify in a few data templates that it?s not violated, but  In my case I was dealing with a multisite platform that can potentially host tens or even hundreds of sites? Going manually over the hundreds of fields in nearly 300 data templates, bah even finding them ? would not be fun or easy thing to do. But hey? we have PowerShell why should I look there if I can whip up a one liner for it? Let?s try it then.

In any of the following scripts it is important to navigate to the appropriate part of the Sitecore tree? which in my case could be:

cd master:\templates\Cognifide\

or

cd master:\content\Home\

in the case of the recommendation above you could use the following one liner within the templates branch to list what field types and in what numbers you have in your solution:

get-childitem -recurse | `
  where-object { $_.TemplateName -eq "Template Field" } |  `
  group-object Type | `
  sort count -descending

To get some idea what kind of fields and in what quantities you?ve used in your solution, then probably you need to identify all those pesky Treelist fields:

get-childitem -recurse | `
  where-object { $_.TemplateName -eq "Template Field" -and $_.Type -eq "Treelist" } |  `
  format-table ItemPath

So that you can easily investigate them. In my case the result of the script looks as follows:

I think you will agree it?s faster than hunting for it all over the tree, right?

In many cases or if you?re just writing an audit – you might be more interested in numbers rather than actual lists of items. in those cases it?s probably easiest to replace the last format-xxx element in the pipeline with measure. This way you don?t have to count the lines

Now what other recommendations PowerShell helped me with?

Make good use of inheritance

Make good use of inheritance ? Place commonly used sections and fields in their own template, so that more specific templates can inherit them. For example, the Title and Text fields in the Page Title and Text section are used in multiple different content templates. Rather than duplicate these fields in each content template, simply inherit the Page Title and Text template.

What does this mean? Basically every data template that inherits from the Standard template is a candidate to violate this. So you might want to investigate the items that you will have listed as a result of the following script:

get-childitem -recurse | `
  where-object { $_.TemplateName -eq "Template" -and `
                 $_."__base template" -match "1930BBEB" } | `
   format-table ItemPath

what it does is: check all the templates that have the first segment of the GUID signature in it?s base template for a match with Standard Template. Now the output you get does not list the items that violate the rule, it just lists all your base types, what you need to verify is that this list makes sense and that perhaps some of the templates might be moved up the inheritance structure.

Assign icons to templates

Assign icons to templates ? This provides a visual clue to the type of item that will be created.

this one will be similar. You want to learn which templates do not define __Icon here:

get-childitem -recurse | `
  where-object { $_.TemplateName -eq "Template" -and $_."__icon" -eq "" } | `
  format-table ItemPath

You might need to be careful with using measure here. Since templates will also contain rendering templates and Rendering templates have no use for icons, so you need to subtract those from your audit figure.

__Standard Values

__Standard Values ? Define layout details, initial workflow, and insert options to a template. This reduces administration and centrally manages system settings, rather than setting them on individual items

Alistair Deneys have blogged about how to do something like this in Revolver, You might want to read his blog before proceeding. I will try to replicate some of that in PowerShell.

Simplest approach would be to find the templates that do not have Standard Values and perform an assessment on whether you need rendering or workflow attached to them:

get-childitem -recurse | `
  where-object { $_.TemplateName -eq "Template" -and `
                !$_.Children["__Standard Values"] } | `
  format-table ItemPath

Once you have the list, go over it and rationalize whether the item does or does not need Standard Values and thus Renderings/Workflows/Insert Options attached to them.

Now let?s look at the items with Standard Values defined. With the following script you might want to find out which of templates that define the Renderings,Default Workflows, Insert Options or Rules.

get-childitem -recurse | `   
  where-object { $_.TemplateName -eq "Template" -and $_.Children["__Standard Values"]} | `   
  select-object ItemPath, `   
    @{Name="__StandardValues"; Expression={$_.Children["__Standard Values"]}} | `   
  format-table ItemPath, `
    @{Name="Has Renderings"; Expression={!$_.__StandardValues["__Renderings"]}}, `   
    @{Name="Default Workflow"; Expression={$_.__StandardValues["__Default Workflow"]}}, `   
    @{Name="Insert Options"; Expression={$_.__StandardValues["__masters"]}}, `   
    @{Name="Insert Rules"; Expression={$_.__StandardValues["__Insert Rules"]}}

Having that data on the screen might be limiting ? if you want to export it and then process it in Excel you might do so with a small change modifying the script above to look like following:

get-childitem -recurse | `   
  where-object { $_.TemplateName -eq "Template" -and $_.Children["__Standard Values"]} | `   
  select-object ItemPath, `   
    @{Name="__StandardValues"; Expression={$_.Children["__Standard Values"]}} | `   
  select-object ItemPath, `
    @{Name="Has Renderings"; Expression={!$_.__StandardValues["__Renderings"]}}, `   
    @{Name="Default Workflow"; Expression={$_.__StandardValues["__Default Workflow"]}}, `   
    @{Name="Insert Options"; Expression={$_.__StandardValues["__masters"]}}, `   
    @{Name="Insert Rules"; Expression={$_.__StandardValues["__Insert Rules"]}}  | `
        export-csv C:\temp\StandardValues.csv -NoTypeInformation -Delimiter `t

Then import the file to Excel using the following:

So you can graph and agonize about the values to your heart?s content.

Now what about items that use those templates? After all the recommendation states:

This [?] centrally manages system settings, rather than setting them on individual items.

Cool, let?s find the items that violate this recommendation. The following finds all items that define renderings or insert options/rules of their own (set-location to your content part of the tree before running it):

get-childitem -recurse | `   
  where-object {$_.__Renderings -or $_.__masters -or $_."__Insert Rules" } | `   
  format-table ItemPath, __Renderings, __masters, "__Insert Rules"

Now the fact that something is there does not by itself means the recommendation is being violated. The option is there to use it, just use it sparingly and where it makes sense, it?s only when you?ll build your layout over and over again you risk your Sitecore consultant start crying when they visit you.

I?ll go over more recommendations regarding fields usage and how to audit them in the next post.

(3 votes, average: 5.00 out of 5)

Loading...

This entry (Permalink) was posted on Friday, June 22nd, 2012 at 3:13 pm and is filed under Best Practices, C#, CMS UX, PowerShell, Sitecore, Software Development, Solution, Uncategorized. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response , or trackback from your own site.