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:
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.
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.
April 17th, 2013 by Adam Najmanowicz | 108 Comments
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?
January 29th, 2013 by Adam Najmanowicz | 42 Comments
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?).
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.
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.
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
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.
March 31st, 2012 by Adam Najmanowicz | 30 Comments
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.
January 23rd, 2012 by Adam Najmanowicz | 2 Comments
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: Sitecore PowerShell Console cheat sheet â Part 1. In all cases where it made sense Iâve converted the samples to establish them in Sitecore scenarios.
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!"}
}
January 23rd, 2012 by Adam Najmanowicz | 12 Comments
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: Sitecore PowerShell Console cheat sheet ? Part 1. In all cases where it made sense I?ve converted the samples to establish them in Sitecore scenarios.
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!"}
}
January 23rd, 2012 by Adam Najmanowicz | 12 Comments
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: Sitecore PowerShell Console cheat sheet ? Part 1. In all cases where it made sense I?ve converted the samples to establish them in Sitecore scenarios.
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!"}
}
Loading...
