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\"

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:

get-command `
  | where-object {$_.Implementingtype.FullName -match "Cognifide.PowerShell"} `
  |% {$_.Definition}

Cool, isn’t it?!

The best thing about it is that you can pipeline the commands so you can make a somewhat sophisticated query for items and publish them in a single line. For example to publish all items under Home that are created by admin it’s sufficient to use:

get-childitem master:\content\home\* `
  | where-object {$_.CreatedBy -eq "sitecore\admin"} `
  | publish-item -verbose

To publish all of items I (the current user) have modified you would use:

get-childitem master:\content\home\* `
  | where-object {$_.UpdatedBy –eq $me} `
  | publish-item -verbose

So who edited those pages over the last 7 days?

get-childitem master:\content\home\* `
  | where-object {[datetime]::Now.Subtract([Sitecore.DateUtil]::IsoDateToDateTime($_.Updated)).Days -lt 7} `
  | select-object { $_.Name, $_.UpdatedBy, [Sitecore.DateUtil]::FormatIsoDate($_.Updated) } 

You get the idea…

I’ll try to provide more content regarding the Console and its usage over the coming weeks, stay tuned for much more fun!

[Download & Enjoy]

All feedback appreciated!

Disclaimer – Responsibility: With great powers comes great responsibility – this tool can do a lot of good but also bring harm to a lot of content in a very short time – backup your system before using the plugin and never run any untested scripts in a production environment! I will not be held responsible for any use of it. Test your scripts on your development server first! Test on an exact copy of production before running scripts on production content.

Disclaimer – Security: If you plan to use the tool on your production environment, make sure to set the rights up in a way that an irresponsible users or just those who do’n’t necessarily need to, have no access to it. You can additionally, protect it with a <location> entry in web.config, to add another layer of security especially if your editor UI is available on a public server. Manage your group memberships & rights responsibly!

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:

Unfortunately, and I suspect it’s because 6.5 is not a recommended version yet, this is not yet very well documented. Standing on the shoulders of giants, I’ve found a hint on the solution on John West’s blog. However after implementing this – the default report still showed the same… no luck… so I started looking in the analytics database. and found that the data in fact is not kept on the Page Request level but rather on the Visit level. Even better(!)… So there is no need for me to set it on every call to the server like before but instead I can dig into the improved analytics pipeline and plug only once when the first call to a server is made by the visitor. For that purpose I need to inherit a CreateVisitProcessor class and override the following method:

public override void Process(CreateVisitArgs args)

The body of the method is somewhat similar to John’s implementation however for the report to show proper visitor ISP/company name you need to overwrite the RDNS field of the VisitRow object  – IP/GeoIP is not enough.

The body of my class looks as follows:

private static string[] headers = { "true-client-ip", "X-Forwarded-For" };

public override void Process(CreateVisitArgs args)
{
  VisitorDataSet.VisitsRow visit = args.Visit;
  HttpRequest request = args.Request;

  if (visit == null || visit.Ip == null)
  {
    return;
  }

  string forwardedFor = string.Empty;
  string headerUsed = string.Empty;

  // looking through all the headers where the true client IPs might be sent
  // the headers are ordered from highest to lowest priority
  foreach (string header in headers)
  {
    forwardedFor = request.Headers[header];
    if (!string.IsNullOrEmpty(forwardedFor))
    {
      headerUsed = header;
      break;
    }
  }

  if (!string.IsNullOrEmpty(forwardedFor))
  {
  // do the best effort for parsing x-forwarded-for
  // we need to check for multiple coma separates addresses
  // as there can be multiple proxies between the server and the client
  // this might not be 100% reliable as soem proxies and CDN's don't
  // append their IP's in the back but rather put themselves in the front
  string rdns = forwardedFor.Split(',').First().Trim();
  byte[] bForwardedFor = rdns.Split('.').Select(p => byte.Parse(p)).ToArray();

  var proxyIp = visit.Ip;
  visit.GeoIp = Tracker.Visitor.DataContext.GetGeoIp(bForwardedFor);
  visit.Ip = bForwardedFor;
  // the following needs to be set for the reverse dns lookup done by Sitecore
  // be performed on the right IP
  visit.RDNS = rdns;

  // feel free to eliminate that or change the default logging level to Debug
  // to stop it from poluting your logs
  Sitecore.Diagnostics.Log.Info(String.Format(
    "Proxy overridden IP address: original [{0}.{1}.{2}.{3}] "+
    "replaced by [{4}] from header '{5}'.",
    proxyIp[0], proxyIp[1], proxyIp[2], proxyIp[3],
    forwardedFor, headerUsed), visit);
  }
}

Now you may wonder why do I use more than one signature? The problem is that both CDN-s and proxy servers have a tendency to abuse the “x-forwarded-for” header, for example some append their IP in the beginning rather than append it as a last. This, together with potentially having a number of proxies on the way is why we usually configure the CDN instances for our clients to put the real user IP address in an additional field that we can reliably parse.
Pawel Cegielski (our local Cognifide’s CDN guru) will writing more about that on his blog.

Now to integrate it with the Sitecore CreateVisit pipeline add the reference to your class as the first line in the createVisit section of the sitecore.analytics.config file similarly to the following:

<createVisit>
  <processor type="Cognifide.SiteCore.Framework.Facilities.Analytics.CreateVisitForProxy,Cognifide.SiteCore.Framework"/>
  ...
</createVisit>

Your analytics should now work as if the proxy or CDN was never there…

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:

cd VPP:\
cd \Documents\
get-childitem -recurse |
    copy-item -destination \DocumentsNonVersioningVPP\

This worked well but flattened the directory structure – in other words useless for our client.

I’ve tried what should work in a plain PowerShell:

cd VPP:\
copy-item -path vpp:\Documents\*
          -destination vpp:\DocumentsNonVersioningVPP\
          -recurse -force

Now that didn’t work at all, and turned out to be a bug in my PowerShell plugin’s PSDrive provider. Unfortunately when I attempted to fix it by implementing the copy in the naive way – using UnifiedDirectory’s  Copy method I’ve run into the same exception about incompatibility between the classes that I’ve seen when trying to copy the files form the file manager.

Mmmkay… I’ll just implement the recursion myself…

A quarter later the new version of PowerShell plugin is operational and… I have an excuse for another blog post.

Additionally – since the client solution required it – this version will be compatible with a wider variety of EPiServer versions as it had to be compiled against build 5.2.375.133 instead of 5.2.375.236.

[Download & Enjoy]

When downloading the plugin

always look for the latest blog post about it to get the most recent version!

How to install?

Extract the DLL form the ZIP file into the BIN folder of your web application to install the plugin. Remove the DLL to uninstall it.

All feedback appreciated!

In lieu of the regular disclaimer:

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