One thing I always wanted to add to the Cognifide PowerShell Console for Sitecore but never had the chance to investigate properly, was GUI and user interaction. For example in a regular PowerShell console when an irreversible action needs to be taken or one that user needs to be notified about ? a question is asked:

Unfortunately due to the stateless and non-persistent nature of HTTP connections this is not easily achievable in Sitecore Sheer environment especially since in our case a PowerShell session usually lives in a separate thread within a Sitecore Job.

I knew this had to be achievable as Sitecore allows for rich interaction with user e.g. during a package installation process but I could not find any documentation regarding this subject, and my Sitecore gurus? posts were pretty discouraging in that regard:

• All About Jobs in the Sitecore ASP.NET CMS by John West
• Using Sitecore Jobs by Brian Pedersen

But heck(!) Somehow the package Installer manages to show those pesky Overwrite/Merge/Skip dialogs, right?

Not discouraged by the early discoveries, I?ve dusted my trusty copy of Reflector and dived inside the installer code. Following are the findings of my investigations and sample solutions for using them with your Jobs.

Read the rest of this article »

One thing I always wanted to add to the Cognifide PowerShell Console for Sitecore but never had the chance to investigate properly, was GUI and user interaction. For example in a regular PowerShell console when an irreversible action needs to be taken or one that user needs to be notified about – a question is asked:

Unfortunately due to the stateless and non-persistent nature of HTTP connections this is not easily achievable in Sitecore Sheer environment especially since in our case a PowerShell session usually lives in a separate thread within a Sitecore Job.

I knew this had to be achievable as Sitecore allows for rich interaction with user e.g. during a package installation process but I could not find any documentation regarding this subject, and my Sitecore gurus’ posts were pretty discouraging in that regard:

• All About Jobs in the Sitecore ASP.NET CMS by John West
• Using Sitecore Jobs by Brian Pedersen

But heck(!) Somehow the package Installer manages to show those pesky Overwrite/Merge/Skip dialogs, right?

Not discouraged by the early discoveries, I’ve dusted my trusty copy of Reflector and dived inside the installer code. Following are the findings of my investigations and sample solutions for using them with your Jobs.

Read the rest of this article »

There are 2 more ways I?ve managed to find and implement that you can control data sources with PowerShell:

• rendering data source roots
• rendering data source itself

The motivation would be similar to what I?ve described in the ?Part 1? blog post. So without further ado let?s cut to the meat?

Rendering Data Source Roots

You might want your roots to be dynamic and you can deliver those using a PowerShell script!

Sitecore allows you to specify a place in the content tree where content for your rendering or sublayout can be selected from. More over it allows you to specify more than one of those roots. What?s even greater ? this is done through a pipeline defined in web.config, which means we can hook into it with? PowerShell!

A cool part of the experience is that you can have multiple roots, which means that your scripts can be more liberal in what roots they expose.

Read the rest of this article »

Reading some time ago the Item Buckets documentation I discovered something really cool called code data sources. We delivered something similar in our internal libraries and it proved super useful ever since. I?ve also recently read a nice article by Ronald Nieuwenhuis on NewGuid about their approach to the subject.

So what a PowerShell and Sitecore nut does when he sees stuff like that? Obviously delivers a scripted data source!

Why do that?

Just to prove that both Sitecore and PowerShell are infinitely malleable and mixable, is good enough for me, but that?s not really the reason someone other than me would be interested in it.

• Delivering complex functionality based on multiple criteria. e.g. your field may need to provide different set of items to choose from based on:
  • user name or role (in simplest case this can be done using right management, but maybe not always possible in a more elaborate scenario)
  • current day or month?
  • In a multisite/multimarket scenario you may want to show different items for each site
  • based on engagement analytics parameters of the page
  • based on where in the tree an item exist (some of it can be done with use of a ?query:?)
  • anything you might want to build the code data source for?

Something that would be beyond the reach of a regular Sitecore query and potentially something that you would really need to deliver code source for. But maybe you?re not in a position to deploy that on your environment?

Read the rest of this article »

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!

A while ago Jakob suggested that putting the Sitecore PowerShell Console in Visual Studio might not be a bad idea. He even provided me with the boilerplate code that served as a stub for the module (Thanks a million Jakob!).

So after some struggling on my part the new module is now on the Sitecore Marketplace. There is really not much to write about. If you like PowerShell and Sitecore Rocks you will find it pretty neat. Otherwise I?m afraid those are not the droids you are looking for

Basically what it does is: it allows you to enjoy PowerShell automation while still skipping the web interface (that effectively is why you?re using rocks, right?).

Pre-Requisites are:

• Have Rocks installed in Visual Studio, which of course you already do have.
• Have Sitecore PowerShell Console installed on your server (please tell me you do? please?).

Installation is fairly straightforward. Once you download the zip file ? unpack it somewhere on your drive and run the install.bat within it. Once you restart your Visual Studio you?ll be able to do the following:

Which should result in the following outcome:

Feel free to contact me or post your questions as a comment below.

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.

Read the rest of this article »

All of the PowerShell blog posts so far were about using the console. Being the developer however, you probably think ? well that’s good for admins, but what?s in it for me? How can I benefit from it in my code? Well you can. With the latest update you can run the PowerShell environment in your application and take advantage of its scripting power, by getting the results out of it and pulling them into your app.

So How do I tap into the PowerShell goodness?

Read the rest of this article »

There is a lot of new stuff in the imminent 2.0 release of the PowerShell Console for Sitecore. Some of it is fairly obvious like the improved console window, some of it not so much. The aim of the console has always be to enable Sitecore developers to extend the CMS in new exciting ways. For this to happen it had to become a mini-platform on its own. So far you could use it to add scripts to ribbons and menus, write scripted tasks and execute scripts just by launching them from a URL call.

That?s extending Sitecore with PowerShell but what about PowerShell itself?

One of the coolest features introduced in 2.0 is the ability to write your own commandlets. Sure you could always use PowerShell to do it and write commandlets in script. But then the caveat was that you had to attach such commandlets to your own scripts (or put them in the initial script that would have to execute prior to the console). Now I?m talking about writing the real commandlets, just like those that come with the PowerShell console itself. Starting from 2.0 the console does not default to only attach commandlets that come with it, but can also scan other assemblies to attach your commandlets. To add your own all you have to do is well.. write them but then? all you have to do is to use the standard Sitecore include mechanism to enable the console to find them.

Including my own commandlets into Sitecore PowerShell Console

<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/">
  <sitecore>
    <powershell>
      <commandlets>
	<add type="*, Cognifide.PowerShell" name="Cognifide_PowerShell_Commandlets" />
      </commandlets>
    </powershell>
  </sitecore>
</configuration>

Where the type parameter is just a regular Sitecore type reference with a slight twist ? you can use wildcards in it. So with the above example, the console will scan the Cognifide.PowerShell assembly and allow you to use all the commandlet classes that are tagged appropriately.

How to write a commandlet?

Read the rest of this article »

While I?m updating it on a separate page I thought for the purpose of having a record and further tracking – it would be interesting to capture the state of the PowerShell knowledge in the Sitecore community here as well.

How do I get the PowerShell Console for Sitecore?

• Download the Console installation package from its Sitecore Shared Source page.
• Introductory documentation to PowerShell console on its Shared Source page.

Read the rest of this article »