I’m realizing time and time again that the learning curve for PowerShell can be steep without a proper guidance. While most people I talk to are very excited about the concept they become discouraged after a having some tries and not realizing its full potential. Therefore I decided it’s worth spending some time introducing some basic principles to help scripting alleviate some of the initial pains.
A few days back a budy from our Sitecore team has alerted me to this interesting question on StackOverflow which asks for automation of content promotion from one Sitecore instance to another. He suggested - and rightly so – that the PowerShell Console could be used in that scenario. While this was always possible by simply writing it as a PowerShell code the latest version of the console added a few commandlets making building packages much easier.
So now that you can easily create the menus and ribbons executing PowerShell scripts, it might be a good time to do some more administrative tasks? let’s start with scheduled tasks. I’m not going to go deep into the task scheduling, you can find an excellent post by John West on his blog regarding task scheduling. Currently the PowerShell module supports one of the ways described in the post – the section describing how to configure them is called ?Scheduled Tasks? in the blog.
Sitecore is built from the grounds up with extendibility in mind. Be that plugging into any place in its internal pipelines or any aspect of its User eXperience, therefore when I’ve managed to extend it’s context menu, I expected to have no problems whatsoever doing the same to its ribbon. Mind you I was right?
Using the PowerShell Console Module it took me less than 10 minutes total to add a nice piece of functionality that I thought was missing – Publish items I have modified.
In the he latest update of PowerShell Console for Sitecore, I’ve started experimenting with further integration – context scripts. What is that and what can it do for you?
You can safely assume PowerShell is not something your regular users will aspire to learn, but it does not mean they cannot harness its power if you enable them to.
If you look closely at the latest Microsoft solutions you may notice that a lot of what GUI does is running some scripting behind the scenes. This is true for a long time with the SQL Server Management studio where pretty much for any action you can generate a script that will let you automate a common task.
For the same of brevity I’m assuming your location is already somewhere within a Sitecore tree (e.g. you did something akin to cd master:\content prior to executing the following scripts.
The aim of the PowerShell console for Sitecore is to create a command line interface to your data so you can automate and aggregate mundane tasks as well as create statistics and a discoverability layer on top of your content.
Have you ever found yourself:
having to make a mundane change to a large number of pages?
in need of getting statistics field or template usages?
being curious of e.g. what’s the oldest page on your site?
in need to find out how many authors really create your content and how active they are?
having to copy or move a large number of files from one folder to another?
renaming or deleting files in your file store en-masse?
publish pages that match some specific feature rather than a whole branch?
If the answer to any of those (and more) is something akin to “yes I did!”, I believe you might find my little plugin useful.
The idea is to create a scripting environment to work within Sitecore process, being able to make native calls to Sitecore API and modify content on a per-property level. The goal was to make it familiar to your IT and developers so they can reuse their skillset with it or if they rather learn it here, this knowledge will benefit them in the long run as clearly PowerShell is becoming an industry standard. The plugin’s aim is to manipulate not just sites, but files and pages on a large scale or perform statistical analysis of your content using a familiar and well documented query language. The console allows you to execute and test scripts interactively, but also gives the admin means of exposing scripts to end users within context menus and in the ribbon. I’m sure in the long run I’ll come up with more applications. Scripted pipeline processors? Scripted renderings? Scripting campaigns statistics and engagement workflow steps? You name it…
Now there is Rocks interface that performs similar task which I think is brilliant, however slightly - yet significantly different. Rocks integrates with your Windows PowerShell console and allows you to work on your remote website as if it was a file system on your machine. Rocks also features a number of commandlets that help you with some common tasks. The definite bonus of this approach is that you can simply use it in your deployment script and integrate some common content modifications, or clear caches/recycle bins on your server in a timely manner from your monitoring environment. I think the solution is a really needed addition to your Sitecore toolbox, but… it’s somewhat limited. Namely whatever new idea you want to employ in your script, is either supported by the commandlets provided – or impossible. You have access to all the goodies of rocks, but any extension must first be imagined and implemented in Rocks (both server and client side).
The Sitecore Console however works within the process of your Sitecore site and therefore can instantiate and execute any API Sitecore features. The only limit is that of the imagination. this comes at a price too though. The most important thing is security. The PowerShell plugin by itself does not run with elevated privileges, nor does it circumvent the rights, but since you can use any Sitecore API a malicious person could potentially do it themselves – therefore you need to be careful whom do you grant access to the PowerShell Console.
The console comes with some sample scripts when you install it – review the script and press Ctrl+Enter to execute and see some of the interesting use cases for it.
By default the console creates a “drive” for each of your databases so you will definitely have a “core” and “master” drives, and you will most probably have a “web” drive.
Since this is only an introductory post I’ll let you discover the full list of commands by yourself, just use the following script within the console:
Should you put your Sitecore site behind a load balancing proxy you will run into a bit of a problem with analytics where all the Engagement Analytics app would ever report would be your own load balancing proxy’s IP address. Needless to say that is fairly big loss as you are unable to reap a host of benefits of the Sitecore CEP like page personalization, automation and reporting.
While our website was running on Sitecore 6.4 this problem was already solved and we have implemented something akin to the solution from Jeroen’s blog. Meanwhile Sitecore has reimplemented its analytics engine from the grounds up in version 6.5, and I should say they did a great job on that. However in the process the API for the analytics has changed to a degree that made our current solution obsolete, basically what we got logged looked as follows:
We had a situation in the company this week which required us to deliver the whole EPiServer virtual path provider file structure to the client – zipped. Easy enough? go to the EpiServer VPP directory and? well? ok? hmm? so the path provider is versioning and as a consequence the physical organization of files on the disk does not make any sense for a human trying to browse it.
Fine! So let’s create a native provider and do a copy and paste within the file manager?. hmm an exception complaining about the provider incompatibility?
Naturally, my knee-jerk reaction is – let’s do it with the PowerShell? which I recall was doing something like this in it’s previous version? The example I’ve tested and placed in the ?Samples? tab was:
Most of this post is also based on the Microsoft’s Windows PowerShell Quick Reference however despite the sharing scripting runtimes the nature of the both shells differ considerably as described in the previous post: PowerShell for EPiServer - cheat sheet - Part 1. In all cases where it made sense I’ve converted the samples to establish them in EPiServer scenarios.
How to Write Conditional Statements
To write an If statement use code similar to this:
