So I?ve finally found a moment (well a few days actually) to follow up on the previous article, and just about time as there are quite a few more tricks that PowerShell can help you with when assessing the quality of your Sitecore solution.

One thing that you need to keep in mind when reading the recommendations is that they are exactly that ? recommendations. While Sitecore strongly encourages you that you follow them ? I can see how most of those are perfectly fine to be ditched in some situations, you just need to be careful about picking those situations. By the general rule of thumb though, following vendor recommendations is a good thing and they are usually a good metrics of a well put together solution. Most of statistics provided in this post are hard to gather without a scripting solution like Sitecore PowerShell Console or Revolver.

Measurement is the first step that leads to control and eventually to improvement. If you can?t measure something, you can?t understand it. If you can?t understand it, you can?t control it. If you can?t control it, you can?t improve it

Dr. H. James Harrington

By no means this is the final list of assessments, those are simply the most straightforward translations of Sitecore recommendations into PowerShell reports. Most of those reports does not give you a simple Yes/No answer on whether your solution is in a good shape or not. But they give you the solution statistics that you can analyse further to improve. It?s worth mentioning that most of the scripts you will be able to find in the upcoming version of the PowerShell Console in a ready-to-reuse ?Solution Audit? library of scripts. Scripts in this post  are simplified (to make them easier to understand, apply and re-use) versions of the scripts found in that library.

Ok so let?s start with what you came here for?. the recommendations!

Templates and _Standard Values

Image Fields ? Define the source field to show the point in the media library that is relevant to the item being created.

Which we can get an outlook of with this little script (run in context of /sitecore/templates/my site templates/):

Get-ChildItem -recurse | `
  Where-Object { $_.TemplateName -eq "Template Field" `
                 -and $_.Type -eq "Image" } | `
  Format-Table -auto ItemPath, Name, _Source

What it will show you is the list of all fields of type ?image? and will allow you to see if they have Source defined for them. Just because a source is not there , doesn?t necessarily mean it?s a bad thing. You just need to look at them critically and make sure you cannot narrow their scope to improve your author?s experience.

Another aspect of editing streamlining is having a human readable description on each field:

Use the Help option in the individual field definition items to provide extra information to users about fields. Also consider using the Title field of the definition item to present a different name for the field to the user.

To learn which field does or doesn’t meet the criteria you can execute the following script (run in context of /sitecore/templates/my site templates/):

get-childitem -recurse | `
  where-object { $_.TemplateName -eq "Template Field"} | `
  format-table ItemPath, `
    @{Name="Help Defined"; `
      Expression={$_."__Long description" -ne "" -or `
                  $_."__Short description" -ne "" -or `
                  $_."__Help link" -ne "" }}, `
    @{Name="Title Specified"; `
      Expression={$_.Title -ne "" }} `
    -auto

which will show you all fields in your solution with information whether they define short or long description as well as a human readable title.

Information Architecture (Content Structure)

Sitecore defines a number of recommendations on your content a few of which can benefit from measuring with Powershell. the following is especially important if you want your site to be usable in Content Editor:

Limit the number of items under any given node that share the same parent, to 100 items or less for performance and usability.

A script that will allow you to see if your site is violating the recommendation (or approaching its limit) could look as follows (run in context of /sitecore/content/my site/):

Get-ChildItem -recurse | `
  Select-Object `
    ItemPath, `
    @{Name="ChildrenCount"; Expression={$_.Children.Count;} } | `
  Where-Object { $_.ChildrenCount -gt 50 } | `
  Sort ChildrenCount -descending

The script will show you all pages with 50 or more children. If there is a recommendation that you should be orthodox about ? that?s definitely the one. Should your content structure violate it, your editors will be in a lot of pain because of the site being slow on the back-end!

Similarly on the user experience you can hurt yourself having too many versions defined for any particular page.

Limit the number of versions of any item to the fewest possible. Sitecore recommends keeping 10 or fewer versions on any item, but policy may dictate this to be a higher number.

You can measure the compliance to this recommendation with the following script (run in context of /sitecore/content/my site/):

Get-ChildItem -recurse | `
  Select-Object `
    ItemPath, `
    @{Name="Versions"; Expression={$_.Versions.Count;} } | `
  Where-Object { $_.Versions -gt 10 } | `
  Sort Versions -descending

The result of running the script will be a list of pages with more than 10 versions (sorted from the biggest to the smallest abusers).

The following recommendation deals more with the convenience for your authors, and suggests that you only list the relevant nodes in your tree selectors:

Use the special syntax to restrict the results on Treelists, DropTrees, and TreelistEx to make sure users can only select the appropriate items, or Sitecore query in the other selection fields.

To learn about your solution compliance in this regard you can run the following script (in context of /sitecore/templates/my site templates/):

get-childitem -recurse | `
  where-object { $_.TemplateName -eq "Template Field" } |  `
  where-object { $_.Type -match "Drop" -or 
                 $_.Type -match "Tree" -or 
                 $_.Type -match "list"  } |  `
  format-table 
    @{Name="Template"; 
      Expression={$_.Parent.Parent.Paths.Path 
                    -replace "/Sitecore/templates/", ""}}, 
    Name, Type, _Source -auto

As a result you will see a list of fields with their types and the queries that they will use to populate their available select options. Examine the list carefully to see if you can limit the choices further.

Security (Users and Roles)

Security recommendations are usually tricky ones as you can always find a situation where they won?t meet your scenario but overall from my experience the following two recommendations are definitely worth adhering to:

Break inheritance rather than explicitly deny access rights ? It is a recommended practice to break inheritance in cases where the access right should be denied instead of explicitly denying it for a security account. If you deny an access right explicitly to a security account, the only way to override this denial of access is to do it directly on a user account. This creates an overhead in security management when you would like a user to inherit this role and some other role that should allow the same right access.

The following script (run in context of /sitecore/content/my site/) will show you all items where restrictions have been applied in a deny fashion:

Get-ChildItem -recurse | `
  Where-Object { $_.__Security -match "-item"  -or $_.__Security -match "-field" } |  `
  Format-Table -auto `
    @{Name="Item restricting right"; Expression={$_.ItemPath}}, `
    __Security

The following recommendation is also definitely worth complying to:

Apply security to roles rather than users ? We recommend that you configure security rights for a role security account rather than a user account. Even if there is only one user in the system with this unique access level, it is still better to have permissions configured for a role account. It is much easier to maintain a security system in which all the security configuration is set on role security accounts.

Which you can investigate with the following script (run in context of /sitecore/content/my site/) that will show you all items where rights have been assigned on a user rather than role basis:

Get-ChildItem -recurse | `
  Where-Object { $_.__Security -match "au\|" } |  `
  Format-Table -auto `
    @{Name="Item assigning rights to users"; Expression={$_.ItemPath}}, `
    @{Name="Security setting"; Expression={$_.__Security}}

Presentation

And last but no least ? presentation:

Leverage the presentation component parameters. You could use the parameters to allow users to configure/modify the behavior of the component, for example, the number of items shown in a list, the CSS classes to use, the URL for a feed it is showing, and so on.

? and then again ?

Make sure to create a template for any parameters in the presentation component, and set the Parameters Template Property.

Basically what it means is ? use rendering parameters. Which you can get metrics of by running (in context of /sitecore/layout/sublayouts/):

Get-ChildItem -recurse | `
  where-object { `
    $_.TemplateName -eq "Sublayout" -and  `
    $_."Parameters Template" -eq "" 
  } | `
  Select-Object Name

Now agreed ? not all components necessarily require rendering parameters, but if you?re seeing that all of your presentation parameters are driven by item pointed to from data source or if you find that you have a large number of similar components ? maybe you should think about leveraging the rendering parameters more?

Summary

As said before, by no means this exhausts metrics that you can get from your content using PowerShell, the ones listed are the most obvious and simple to gather. If you have any metrics I?ve missed and you created or if you have other metrics you would be interested to have but you have trouble writing the script for ? by all means let me know! I?d love to include them in the ?Solution Audit? library, so we can all enjoy more responsive Sitecore solutions that delight our clients!