[noun] - \ko-'da-la-te\ - Code and Effect - solving problems with just enough amount of code - by Adam Najmanowicz
It’s been a while since my last summary on April 2012 but finally getting to update the Reference page with the latest community summary for Sitecore PowerShell Extensions.
Following are the updates I will be pushing onto the reference page I’m trying to keep up to date and failing miserably most of the time.
A large problem with Sitecore PowerShell Extensions up to version 3.0 was the lack of proper separation of solutions provided on top of it from the core of the module. The problem is that all integrations look for scripts in the main Script Library but they look for them solely in their single libraries. The specification outlined in this blog aims at solving this issue. The current structure of the tree looks somewhat as follows:
If you’re reading this, chances are you’ve probably read about the ways of putting scripts in the Content Editor ribbon or Context Menu. Those are some simple and quick ways of extending the Sitecore UI to do quick actions accessible for your users without them having to even know about the existence of PowerShell in your system. Up until now however we’ve not been very vocal about the fact that those does not really have to be quick one-off actions but they can indeed form a broader solution to your problem through the use of persistent, named sessions. In fact Sitecore PowerShell Extensions (SPE) allow you to manage sessions and decide that it should stay in memory after the script have executed. In fact SPE does quite a bit of session maintenance itself that you might want to be aware of.
Creating reports is probably a task that every developer dread. I for once always felt like listening to Tennessee Ernie Ford’s ?16 Tons? every time when I was supposed to do it for yet another project audit – especially this part resonated with me:
I was born one mornin’ when the sun didn’t shine I picked up my shovel and I walked to the mine I loaded sixteen tons of number nine coal And the straw boss said “Well, a-bless my soul”
Reading some of the blogs from the Sitecore community I find it pretty apparent that we didn’t do a great job advocating the optimizations that PowerShell Extensions have introduced for working with Sitecore items. This blog attempts to rectify this problem to a degree.
The most natural way to retrieve Sitecore items is with use of Get-Item and Get-ChildItem commandlets. That is because those 2 commandlets add a PowerShell wrapping around them that allows the functionalities that I’m going to describe in the next section of this blog after I’ll tell you all about retrieving items. If you have retrieved your item directly using the Sitecore API you can still add the nice wrapper when you pipe them through the Wrap-Item commandlet as well. Some of those enhancements work in the older versions of PowerShell Extensions but I would encourage you to upgrade to the latest version (2.7 at the time this blog was written) to leverage the full potential of the environment.
I’ve been meaning to write this article for quite a while since the functionality to remote into the Sitecore environment exists in the module at least for at least a couple of versions now and the recent email from one of the Sitecore PowerShell Extensions users convinced me this cannot wait any longer.
You would probably need this as part of your Continuous Integration or installation scripts. If you need to manipulate Sitecore data from your deployment script remoting is the right solution for you.
I’ve decided to 1-up the game from my previous post and zip something that isn’t really a real file but rather a blob in a Sitecore database. The script below is based heavily on the last post but instead of just zipping content of a flat folder traverses the Sitecore item tree and zips all files beneath the current folder. If you have downloaded the 2.1 version of the Sitecore PowerShell Console from the Sitecore Marketplace you will actually have the script deployed on your system already. Here’s how it looks like for your user in the Content Editor:
There was a breaking change in the Console 2.1, if you’re using version 2.1 or newer use Download-File commandlet instad of the “Get-File” as shown in the code below.
You might have have found yourself hunting around in the Sitecore interface for something that would allow you to download all the the log files in a fast and convenient way once time or another. Have you found one? Me neither? but luckily I had the PowerShell console installed on my server so I started looking for a script to zip all files in a folder and luckily because we have a full PowerShell power in the box I could stand on the shoulders of giants and get the zipping part from Stack Overflow – again (which is the majority of my script. The rest was super easy – just call the function and download the file?
Last night I needed to reproduce really quickly a site structure we will be moving from another CMS and create a matching item hierarchy in my Sitecore instance… I could face an hour or so of boring clicking and copying and pasting and hoping I’ve not missed anything or… I could write a short PowerShell script to do the work for me… Guess which path I chose?
Before you use the script you should customize the script parameters:
Kieranties must be the biggest PowerShell nerd (together with yours truly) I’ve had a privilege to chat with (I guess this implies I talk to myself?). So it shouldn’t be a surprise when the two started talking PowerShell/Sitecore pixie dust started sparkling.
This time – events integration.
This is a fairly easy task that Sitecore pretty thoroughly describes in the ?Using Events? SDN article. So there is little point for me to reiterate it here.