Saturday, October 25, 2014

Sitecore PowerShell Extensions Tip 2 - Set Random Wallpaper

As of late I've spent more time using Sitecore PowerShell Extensions.Today I decided to change the wallpaper with a random image from the media library.

# Get all the first level items in the images folder.
$items = Get-ChildItem -Path "master:\media library\images\"
# Select an item at random.
$item = $items[(Get-Random -Maximum ($items.length - 1))]
$url = [Sitecore.Resources.Media.MediaManager]::GetMediaUrl($item)

# Get the user in need of a refreshed wallpaper.
$user = Get-User -Identity "sitecore\admin" -Authenticated
$user.Profile.SetCustomProperty("Wallpaper", $url)

I hope this encourages you to spend a little more time in SPE.

Wednesday, October 22, 2014

Sitecore PowerShell Extended with Pipelines

Every once in a while I have what I think is a cool idea. Then I have to tell someone.

Thank you Adam for the encouragement. This took me a few days to finally write it all down. Hopefully those reading this will learn something, decide to share it, and point out areas of improvement. Feel free to comment or make suggestions. I expect to add this to a future release of Sitecore PowerShell Extensions (SPE).

User Story:
As a spe user, I can create scripts to run during user logging in, successful login, and logout so that I can automate tasks that are tedious.

Acceptance Criteria:

  • The scripts must fit into one of the available pipelines provided by Sitecore.
    • loggingin
    • loggedin
    • logout
  • The example scripts used must be stolen.

Some concepts you will see in this article:

  • Config include files
  • Pipelines
  • Configuration Factory with hint attribute and raw: prefix
First we begin with creating a new library project in Visual Studio. When we are complete with the example, we'll have a project that looks like this:

Second we need to reference Sitecore.Kernel and Cognifide.PowerShell libraries. You'll find the Cognifide.PowerShell library in the bin directory after installing SPE.

Third we will create our new pipeline processor which will execute our PowerShell scripts. Below is the skeleton of the class.
using Sitecore.Pipelines;

namespace Sitecore.SharedSource.Pipelines
    public abstract class PipelineProcessor<TPipelineArgs> where TPipelineArgs : PipelineArgs
        protected void Process(TPipelineArgs args)

We can go ahead and create our three pipelines to extend the PipelineProcessor. Below is the complete implementation of each pipeline.

using Sitecore.Pipelines.LoggedIn;

namespace Sitecore.SharedSource.Pipelines.LoggedIn
    public class LoggedInScript : PipelineProcessor<LoggedInArgs> { }

using Sitecore.Pipelines.LoggingIn;

namespace Sitecore.SharedSource.Pipelines.LoggingIn
    public class LoggingInScript : PipelineProcessor<LoggingInArgs> { }

using Sitecore.Pipelines.Logout;

namespace Sitecore.SharedSource.Pipelines.Logout
    public class LogoutScript : PipelineProcessor<LogoutArgs> { }

Let's go ahead and setup our script libraries in Sitecore before we create the include config and finish out the implementation of running the scripts.

Now that we have the three pipeline libraries, we can create the include config to map to those. I prefer this solution so I don't have to hard code the GUID for each in compiled code.

<configuration xmlns:patch="">
      <loggingin argsType="Sitecore.Pipelines.LoggingIn.LoggingInArgs">
        <!-- Pipeline to run scripts while the user is logging in. -->
        <processor patch:after="processor[position()=last()]" mode="on" type="Sitecore.Sharedsource.Pipelines.LoggingIn.LoggingInScript, Sitecore.SharedSource.PowerShell">
          <config hint="raw:Config">
            <!-- /sitecore/system/Modules/PowerShell/Script Library/Pipelines/LoggingIn -->
      <loggedin argsType="Sitecore.Pipelines.LoggedIn.LoggedInArgs">
        <!-- Pipeline to run scripts after the user is logged in. -->
        <processor patch:after="processor[position()=last()]" mode="on" type="Sitecore.Sharedsource.Pipelines.LoggedIn.LoggedInScript, Sitecore.SharedSource.PowerShell">
          <config hint="raw:Config">
            <!-- /sitecore/system/Modules/PowerShell/Script Library/Pipelines/LoggedIn -->
      <logout argsType="Sitecore.Pipelines.Logout.LogoutArgs">
        <!-- Pipeline to run scripts when the user logs out. -->
        <processor  patch:after="*[@type='Sitecore.Pipelines.Logout.CheckModified, Sitecore.Kernel']" mode="on" type="Sitecore.Sharedsource.Pipelines.Logout.LogoutScript, Sitecore.SharedSource.PowerShell">
          <config hint="raw:Config">
            <!-- /sitecore/system/Modules/PowerShell/Script Library/Pipelines/Logout -->

The pipeline is pretty standard. I did have to place the LogoutScript pipeline to be placed right after CheckModified, otherwise the username will be anonymous.

Notice the config section inside the processor. I found an example here by Partech which helped to setup the parameters in the config. John West has a nice article explaining the different options.

With that said, I'll show the remaining implementation of the PipelineProcessor. The code follows a few steps:

  1. Read the libraryId configured for the specified pipeline. A static collection would create a problem in this example, so be sure to leave it as it is below.
  2. If the library item contains any scripts, then continue.
  3. For each script defined in the pipeline library create a new session and execute the script. The args parameter is passed as a session variable for use in the scripts.

    public abstract class PipelineProcessor<TPipelineArgs> where TPipelineArgs : PipelineArgs
        protected PipelineProcessor()
            Configuration = new Dictionary<string, string>();

        protected void Process(TPipelineArgs args)
            Assert.ArgumentNotNull(args, "args");

            Assert.IsNotNullOrEmpty(Configuration["libraryId"], "The configuration setting 'libraryId' must exist.");

            var libraryId = new ID(Configuration["libraryId"]);

            var db = Factory.GetDatabase("master");
            var libraryItem = db.GetItem(libraryId);
            if (!libraryItem.HasChildren) return;

            foreach (var scriptItem in libraryItem.Children.ToList())
                using (var session = new ScriptSession(ApplicationNames.Default))
                    var script = (scriptItem.Fields[ScriptItemFieldNames.Script] != null)
                        ? scriptItem.Fields[ScriptItemFieldNames.Script].Value
                        : String.Empty;
                    session.SetVariable("args", args);

                        session.ExecuteScriptPart(script, false);
                    catch (Exception ex)
                        Log.Error(ex.Message, this);

        protected Dictionary<string, string> Configuration { get; private set; }

        public void Config(XmlNode node)
            Configuration.Add(node.Name, node.InnerText);

Finally, create your scripts in the libraries and watch it in action. Each of my example scripts are adapted from other articles and are linked at the end of this post.

That's pretty much it. If you really want to mess with your colleagues, write a script to send them a phony email every time they login and logout.

  • Some scripts you can use. The random desktop background is really useful.

Wednesday, October 8, 2014

Sitecore PowerShell Run Task On Demand

Recently I needed to help a colleague run a scheduled task on-demand. Immediately I thought to myself, Sitecore PowerShell Extensions can do it! I was certain other developers had created a solution, but I needed something quick.

helped by providing one out-of-the-box way to accomplish the task. The short answer is to use the Task Manager. Have a look under Sitecore -> PowerShell Toolbox -> Task Manager

You are then presented with a delightful screen which provides you with options like Execute Now and Edit Schedule.

 also had a good suggestion. Oh wait, that was me :)

This solution creates a context menu item that can be made visible when selecting an item with the Schedule template.

What we'll do here is create a new PowerShell Script item called Run Task, set a rule on it to only appear for the Schedule template, and write some simple code to run the task:

$item = Get-Item -Path .
if($item) {
  $schedule = Get-TaskSchedule -Item $item
  Start-TaskSchedule -Schedule $schedule

You can also confirm that the scheduled task completed successfully by checking the Log Viewer.

(coincidentally with the same last name) did provide a detailed article on an approach that does not the module.
also provided details to a module that provides an alternative experience to the schedule editor.

I hope this helps someone.

// Michael

Sunday, October 5, 2014

Sitecore Code Editor 1.5 Preview

Recently I've spent some time on the Sitecore Code Editor Module to add Markdown support. Back in May I saw a nice article by Dan Cruickshank where he integrated the MarkdownDeep library into Sitecore module. I thought to myself, "If Dan can do it for his module, and I can it for my module!" So here you have it. An implementation of Markdown in the Code Editor module.

There are a few aspects that must be considered when creating a custom field. First, how do you render text so that html doesn't break the content editor. Second, how do you render text so that html doesn't break the page editor.

The magic for the page editor begins here in the GetCodeTextFieldValue pipeline:
            if (Context.PageMode.IsPageEditorEditing)
                // Encode so the page editor will render the html.
                // Replace with line breaks so the spacing is correct.
                args.Result.FirstPart = HtmlUtil.ReplaceNewLines(HttpUtility.HtmlEncode(args.Result.FirstPart));
                args.Result.LastPart = HtmlUtil.ReplaceNewLines(HttpUtility.HtmlEncode(args.Result.LastPart));

The ReplaceNewLines method simply searches for all new line characters and converts to html breaks:
        public static string ReplaceNewLines(string input)
            if (String.IsNullOrEmpty(input)) return input;

            return Regex.Replace(input, @"(\r\n|\n)", "<br />", RegexOptions.Compiled);

In the event that you are not viewing in page editor mode, the code skips and runs the MarkdownRenderer:
            var parameters = args.GetField().Source.ToDictionary(args.Parameters);
            if (!parameters.ContainsKey("mode") || !parameters["mode"].Is("markdown")) return;

            // Decode the html and then convert new lines to html breaks.
            args.Result.FirstPart = MarkdownRenderer.Render(args.Result.FirstPart, parameters);
            args.Result.LastPart = MarkdownRenderer.Render(args.Result.LastPart, parameters);

The content editor mode is handled very similar to page editor in the CodeText class (inherits from Sitecore.Web.UI.HtmlControls.Memo):
        protected string RenderPreview()
            // Renders the html for the field preview in the content editor.
            return String.Format("<div style='height: 100%; overflow: hidden;'>{0}</div>",

        protected override void DoRender(HtmlTextWriter output)
            output.Write("<div {0}>{1}</div>", ControlAttributes, RenderPreview());

As you can see by overriding the DoRender you have access to how the control is rendered. Below is a short video demoing the new functionality.

Have a look out on Github for a more detailed look into the code that makes this module tick.

// Michael