November 17th, 2011 by Adam Najmanowicz | 2 Comments
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âŚ
November 17th, 2011 by Adam Najmanowicz | 58 Comments
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?
November 17th, 2011 by Adam Najmanowicz | 58 Comments
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?
October 5th, 2011 by Adam Najmanowicz | 69 Comments
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:
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:
$page = Get-CurrentPage;
$changedBy = $page.ChangedBy;
$me = [EPiServer.Security.PrincipalInfo]::Current;
$myName = $me.Name;
if ($changedBy -eq "")
{ "Unspecified author - a system page?" }
elseif ($changedBy -eq $myName)
{ "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-CurrentPage;
switch ($page.PageChildOrderRule) {
0 {"Undefined sort order. "}
1 {"Most recently created page will be first in list"}
2 {"Oldest created page will be first in list"}
3 {"Sorted alphabetical on name"}
4 {"Sorted on page index"}
5 {"Most recently changed page will be first in list"}
6 {"Sort on ranking, only supported by special controls"}
7 {"Oldest published page will be first in list"}
8 {"Most recently published page will be first in list"}
default {"No idea what that means!"}
}
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).
Windows PowerShell
PowerShell Console for EPiServer
Interactive ? command can ask for confirmations and can be aborted. User can be solicited to provide input.
Batch ? all commands are being executed in one go, the script has no chance to ask questions, go or no-go decisions have to be solved within the script.
Supports colouring.
Supports plain text output only.
Supports command line arguments for running scripts.
All arguments are defined directly within the script or derived from context automatically.
Can access any file depending on the rights of the user.
Can only access files the web application identity can write to. Cannot access files on user?s machine but rather operates on the server?s file system. Cannot operate with elevated privileges.
That said, I considered that enough of the Reference document is irrelevant in the EPiServer 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 EPiServer admin or developer.
Ok, so I?ve got my shot of endorphins writing about PowerShell last week (damn, it?s nice to be able to code again!), and I got pretty determined on making it usable and achieving all the goals I?ve initially envisioned. and in the process build a usable tool and a library of scripts that people can use either directly or to modify to meet their needs.
The goal for this week: Context Scripts
Context scripts are the first step to break the scripting out of the admin realm and into the editor?s space. Those scripts will still be written by admins and developers but the goal is for them to be usable by the authors. The goal for those scripts can be as trivial as e.g. syndicating all the great functionality little plugins like this Unpublish button by Ted in one place and then mix and match them to your liking.
Some of the important bits:
Context scripts are something that is visible to users on ?Scripts? page.
Scripts can be exposed to everyone or just the groups of your liking? you define it in the script.
Scripts are grouped in collections that are defined in *.psepi files that you drop into your application folder
Itâs been a while since I had a chance to do any coding… turns out leading a development division tends to not have much to do with development⌠who knew?!
But Iâve finally got a moment to sit down and refresh the EPiServer PowerShell console and make it compatible with both CMS versions 5 & 6. You could technically use it before on CMS 6 but the looks of it was broken. (previous version available here)
What triggered it was a talk with Michael Sadler earlier this week. Michael is a technical consultant by day (and a musician by night) in our solutions team in London. We talked how he was doing a content audit for a client in one of the other CMSâes weâre supporting. Which really sounded like a daunting task⌠The content got exported as XML and then he had to write a bunch of C# code to parse it and create statistics for e.g. how many people edit the content, who created the majority of the content etc⌠well I couldnât resist but to bragâŚ
looks through all the pages, and counts how many articles by each author there are in the CMS. Naturally you can also do it on a sub-branch of content as well.
Iâm sorry Michael you had to go through this without PowerShellâŚ
Deployment
The plugin will detect the version of EPiServer itâs running under and will skin itself appropriately to match the CMS style.
As far as I can tell, your PowerShell scripts will be interchangeable between the versions, as far as they themselves donât touch any API thatâs undergone a breaking change.
It?s been a while since I had a chance to do any coding… turns out leading a development division tends to not have much to do with development? who knew?!
But I?ve finally got a moment to sit down and refresh the EPiServer PowerShell console and make it compatible with both CMS versions 5 & 6. You could technically use it before on CMS 6 but the looks of it was broken. (previous version available here)
What triggered it was a talk with Michael Sadler earlier this week. Michael is a technical consultant by day (and a musician by night) in our solutions team in London. We talked how he was doing a content audit for a client in one of the other CMS?es we?re supporting. Which really sounded like a daunting task? The content got exported as XML and then he had to write a bunch of C# code to parse it and create statistics for e.g. how many people edit the content, who created the majority of the content etc? well I couldn?t resist but to brag?
looks through all the pages, and counts how many articles by each author there are in the CMS. Naturally you can also do it on a sub-branch of content as well.
I?m sorry Michael you had to go through this without PowerShell?
Deployment
The plugin will detect the version of EPiServer it?s running under and will skin itself appropriately to match the CMS style.
As far as I can tell, your PowerShell scripts will be interchangeable between the versions, as far as they themselves don?t touch any API that?s undergone a breaking change.
Warning: Use of undefined constant php - assumed 'php' (this will throw an Error in a future version of PHP) in /home/users/najmanowicz/public_html/najmanowicz_www/wordpress/wp-content/themes/404-at-ie7/sidebar.php on line 60
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.
Loading...
