So How do I tap into the PowerShell goodness?

First of all, you download the PowerShell Console from its Sitecore Shared Source site. Reference the Cognifide.PowerShell.dll from your application and add the following to your class:

using Cognifide.PowerShell.Shell.Host;

Now you can run your PowerShell script by using code that looks like follows:

using (ScriptSession session = new ScriptSession())
{
    // sample script that returns processes
    var scriptResults = session.ExecuteScriptPart(
      "get-process | where-object { $_.ProcessName -eq 'w3wp' }",
      false);

    //iterate through the results to retrieve the
    foreach (Process process in scriptResults)
    {
        WebProcesses = WebProcesses + process.SessionId + ",";
    }
}

In the above sample the environment is used to pull all w3wp processes and create a coma separated list of their ID’s. While you may not find this sample very compelling, just think what you have the whole PowerShell filtering and processing engine at your disposal, that’s including the ability to traverse Sitecore tree and perform actions and creating the script dynamically in your code. You could think of it like a Regexp, but for your environment rather than for Strings.

If you want to get the results PowerShell would print out rather than the objects themselves, you can put “true” in the second parameter of ExecuteScriptPart and then iterate over the Output property of the session to access the results.

using (ScriptSession session = new ScriptSession())
{
    // sample script that lists w3wp processes list
    session.ExecuteScriptPart(
      "get-process | where-object { $_.ProcessName -eq 'w3wp' }",
      true);

    //iterate through the output lines to display them
    foreach (var output in session.Output)
    {
        WebProcesses = WebProcesses + output.Text + "</br>";
    }
}

Naturally you can do something at this level without the PowerShell Console for Sitecore (and here’s how). What the console gives you is the access to all the Sitecore specific elements like being able to access items like drives e.g. “cd master:\content\home\” etc as well as all of the custom commandlets.

To get access to the above functionality you need the console in version 2.0 beta5 or later.

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?

Fortunately there is a lot of documentation on that subject from both Microsoft and community a few good starters:

• Creating a Windows PowerShell CmdLet using the Visual Studio Windows PowerShell Templates
• Extend Windows PowerShell With Custom Commands
• Cmdlet Class – description on MSDN
• You might find the PowerShell SDK – helpful in the process

But overall all you need to do is to write a class that inherits from the Cmdlet class and implement one or more of the methods:

• BeginProcessing
• ProcessRecord
• EndProcessing

and PowerShell will take care of all of the pipeline processing, parameter handling, binding and so on, you only implement the logic you want your commandlet to perform.

If you want to make your life even easier the Sitecore Console introduces a Cognifide.PowerShell.Shell.Commands.BaseCommand class that does some of the common tasks you might want to perform like getting the CurrentDrive (Windows Drive or Sitecore Database), learning if your script context is within one of the database (master:\ etc.) IsCurrentDriveSitecore or learning the current full path CurrentPath or getting a Wildcard to verify if a name matches a user-provided wildcard GetWildcardPattern allowing you to write into pipeline only if your object matches a wildcard provided by the user WildcardFilter.

For example a commandlet that retrieves a user from Sitecore and puts it into pipeline looks like following

using System.Management.Automation;
using System;
using Sitecore.Security.Accounts;

namespace Cognifide.PowerShell.Shell.Commands
{
    [Cmdlet("Get", "User", DefaultParameterSetName = "Name")]
    public class GetUserCommand : BaseCommand
    {

        [Parameter(ValueFromPipeline = true, Position = 0)]
        public string Name { get; set; }

        [Parameter]
        public SwitchParameter Current { get; set; }

        protected override void ProcessRecord()
        {

            if (Current.IsPresent)
            {
                WriteObject(Sitecore.Context.User, false);
            }

            if (!String.IsNullOrEmpty(Name))
            {
                // from BaseCommand
                WildcardWrite(Name, UserManager.GetUsers(), user => user.Name);
            }
            else
            {
                WriteObject(UserManager.GetUsers(),true);
            }
        }

    }
}

In this case the commandlet can be used in Powershell as a “Get-User” as defined in the Cmdlet attribute on the class while Current and Name are exposed as its parameters. This is quite cool seeing how you don’t have to do anything about Parsing or binding the arguments – PowerShell does all the plumbing for you. The Name parameter is bound to the pipeline input which means that you can feed the commandlets with multiple user names (e.g. from a CSV file) and it will turn those into User objects for its pipeline consumers.

The Current parameter in turn is interesting for other reasons – shows how to define a switch that can be checked for existense – in this case calling the commandlet like

Get-User -Current

Will add the currently logged in user ad the output of the commandlet pipeline by its mere inclusion in the command line.

Overall I would strongly encourage you to crack the PowerShell console assembly and see how the existing commandlets work and build your own based on that.

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.

Adam’s (101 level) blogs for PowerShell Console for Sitecore

• So what PowerShell Console for Sitecore is and what can it do for me?
• Sitecore PowerShell Console cheat sheet Part 1 & Part 2
• Sample scripts for Sitecore PowerShell Console

How PowerShell console can help you extend Sitecore?

• Continuous deployment in Sitecore with PowerShell
• Extending Sitecore ribbon with PowerShell scripts
• PowerShell driven Sitecore scheduled tasks

External Content helpful for Sitecore PowerShell Scripters

• Free PowerShell EBooks
• Sitecore Virtual User Group:  An Introduction into PowerShell from a Sitecore .NET Developer

Alternative solutions

• PowerShell console in Sitecore Rocks – part of the Sitecore Rocks extension to Visual Studio
• psTerminal – not available yet (currently in development by Andrew Chumachenko of Sitecore UA) – introduced on Sitecore Virtual User Group Webinar.

The PowerShell co-nerds within Sitecore Community

Other people that did research in the field, adopted the console early and/or are knowledgeable in the subject:

• Jakob Christensen – Sitecore – Sitecore Rocks author – has alternative Sitecore PowerShell console (@TheRocksGuy
  Sitecore.PowerShell – Rocks PowerShell commandlets
• James Gardner – PS Console enthusiast – doing quite advanced stuff with the console (@iamdudley
  • Powershell Console – editing fields that have never been populated
  • PowerShell Console script examples for updating built in fields
• Nick Wesselman – co-author of Sitecore EviBlog (@techphoria414 – PS proponent.
  • Blog – Changing Item Templates With Sitecore PowerShell
  • Forum – PowerShell error on Get-Item
• Alex Shyba – Sitecore US – advanced stuff with PowerShell deployment (@alexshyba
  • Installing Sitecore with PowerShell
• Szymon Kuźniak – Cognifide – contributed commandlets to the console (@skuzniak)
  • Sitecore Profile Cards: The Lazy Way
• Marek Musielak – Cognifide – (@MarasM) great thanks to Marek for his help in integrating JQueryTerminal with the console)
• Great thanks to Lars Nielsen‏ (@ln_sitecore) and Lars Birkholm Peters (‏@larsbirkholm) for their support and encouragement for the project.

How can I contribute?

If you have any suggestions please email me: adam [at] najmanowicz.com or post within the Sitecore Shared Source Forum.

How to Write Conditional Statements

To write an If statement use code similar to this:

$page = Get-item .;
$changedBy = $page."__Updated by";

if ($changedBy -eq "")
  { "Unspecified author - a system page?" }
elseif ($changedBy -eq $me)
  { "The page has been last edited by me!" }
else
  { "The page has been last edited by "+ $changedBy }

Instead of writing a series of If statements you can use a Switch statement, which is equivalent to VBScript’s Select Case statement:

$page = Get-Item .;
switch ($page.Language) {
    "en" {"This version is in English"}
    "pl" {"This version is in Polish"}
    "tlh-KX" {"This version is in Klingon?!"}
    default {"No idea what this language is!"}
  }

How to Write For and For Each Loops

To write a For statement use code similar to this:

for ($a = 1; $a -le 10; $a++) {$a}

By comparison, a For Each statement might look like this:

cd master:\content\home
foreach ($i in Get-ChildItem .)
{ write-host $i.TemplateName }

How to Write Do Loops

To write a Do loop use code like the following, replacing the code between the curly braces with the code to be executed on each iteration of the loop. Oh: and replacing the code inside the parentheses with the loop condition:

$a = 1
do {$a; $a++}
while ($a -lt 10)

$a = 1
do {$a; $a++}
until ($a –gt 10)

How to Use .NET Objects and Classes

To use a .NET Framework class static method enclose the class name in square brackets, then separate the class name and the method using a pair of colons:

$master = [Sitecore.Configuration.Factory]::GetDatabase("master");
$homeItem = $master.GetItem("/sitecore/content/home");
$sample = $master.Templates["sample/sample item"];
$myItem = $homeItem.Add("MyItem", $sample);

To create an object reference to a .NET Framework object use the New-Object cmdlet:

$item = Get-Item "master:\media library\Files\Sample";
$mediaItem = New-Object `
                   -type Sitecore.Data.Items.MediaItem
                   -argumentlist $item

Note. This is a cursory overview of working with .NET. The two techniques shown here will not necessarily work with all .NET classes.

How to Select Properties

To work with or display specified properties of a collection, pipe the returned results to the Select-Object cmdlet:

Get-Item master:\content\Home | `
  Select-Object DisplayName, TemplateName

How to Sort Data

To sort data returned by Windows PowerShell simply pipe that data to the Sort-Object cmdlet, specifying the property you want to sort by:

Get-ChildItem -recurse |
    Sort-Object DisplayName |
    Select-Object DisplayName, TemplateName

You can also add the –descending or -ascending parameters to specify a sort order:

Get-ChildItem -recurse |
    Sort-Object PageSaved -descending |
    Select-Object DisplayName, __Updated, "__Updated By"

You can even sort by multiple properties:

Get-ChildItem -recurse |
    Sort-Object TemplateName, "__Updated By" |
    Select-Object TemplateName, "__Updated By", DisplayName

How to Work with WMI

To get computer information using WMI call the Get-WMIObject cmdlet followed by the class name:

Get-WMIObject Win32_BIOS

If the class you are interested in does not reside in the cimv2 namespace simply include the –namespace parameter:

Get-WMIObject SystemRestore `
    -namespace root\default

To access data on another computer use the –computername parameter:

Get-WMIObject Win32_BIOS `
    –computername atl-ws-01

To limit returned data, use a WQL query and the –query parameter:

Get-WMIObject -query `
    "Select * From Win32_Service `
        Where State = 'Stopped'"

How to “Interrogate” an Object

To get information about the properties and methods of an object retrieve an instance of that object and then “pipe” the object to the Get-Member cmdlet. For example, this command returns the properties and methods available when working with processes:

Get-Item . | Get-Member

More tips coming soon… In the mean time please download the fresh version of the plugin with the latest improvements:

[Download & Enjoy]

All feedback appreciated!

Science isn’t about why, it’s about why not!? You ask: why is so much of our science dangerous?

I say: why not marry safe science if you love it so much. In fact, why not invent a special safety door that won’t hit you in the butt on the way out, because YOU ARE FIRED!

Yes you, box your stuff, out the front door, parking lot, car, goodbye.

– Cave Johnson

I have gathered some literature available for free about the topic of PowerShell in general you might want to read, but I also think that a distillation of the basic concepts is really important so you can have some quick wins while you begin your PowerShell journey.

A great deal of this post is a port of my older post for similar console for EPiServer, but since the differences are significant enough to confuse Sitecore developers if I sent them to the original version, I’ve decided to create a proper Sitecore cheat sheet.   Most of this is based on the Microsoft’s Windows PowerShell Quick Reference however despite the sharing scripting runtimes the nature of the both shells are pretty different (although the differences are not as vast as one might think).

That said, I considered that enough of the Reference document is irrelevant in the Sitecore scenario that it’s beneficial for the users of the console to have a bespoke cheat sheet created especially for the purpose of this plugin.

The content & samples of the original cheat sheet has been adjusted to more closely reflect scenarios usable for an Sitecore admin or developer.

How to get help

Give a man a fish and you feed him for a day. Teach a man to fish and you feed him for a lifetime.

By this principle – PowerShell by itself comes with an extensive help system. And the Sitecore implementation takes nothing away from it. Should you find yourself wondering the following is your friend.

To discover commandlet’s syntax you can use something like:

Get-Help Get-Item –Full

Get-Help ForEach-Object –Verbose

You can learn more about the help system by being slightly recursive

Get-Help Get-Help –Full

There is a lot of discoverability within the environment. For example to learn about commandlets available to you you can try experimenting with these:

Get-Command -CommandType Cmdlet

Get-Command Get-*

You can discover what capabilities an object you got in pipeline possesses by using Get-Member e.g.:

Get-Item master:\ | Get-Member

And here go the Sitecore specific tips

How to work with items

To switch to the desired database item you would use the following:

cd master:\

cd core:\content\Applications

The environment deliberately skips the “Sitecore” root in the tree as it provides no value to give the script access to the item and in fact unnecessarily lengthens each path so the “Sitecore” root is treated as the drive root. You can still access it as follows:

cd master:\
Get-Item .

How to get Current Item

To get the page for the location you’re in you can use:

Get-Item .

How to get Current Page’s children

To get the children of the page you’re currently in:

Get-ChildItem

To get the children of the page you’re currently in and all of its children children (whole branch):

Get-ChildItem –recurse

How to Modify an item

Get-Item . | ForEach-Object { $_.Text = “<p>Hello World</p>” }

or in short:

Get-Item . |% { $_.Text = “<p>Hello World</p>” }

How to restart the application

To restart the application use the following command:

Restart-Application

How to get system properties and environment variables

Some more important variables are mapped onto the PowerShell variables by the plugin. Notable variables (value depending on your server configuration):

You can list all PowerShell variables by using:

Get-Variable *

Additionally you can list all environment variables by using:

[System.Environment]::GetEnvironmentVariables()

and get the value of a specific variable with e.g.:

[System.Environment]::GetEnvironmentVariable("ComputerName")

PowerShell Language and environment specific tips

How to Insert Comments

To insert a comment, use the pound sign (#):

# This is a comment, not a line to be run.

How to Insert Line Breaks

To insert a line break into a Windows PowerShell script use the backtick (`) :

$b = `
"This is a continuation of the line."

You can also break a line at the pipe separator (|) character (assuming your line uses the pipeline):

Get-ChildItem C:\Scripts |
Sort-Object Length –Descending

How to Create Multi-Command Lines

To put multiple commands on a single line, separate those commands using a semicolon:

$a = 1,2,3,4,5; $b = $a[2]; $b

Hint. This script writes-out the value of $b which is 3

How to Make Comparisons

Windows PowerShell cmdlets (like Where-Object) use a special set of comparison operators, including those shown in the following table.

Each of these operators can be made case sensitive by adding a c immediately after the hyphen. For example, -ceq represents the case-sensitive equals operator; -clt is the case-sensitive less than operator.

How to Read a Text File

To read the contents of a text file into a variable, call the Get-Content cmdlet followed by the path to the text file:

$a = Get-Content C:\Scripts\Test.txt

Each line in the file ends up as an item in the array $a. If you want to access a single line in the file you can simply specify the index number corresponding to that line:

$a[0]

This command echoes back the last line in $a:

$a[-1]

Bonus. To determine the number of lines, words, and characters in a text file use this command:

Get-Content c:\scripts\test.txt |
measure-object -line -word -character

How to Write to a Text File

To save data to a text file use the Out-File cmdlet:

Get-Item . | Out-File C:\Scripts\Test.txt

To append data to an existing file, add the –append parameter:

Get-Item . | Out-File C:\Scripts\Test.txt –append

Attention. Unlike in the regular Windows PowerShell console you cannot use the MS-DOS redirection characters (> for write, >> for append) when using Sitecore hosted PowerShell.

Another option is to use the Export-CSV cmdlet to save data as a comma-separated-values file:

Get-Item . | Export-CSV C:\Scripts\Test.txt

More tips coming soon… In the mean time please download the fresh version of the plugin with the latest improvements:

[Download & Enjoy]

All feedback appreciated!

The easiest approach is to build the package visually in the package designer, save it and then simply use the console to read it and generate the installation zip like:

get-package "powershell console.xml" `
  | Export-Package -FileName "PowerShell Console.zip" -Zip

That’s fine in most cases but if you have some more complex scenarios or want to generate some custom packages – you might want to generate packages directly in PowerShell.

To Create a Package you simply use:

$package = new-package "Test Package";

Now that you have that package you might want to add some files and items to it.

Let’s add for example our item templates by querying the master database and creating a dynamic item source:

$TemplatesSource = get-childitem "master:/templates/Cognifide" `
  | New-ItemSource "Cognifide Templates";

And subsequently add it to our new package:

$package.Sources.Add($TemplatesSource);

While that by itself is fairly useful, the really cool part is that you have a full flexibility of PowerShell at your disposal when you create a source with static items. Let’s say you want to add all items of template “Article Template” that reside anywhere under your “home” node … now that would require quite a bit of clicking in the Package Designer, but is trivial with the PowerShell Console:

$ArticlesSource = get-childitem master:/content/home/about-us/* -recurse `
  | where-object { $_.TemplateName -match "ArticleTemplate" } `
  | New-ExplicitItemSource "Cognifide Articles";

$package.Sources.Add($ArticlesSource);

You can specify any automation or filter you can think of to your Get-ChildItem, and you really don’t have to skimp on the number of data sources – after all you can re-generate your package at any time!

Similarly you can do this to the files on disk. Let’s say – you want to add all .aspx, .ascx and .ashx files, just to make sure your deployment features all the latest code and for the sake of this example let’s assume your UI elements are located in the Layouts folder under your web application:

$LayoutsPath = $AppPath+"layouts\*"
$Layouts = get-childitem $LayoutsPath -include "*.as?x" -recurse -force `
  | New-ExplicitFileSource "My Layouts";
$package.Sources.Add($Layouts);

Easy enough… now let’s add everything that is within the bin folder as a dynamic file source:

$BinFolder = New-FileSource "Bin Folder" -Root "/bin"
$package.Sources.Add($BinFolder);

That is it really… you may want to specify your package metadata which you would do like:

$package.Metadata.Author = "Auto generated " + `
  [DateTime]::Now.ToShortDateString();
$package.Metadata.Comment = "Isn't it cool?!";
$package.Metadata.Publisher = "Cognifide";

and then save it for later opening in package designer:

$package | Export-Package -FileName "test package.xml"

alternatively you can open such package as specified earlier

get-package "test package.xml"

if you ever wanted to add more sources to it or export as a zip file to be imported with the assets in your target environment:

$package | Export-Package -FileName "test package.zip" -Zip

… now on your target machine you need to upload your package to the Data\Packages folder. But then to install it all it takes is:

Import-Package "test package.zip"

Obviously all of it can be hooked to ribbon, context items, or be scheduled… but I get ahead of myself…

So how does it all relate to continuous deployment?

All of this can be completely automated, all you need to do is create a Script item as described in one of my previous posts and call the PowerShell execution URL referencing your script from your CruiseControl server or whichever continuous integration product you use in a fashion similar to:

http://myhost/Console/Layouts/PowerShellResults.aspx?scriptId={1680E211-BD28-49BE-82FB-DA7232814C62}&scriptDb=web

You need to deal with the fact that you are most probably not logged in with your continuous delivery environment – in this case probably best approach is to use the web database or the script item my turn out to be unavailable to you and the script will not execute.

Now in your source environment your script will create the package and upload it to an FTP server (there is plenty of ways to do this from PowerShell… you can find a couple of samples on Stack Overflow) and subsequently call a second part of the script on the target server.

On the Target server – a complementary script will be executed in the similar fashion – by the originating server and if you don’t have direct access to the file on the FTP server you’ve just uploaded – you can download it and import the package.

Now if you integrate the script with a ribbon in Content Editor on the source server (like described in the previous post) you can have a one-click-deployment solution on your dev machine, but then the REALLY cool part would be to integrate it with the context menu (as described in this post) and be able to push parts of the site to production with a single click! Not to mention your nightlies can really be nightlies if you do it using the scheduled tasks integration.

The module comes with an out-of-the-box PowerShell script command as you can see

You don’t need to create any additional commands, instead you only need to create a script and a schedule for it and the existing command will handle all of them. In my example I wanted to trim all recycle bin items every night.

Let’s get cracking…

First you need a script that will accomplish the task. The module automatically creates a Scripts folder in the following location: /sitecore/system/Modules/Scripts/. It probably is best if you stick to putting your scripts there. The Insert options for it are limited to scripts and folders so you can organize your scripts into subfolders if the number will grow significantly.

In my case the script part will be fairly simple:

The Popup window and Pre-execution warning settings in this case have no meaning as the script has no means of providing this kind of feedback as it’s executed in a background thread.

Now create a schedule for your script in /sitecore/system/Tasks/Schedules/:

I strongly encourage that you read more about how task scheduling works in Johns blog. An additional feature you might find useful since there is no UI component to running scheduled tasks is the new Write-Log commandlet, which wors similarly to Write-Host but instead writes to Sitecore diagnostic logs. The syntax is as follows

Write-Log [[-Object] <Object>] [-Separator <Object>]
  [-Log <LogNotificationLevel>]

So for example to write an info message you can use:

Write-Log “Recycle bin clear scheduled task started”

Similarly you can write a Debug message like:

Write-Log –Log Debug “This is a debug message”

This supports all of the common log types like: Debug, Error, Fatal, Warning & Info – if no log type specified – Info will be used.

The solution requires the latest Sitecore PowerShell Console (1.2.0) from Cognifide, available for free from Sitecore Shared Source site.

All feedback appreciated!

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.

Similarly to extending context menu – first I’ve created the script I wanted to execute that will take the current item and it’s sub-items and publish them by adding a new script item using the /sitecore/templates/Cognifide/PowerShell Script template in the core database. I’ve put it in the same place I store all my my scripts – in the /sitecore/content/Applications/PowerShell Console/Scripts branch but feel free to store them anywhere in the tree.

• Filled in the Script body part with my script.
• I decided I want to see the publishing results as I want to verify if the items I expected got published.

Now the UI integration bits…

Since I wanted it nicely integrated with the publish button – I’ve created a Publish My Items item of template /sitecore/templates/System/Menus/Menu item within the /sitecore/content/Applications/Content Editor/Menues/Publish/ branch in the core database, set it’s icon and reference the script item in the Message field using the following pattern:

item:executescript(id=$Target,script={0937769B-998D-4580-B9FE-730C4CDABECD},scriptDb=core)

where the script guid is the ID of your script and the scriptDb is the database the script is located in.

That’s it really. You can download the solution but I would strongly recommend you try the manual approach – it’s really exciting to see the puzzles click in.

The solution requires the Sitecore PowerShell Console from Cognifide, available for free from Sitecore Shared Source site.

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.

Similarly but the other way around, with the PowerShell Console for Sitecore, you can attach scripts to the context menu in your item tree.

An execution of such script can be completely silent but you can also add a question before a script is executed:

and  if needed – show the results:

Anatomy of a context script

The PowerShell console comes with 2 sample scripts which for better or worse only demonstrate the potential of what can be done. The context part means that before executing your script the PowerShell environment location is set to your content item so Get-Item should yield the item you clicked on, whereas Get-ChildItem will get all of its children, potentially with their children if  -recurse is used.

1. Create a script

Add a new script using the /sitecore/templates/Cognifide/PowerShell Script template in the core database. In my case I store my scripts within the /sitecore/content/Applications/PowerShell Console/Scripts branch but anywhere in the core database is fine really.

• Fill in the Script body part with your script.
• If you want a warning/confirmation request to popup prior to the script execution provide it in the “pre-execution warning” box
• and tick the checkbox if your script can generate output or you expect it to occasionally show errors.

2. Create a menu item for your script

Create a context menu item of template /sitecore/templates/System/Menus/Menu item within the /sitecore/content/Applications/Content Editor/Context Menues/Default/PowerShell/ branch in the core database. If you have more than just a few scripts, a more elaborate structure might need to be created to group your scripts by functionality/purpose.

3. Bind it to your script to the menu item

Within the menu item you’ve just created edit the Message field and bind the script to it using the following pattern:

item:executescript(id=$Target,script={1680E211-BD28-49BE-82FB-DA7232814C62},scriptDb=core)

where the script guid is the ID of your script and the scriptDb is the database the script is located in.

Since this is a simple Sitecore command – similarly you can use the PowerShell functionality to expose your script on any ribbon or other kinds of menus!

That’s it really, and since you have pretty much all of the Sitecore API at your disposal you can hotfix a great deal of missing functionality without ever logging into Visual Studio, how is that not cool?!

On a final note… you might want to protect scripts that might create a heavy load on your site or do anything critical on your database from some users, but that’s a matter of simple permissions setting on your menu items.

[Download & Enjoy]

All feedback appreciated!

List your available site providers. You will use the name provided in the “Name” column in place of where I use “cms” in the later samples.

get-psdrive `
  | where-object { $_.Provider.ToString() -eq "CmsItemProvider"} `
  | format-table Name, Root

Sample scripts for working with pages:

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.

List all properties & fields available for a particular page (including Sitecore properties defined in the item template).

get-childitem | get-member -memberType property*

List all items in the CMS of which template name contains “Article”

get-childitem -recurse `
  | where-object { $_.TemplateName -match "Article" } `
  | format-table DisplayName, Name, TemplateName

List all subitems and how many days ago were they modified

get-childitem -recurse `
  | format-table Name, `
  @{Label="Days since modified"; Expression={ `
  [datetime]::Now.Subtract([Sitecore.DateUtil]::IsoDateToDateTime($_.Updated)).Days} }

Delete all pages that have not been modified for the last 365 days.

get-childitem -recurse `
  | where-object {[datetime]::Now.Subtract([Sitecore.DateUtil]::IsoDateToDateTime($_.Updated)).Days -gt 365 } `
  | remove-item

List all items Updated over the last 24 hours and who changed them.

get-childitem -recurse `
  | where-object { [Sitecore.DateUtil]::IsoDateToDateTime($_.Updated) -gt [datetime]::Now.AddDays(-1) } `
  | format-table -property DisplayName, UpdatedBy, {$_.Paths.Path}

List all pages that have their “Text” field filled in.

get-childitem -recurse `
  | where-object { $_.Text -ne $null } `
  | format-table -property DisplayName, {$_.Paths.Path}

Make a nice reviewer’s comment on all pages with their “Text” property filled in.

get-childitem -recurse `
  | where-object { $_.Text -ne $null } `
  | foreach-object { $_.ReviewersComment = "Great job providing content!" }

Add a warning to the beginning of “Text” property for all pages that have not been saved for the last 180 days.

get-childitem -recurse `
  | where-object {`
  [datetime]::Now.Subtract([Sitecore.DateUtil]::IsoDateToDateTime($_.Updated)).Days -ge 180 `
  -and $_.Text -ne $null }
  | foreach-object {$_.Text = "<p style='color:red'>Old content. Review pending!</p>" + $_.Text }

Replace a string in a property on all pages with another string (in this sample – removing the warning the last sample added).

$old_content = "<p style='color:red'>Old content. Review pending!</p>"
$new_content = "";
get-childitem -recurse `
  | where-object {$_.Text -match $old_content} `
  | foreach-object {$_.Text = $_.Text.Replace($old_content, $new_content) }

Display the 10 most recently changed pages ordered in the reverse chronological order or changes. Display the page name, who changed it and when as well as the page status.

get-childitem -recurse `
  | sort-object -property Updated -descending `
  | select-object -First 10 `
  | format-table -property DisplayName, UpdatedBy, Updated

Sample scripts for working with Media Library / files:

Removes all .xml files from the “Old Xml Files” in Media library.

cd "master:\media library\Old Xml Files"
get-childitem -recurse `
  | where-object { $_.Extension -match "xml" } `
  | remove-item

Copy all files from the “staging” folder to the “production” folder in Media Library.

Copying files within media library is done as follows. This can also be done for items in the content branch.

copy-item "master:\media library\staging\*" "master:\media library\production\"