Saturday, November 1, 2014

Sitecore PowerShell Extended with Gutters

Recently I challenged myself to find integrations with Sitecore PowerShell Extensions that have not yet been published. I saw this cool  article by ParTechIT and knew it was something I had to try. Of course I have to tell someone when I get it figured out.

After having already extended with pipelines I didn't expect this to take very long. 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 when rendering gutters so that I don't have to compile the GutterRenderer.
As a spe user, the script can be configured just like any other GutterRender, so that I don't have to further complicate the setup.

Acceptance Criteria:

  • The gutter rendering scripts must reside under the following path:
    • /sitecore/system/Modules/PowerShell/Script Library/Content Editor/Gutters
  • The GutterRenderer must be configured under the following path:
    • /sitecore/content/Applications/Content Editor/Gutters
  • The example GutterRenderer must be stolen.
Some concepts you will see in this article:
  • Creating a GutterRenderer using Windows PowerShell code in SPE.
  • Configuring a GutterRenderer in Sitecore
First we begin with creating a new class in our Sitecore.SharedSource.PowerShell library. The class to create in this example is called GutterStatusRenderer.
using System;
using Cognifide.PowerShell.PowerShellIntegrations.Host;
using Cognifide.PowerShell.PowerShellIntegrations.Settings;
using Sitecore.Configuration;
using Sitecore.Data;
using Sitecore.Data.Items;
using Sitecore.Diagnostics;
using Sitecore.Shell.Applications.ContentEditor.Gutters;

namespace Sitecore.SharedSource.Gutters
    // Inherit from the GutterRenderer in order to override the GetIconDescriptor.
    public class GutterStatusRenderer : GutterRenderer
        // We override the GetIconDescriptor so a script can be called in it's place.
        protected override GutterIconDescriptor GetIconDescriptor(Item item)
            // The scriptId parameter is configured when we create a new gutter
            // here /sitecore/content/Applications/Content Editor/Gutters
            if (!Parameters.ContainsKey("scriptId")) return null;

            var scriptId = new ID(Parameters["scriptId"]);

            var db = Factory.GetDatabase("master");
            var scriptItem = db.GetItem(scriptId);

            // If a script is configured but does not exist then return.
            if (scriptItem == null) return null;

            // Create a new session for running the script.
            using (var session = new ScriptSession(ApplicationNames.Default))
                var script = (scriptItem.Fields[ScriptItemFieldNames.Script] != null)
                    ? scriptItem.Fields[ScriptItemFieldNames.Script].Value
                    : String.Empty;

                // We will need the item variable in the script.
                session.SetVariable("item", item);

                    // Any objects written to the pipeline in the script will be returned.
                    var output = session.ExecuteScriptPart(script, false);
                    foreach (var result in output)
                        if (result.GetType() == typeof (GutterIconDescriptor))
                            return (GutterIconDescriptor) result;
                catch (Exception ex)
                    Log.Error(ex.Message, this);

            return null;

Second we need to create a new Gutter library and a Publication Status script. We'll come back to the content of the script later.

Third we need to create a new Gutter in the "core" database.

If you recall from the source code above, the scriptId indicates which script to call for this GutterRenderer. This will allow you to use the same GutterStatusRenderer class for all your gutter needs.

Finally we need to write our script. You'll notice that it's almost exactly what was stolen from ParTechIT, in PowerShell form.

    Adapted from:

# The $item variable is populated in the GutterStatusRenderer class using session.SetVariable.
if(-not $item) {
    Write-Log "The item is null."
    return $null
$publishingTargetsFolderId = New-Object Sitecore.Data.ID "{D9E44555-02A6-407A-B4FC-96B9026CAADD}"
$targetDatabaseFieldId = New-Object Sitecore.Data.ID "{39ECFD90-55D2-49D8-B513-99D15573DE41}"

$existsInAll = $true
$existsInOne = $false

# Find the publishing targets item folder
$publishingTargetsFolder = [Sitecore.Context]::ContentDatabase.GetItem($publishingTargetsFolderId)
if ($publishingTargetsFolder -eq $null) {
    return $null

# Retrieve the publishing targets database names
# Check for item existance in publishing targets
foreach($publishingTargetDatabase in $publishingTargetsFolder.GetChildren()) {
    Write-Log "Checking the $($publishingTargetDatabase[$targetDatabaseFieldId]) for the existence of $($item.ID)"
    if([Sitecore.Data.Database]::GetDatabase($publishingTargetDatabase[$targetDatabaseFieldId]).GetItem($item.ID)) {
        $existsInOne = $true
    } else {
        $existsInAll = $false

# Return descriptor with tooltip and icon
$tooltip = [Sitecore.Globalization.Translate]::Text("This item has not yet been published")
$icon = "People/16x16/flag_red.png"

if ($existsInAll) {
    $tooltip = [Sitecore.Globalization.Translate]::Text("This item has been published to all targets")
    $icon = "People/16x16/flag_green.png"
    Write-Log "Exists in all"
} elseif ($existsInOne) {
    $tooltip = [Sitecore.Globalization.Translate]::Text("This item has been published to at least one target")
    $icon = "People/16x16/flag_yellow.png"
    Write-Log "Exists in one"

$gutter = New-Object Sitecore.Shell.Applications.ContentEditor.Gutters.GutterIconDescriptor
$gutter.Icon = $icon
$gutter.Tooltip = $tooltip
$gutter.Click = [String]::Format("item:publish(id={0})", $item.ID)

Here's the final result.

That's pretty much it. Happy coding!


// Mikey

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

Friday, September 26, 2014

Sitecore Custom Login Details With Version

It sure has been a while since I last posted anything interesting...or anything at all! I recently spoke with +Michael Reynolds about blogging but rather than blog I decided to read all the tweets about the Sitecore Symposium :(

Now it's time to pick it back up. What you will see in here isn't all that new, but it is however very useful. Also, at the bottom I have listed a few blogs I know of that cover the same topic. Two of which are far more interesting than mine so be sure to have a look.

Recently at work an issue came up where the QA team did not know if the test environment had the correct build applied (TDS package). I decided to use some old code from a version page I created for the same issue with an applications.

The following is a list of files that we will create to make the magic happen.

  • ReflectionUtil.cs : Generic reflection code to extract version details from the loaded assembly.
  • ApplicationDetails.cs : Pipeline to extract version information.
  • Sitecore.SharedSource.Version.config : Pipeline configuration

The final results are clean and simple.

The following is a list of other posts I found helpful.

Saturday, June 14, 2014

PowerShell Revisited - Running Commands

Running PowerShell Commands
The command Get-Verb is an example of a cmdlet (pronounced "command-let"). Cmdlets are structured verb-noun, where the noun is singular.
Below we will get a list of approved verbs in PowerShell, then format the results to fill the screen from left to right:
PS C:\> Get-Verb | Format-Wide -AutoSize
Add           Clear         Close         Copy         Enter        Exit         Find         Format       Get
Hide          Join          Lock          Move         New          Open         Optimize     Pop          Push
Redo          Remove        Rename        Reset        Resize       Search       Select       Set          Show
Skip          Split         Step          Switch       Undo         Unlock       Watch        Backup       Checkpoint
Compare       Compress      Convert       ConvertFrom  ConvertTo    Dismount     Edit         Expand       Export
Group         Import        Initialize    Limit        Merge        Mount        Out          Publish      Restore
Save          Sync          Unpublish     Update       Approve      Assert       Complete     Confirm      Deny
Disable       Enable        Install       Invoke       Register     Request      Restart      Resume       Start
Stop          Submit        Suspend       Uninstall    Unregister   Wait         Debug        Measure      Ping
Repair        Resolve       Test          Trace        Connect      Disconnect   Read         Receive      Send
Write         Block         Grant         Protect      Revoke       Unblock      Unprotect    Use

Microsoft has provided a nice page on the verb naming rules which can be found here.
The commands you use in cmd.exe can also be used within PowerShell since they are either aliased, new functions, or the external executable is called.
  • dir is an alias for Get-ChildItem
  • md is an alias for mkdir which is a function for New-Item
  • rmdir is an alias for Remove-Item
Some easy commands that just work:
  • Get-Process
  • Get-Service
  • Get-Date
  • Get-HotFix
  • Get-History
  • Start-Transcript, Stop-Transcript
  • Get-ChildItem
Now you may be wondering why the names seem so generic. The idea is that if the names are consistent then you can easily discover new commands. In addition, some commands can be reused in multiple areas such as managing the registry and filesystem. Here is a good example with Get-PSDrive:
PS C:\> Get-PSDrive

Name           Used (GB)     Free (GB) Provider      Root                                               CurrentLocation
----           ---------     --------- --------      ----                                               ---------------
Alias                                  Alias
C                  81.37        151.42 FileSystem    C:\
Cert                                   Certificate   \
E                                      FileSystem    E:\
Env                                    Environment
Function                               Function
HKCU                                   Registry      HKEY_CURRENT_USER
HKLM                                   Registry      HKEY_LOCAL_MACHINE
I                1112.16        305.87 FileSystem    \\chs-fs01_users\Users\Michael.West
Variable                               Variable
WSMan                                  WSMan
Y                   8.88          3.12 FileSystem    \\chs\data

PowerShell uses a variety of providers such as those for connecting to the file system and the registry. This design allows one to use for example, the Remove-Item command to delete a file or delete a registry key. Sweet!
PS C:\> $item = New-Object -TypeName PSObject -Property @{Name="Michael";Height=73;}
PS C:\> $item | Format-List

Height : 73
Name   : Michael

Here I created a new PSObject to contains some details about my name and height. Let's see the member information.
PS C:\> $item | Get-Member

   TypeName: System.Management.Automation.PSCustomObject

Name        MemberType   Definition
----        ----------   ----------
Equals      Method       bool Equals(System.Object obj)
GetHashCode Method       int GetHashCode()
GetType     Method       type GetType()
ToString    Method       string ToString()
Height      NoteProperty System.Int32 Height=73
Name        NoteProperty System.String Name=Michael

As you can see, the TypeName is "System.Management.Automation.PSCustomObject" and the new properties "Name" and "Height" are listed. The object type will be relevant to whatever object is piped in to Get-Member.

Gets the Windows PowerShell drives in the current session.
# Displays details about the local disk C.
Get-PSDrive C
Random fact:
Try this: (Get-PSDrive)[0].Name <# Returns the name of the first object. #>
Try this: (Get-PSDrive)[0].GetType() <# Returns the type of the first object. #>
Sets the current working location to a specified location.
# Changes the location to the registry hive HKEY_LOCAL_MACHINE. The colon is required.
Set-Location HKLM:

PS C:\> Set-Location HKLM:
PS HKLM:\> Set-Location C:
PS C:\> Set-Location Alias:
PS Alias:\> dir | more

CommandType     Name                                               ModuleName
-----------     ----                                               ----------
Alias           % -> ForEach-Object
Alias           ? -> Where-Object
Alias           ac -> Add-Content
Alias           asnp -> Add-PSSnapin
Alias           cat -> Get-Content
Alias           cd -> Set-Location
Alias           chdir -> Set-Location
Alias           clc -> Clear-Content
Alias           clear -> Clear-Host
Alias           clhy -> Clear-History
Alias           cli -> Clear-Item
As you can see in the image above, I changed to the registry, then the C drive, then to Alias. In all of these locations, you can run the standard commands such as dirlscd and so on. In the image you can also see that cd is an alias for Set-Location.
Below are some command aliases common in other environments.
Copy-Itemcpi, cp, copy
ForEach-Objectforeach, %
Get-ChildItemdir, ls
Get-Contentgc, type, cat
Get-Locationgl, pwd
Move-Itemmi, mv, move
Rename-Itemrni, ren
Set-Locationcd, chdir
Where-Objectwhere, ?
Remove-Itemri, rd, del, rm, rmdir
Random fact:
To count the number of items return, use Measure-Object. Use additional switch parameters such as -Sum and -Average.
Try this: Get-Process | Measure-Object <# Returns a table with the results of Measure-Object. #>
Try this: (Get-Process | Measure-Object).Count <# Returns the count value. #>
Gets the content of the item at the specified location.
# Reads the entire contents of the file.
Get-Content -Path C:\log.txt
Adds content to the specified items, such as adding words to a file.
# Appends the text to the file log.txt.
Add-Content -Path C:\log.txt -Value "The quick brown fox jumps over the lazy dog."
Sends output to a file.
# The first command takes a snapshot of all the running processes. 
# The list passed through pipeline to Out-File which is then written to log.txt.
Get-Process | Out-File -FilePath C:\log.txt
Writes customized output to a host. The information is not kept in the pipeline.
# The text is written to the console window.
Write-Host "This text is written to the host, such as the console window."
Sends the specified objects to the next command in the pipeline. If the command is the last command in the pipeline, the objects are displayed in the console.
# The snapshot of running processes is saved into the variable p. The variable p is then written to the console window.
$p = Get-Process; Write-Output -InputObject $p
The text is written to the verbose message stream. This is commonly used in PowerShell scripts.
# The text is written to the verbose stream. If the switch -Verbose is used, the text will be written to the console window.
Write-Verbose -Message "The quick brown fox jumps over the lazy dog."

Creates a new item. The item can be a new registry key, file, directory, etc. The type of item created depends on which provider you are connected to.
# A new file is created with the specified text.
New-Item -Path C:\ -Name log.txt -ItemType "file"
New-Item -Path C:\log.txt -ItemType "file" -Value "The quick brown fox jumps over the lazy dog."

Monday, June 2, 2014

Sitecore PowerShell Extensions Manual

This document is a work in progress. Hopefully as you continue to refer to this you'll see the updates.

Saturday, May 3, 2014

Archive Log Files with Sitecore PowerShell Extensions

The other day I was talking to Mike Reynolds (@mike_i_reynolds) about his idea of a FileWatcher for the Sitecore CMS log files. That sounded like a great opportunity to use the Sitecore PowerShell Extensions module found on the Sitecore Marketplace.

The process can be broken down into these few steps:

  1. A scheduled task to run a script
  2. The script zips up the log files and saves to an archive folder
Below are the scripts to get the job done.

I added the Compress-Archive script here: /sitecore/system/Modules/PowerShell/Script Library/Functions/Compress-Archive
I then added the Archive Logs script here: /sitecore/system/Modules/PowerShell/Script Library/Tasks/Archive Logs

Finally, I created the scheduled task using the PowerShellScriptCommand.
You'll notice here that I'm using a custom field for the Task Scheduler so it's easier to see what's configured.

These scripts should be included in a future build of Sitecore PowerShell Extensions but feel free to start using now!

Sunday, April 6, 2014

Sitecore Code Editor 1.4 Preview

It's raining today here in Dallas which probably explains why I sound like I'm falling asleep in the video. Here's a preview of enhancements to Code Editor 1.4.

Reports with Sitecore PowerShell Extensions

I was trolling through the Sitecore Marketplace the other day and found this cool module for reporting about media library items called Unused Media Manager. I thought this would be a great example of how you can adapt code that would traditionally be written in C# and turn it into a simple script in Powershell.

Here's a quick example of where the new scripts appear within the Sitecore tree.

As you can see, SPE provides a reports folder where you can add scripts that will appear under Reporting Tools > PowerShell Reports.

I selected the Unused media items script which produced the following results:
The above window is produced by using the "Show-ListView" command.

Wednesday, February 5, 2014

Format Excel Column for Size in GB

Today I was doing some reporting on file sizes and saw that I had columns with data in bytes. When you are looking at the length in gigabytes it can get kinda crazy.
Here's a simple trick:
Format the column with a custom setting and paste this in the format
[<500000]#,##0" B ";[<500000000]#,##0,," MB";#,##0,,," GB"

Original article here

Tuesday, January 21, 2014

Site Down for Maintenance

Here is something that I've been trying to setup as part of our deployment process. The goal is to provide users with a site maintenance page during the deployment. We do not require 100% up-time so this solution should meet our needs. I found additional details here which work pretty nice.


  1. Copy App_Offline.htm.disabled to the website directory and move to App_Offline.htm
  2. Copy the application’s Web.config to Web.config.backup and move Web.config.disabled to Web.config, replacing the original
  3. Test that the offline page is rendered
  4. Deploy file system changes
  5. Move Web.config.backup to Web.config, replacing the temporary file
  6. Delete App_Offline.htm

Friday, January 17, 2014

Report Duplicate AD Users By EmployeeID

Note: The employeeID is formatted to 7 characters so that if you had numbers with leading 0s they would still be matched.