Coding and the Dangers of Familiarity: Keep Your Senses Sharp

When I started at my current company, we essentially had one major project that everyone in the team worked on. It was a client that we had been working with for a long time.  It was a fun project to work on, and I learned a lot about ASP.NET MVC and Sitecore. Even when the project closed, I had no regrets about working on it for nearly two years, with very little other projects coming up during that time.

It wasn’t until the project closed that I realized how it programmed me into doing a certain set of coding practices. They weren’t particularly bad practices, but you could say they weren’t the accepted, best way of doing things. Soon, I was being assigned to projects where the best practices and/or frameworks were in use and I was expected to use those. I’ll give you two key examples, which were both shocking once I realized what I had not done:

  • Glass Mapper. I started a new project where Glass was being used extensively. I had some small training/research on Glass in the past, but this was first project where I had to use it. I did end up using it somewhat effectively, but what shocked me was how suddenly, my defensive coding instincts did not kick in. For example, for 1.5-2.0 years, I was used to doing this:
if (item != null && item.Fields["Heading"] != null && !string.IsNullOrEmpty(item.Fields["Heading"].Value))

The second I would use .Fields[] call in Sitecore development, I would know to do extensive null checks; it’s the way I was trained – but now, I was not using that call anymore. The code was completely different, and so I did not even think of checking for null for some reason. I don’t know why I wouldn’t check for null – maybe I thought Glass would take care of it and never return null? Silly me.

  • Logging. I learned Sitecore development in an environment where I never had to add logging in case an error occurs. My former co-workers that wrote the site added a global try/catch around everything, so that whenever some code in a controller errors out, the details of the error would be entered into a record in an Exception (SQL) table. Essentially, I very rarely or never had to use Log.Error to write an error to the Sitecore log, since the Exception table would always catch that. Well, this convenience turned me into a poor developer; I realized this as soon as some code I wrote went live for a new project. It unexpectedly errored out, but I had no way of finding out what the error was because the site had a custom error page.

This is just my personal experience, and I don’t mean to rag on the project that taught me how to do Sitecore development, but the point I’m trying to make is: if you do the same thing over and over, and suddenly have to do something new, make sure you do some common sense checks before committing the code; namely:

  • Null check all the things.
  • Log information, warnings and errors for each functional part of the code that will be running.
  • Also, will your change negatively affect something that you did not intend? Carefully observe the differences between your new code and the old code.

Additionally, If you’ve been working on one project for a long time, and the development practices generally used in that project are not optimal, keep you coding senses sharp by learning about the best practices in your spare time. Read articles, watch videos, create a Sandbox project which includes those better practices in use. If you have any similar experiences, I would love to read them – thanks!


Sitecore Security Acronyms – ar|au|pe|pd – What Do They Mean?

If you’ve ever explored the SharedFields table of the Sitecore content database, you might have noticed occasionally seeing field values like this:

ar|sitecore\Sitecore Client Maintaining|pe|+item:create|+item:delete|+item:publish|+item:write|pd|+item:create|+item:delete|+item:publish|+item:write|

You may also notice that the FieldId you see in rows that contain that value is always the same. It’s the __Security field of course, which is a shared field used across all Sitecore items. Makes sense, we are querying a table called SharedFields.

So what does this field value mean? To find this out, I simply checked the value of the __Security field on the item specified in the row. You may have to check Standard fields in the View tab to see this field. Scroll down to the Security field section and expand it, and you will see the permissions that role has to this item. You can also see the original string if you check Raw values in the View tab.

To understand what the four individual acronyms mean, I had to do some educated guessing based on how the permissions appear in Access Viewer:

  • ar – Permission applies to a role
  • au – Permission applies to a user
  • pe – Item-level permissions
  • pd – Descendant-level permissions

Additionally, a + sign in front of an item:action means permission was granted. A – sign means permission was denied.

I didn’t really have to know this, I was just curious. Hopefully this explains it for others out there too. If you have any additional information to share, please leave a comment!


How to Disable or Enable a Field in SPEAK

I’m not sure if Sitecore Rocks is the only way to do this, but I recently had to enable a disabled field of a SPEAK form. I figured you would be able to change field settings  in the content editor of Core, but I couldn’t find any way to do it from there. This post will describe how to change field properties through Sitecore Rocks; if there is another way to do this, please let me know through the comments. In my case, I was using SPEAK 2 with Sitecore 8.1.

  1. Open your instance via Sitecore Rocks and navigate to your app’s task page in the Core database.
  2. Right click the Item and select Tasks -> Design Layout.
  3. You should see some fields under Renderings and Placeholders. Double click the field you wish to edit.
  4. On the right, a properties dialog will appear.
    1. To disable the field – which will prevent text entry and make the background gray – set IsEnabled to False, IsReadOnly to True and add disabled=disabled to the  Parameters field.
    2. To enable the field, set IsEnabled to True, IsReadOnly to False and remove the disabled=disabled parameter.

Hopefully this helps other SPEAK developers out there! Feedback is appreciated.

Executing a mass check-in of locked items in Sitecore

Recently I was tasked with finding a way to check-in all locked items in a client’s Sitecore environment. Since Sitecore allows you to lock items for editing to prevent concurrent modifications, and some users never removed their lock, we had a frequent problem with items that were locked by users that did not even work there anymore.

The method of accomplishing this was pretty clear from the get-go. It was time for another Sitecore PowerShell Extensions script!

Creating our Script

I knew PowerShell was the answer, but I wasn’t too well versed with it yet. Sitecore PowerShell Extensions (SPE) is pretty powerful though, since you can access the Sitecore item API through it just as you would through code, so I knew it wouldn’t be that hard once I got through the necessary hiccups.

The logic:

  • Start in the context of the master database.
  • Loop through every item in the content tree, recursively.
  • Then, loop through every version of the current item, since it’s possible that only some of the versions of an item will be locked.
  • Check if the item is locked. If so, open it for editing and unlock it. Then close it for editing.

The script:

<# .SYNOPSIS Check in all locked items in master. .BY Paul Aldrich .DATE 5/3/2017 .UPDATE LOG #>
Write-Host "Starting work in the context of the 'master' database."
Set-Location -Path master:\content
$itemsProcessed = 0;
$itemsUnlocked = 0;
foreach ($item in Get-ChildItem . -Recurse)
   foreach ($version in $item.Versions.GetVersions())
      $itemsProcessed = $itemsProcessed + 1;

      <# For any item in the content node, check if locked. If so, check it in. #>
      if ($version.Locking.IsLocked())
         Write-Host "Unlocking item"
         $itemsUnlocked = $itemsUnlocked + 1;
Write-Host "The script has completed."
Write-Host ("{0} items have been processed." -f $itemsProcessed)
Write-Host ("{0} items were locked and are now checked in." -f $itemsUnlocked)

The script should be pretty straightforward, but let me know if you have any questions in the comments.


This was a really simple, yet powerful script to make, and the best part is its reusability. Don’t forget, you can check your work by running the Locked Items script that comes with SPE and search for locked items by user.

Creating a dynamic image in Rich Text fields

Have you ever inserted an image, then changed its alt or title tags in the Media Library and noticed that the change does not propagate into the rich text field? It’s because Sitecore only inserts static values into the field HTML when you insert an image. If you’ve ever wanted or needed those images to act dynamically – so that changing alt or title text affects the field HTML -then this article might help you.

The Secret? Tokens!

We can modify the rich text editor dialogs so that when a user inserts Sitecore media, the ALT and TITLE text being sent is actually just a token – i.e. {{alt}}. There is no specific syntax required, just use something that you like. That means that we’re actually inserting “{{alt}}” and “{{title}}” into the field HTML, not the actual (static) values. The goal then is to create a pipeline processor that will read the field and look for those tokens, and replace them with the current values of the Alt and Title fields of the media item.

Customizing the InsertImage dialog

The first thing we will want to do is modify the InsertImage dialog. The InsertImage dialog is a Sitecore dialog, and the source can be found with any Sitecore installation. You would need two files:

  1. The InsertImage.xml file for the dialog, which can be found in the webroot of your site under sitecore\shell\Controls\Rich Text Editor/InsertImage.
  2. The InsertImageForm.cs file (code behind file) which can be extracted from the Sitecore.Client.dll. You can use .NET Reflector, DotPeek, or JustDecompile (I personally use the last one). Look for a Sitecore.Shell.Controls.RichTextEditor.InsertImage entry.

You will want to take these two files and preferably put them in your solution. Place these in a new folder, e.g. Controls/RichTextEditor/InsertSitecoreMediaExtended and make the following changes:

  • Keep the .xml file name the same. In the .xml file, there is a line which points to the code behind file – update that with the location of the file in the solution and the assembly name.
  • Update the name of the .cs file to match the parent folder (InsertSitecoreMediaExtended.cs). In that file, remove everything except the OnOK and SetDimensions methods. You will need to modify the OnOK method so that alt and title are set using tokens:
image.Add("Alt", StringUtil.EscapeQuote("{{alt}}"));
image.Add("Title", StringUtil.EscapeQuote("{{title}}"));

Optional: You can edit the Telerik.Web.UI.Editor.DialogControls.SetImageProperties dialog by adding a title field and checkboxes next to the alt and title fields to make it easier for content editors to specify this option.

Let’s make a new pipeline!

You will want to extend the RenderField pipeline in Sitecore.Kernel, specifically the GetFieldValue processor. So when Sitecore gets the value of the RTE field, we’re going to modify the HTML by swapping tokens for media item values. Create a new folder in your pipelines folder or project named GetFieldValueExtended, and a new class file under it with the same name.

Now you’ll need to tell Sitecore to run your custom processor. There are a few options – patch:before, patch:after or overwrite completely. I personally used the patch:after option. If you choose to overwrite, make sure your processor implements all of the same code as the original. Create a new patch file in the App_Config/Include folder similar to the below. (In my case, the solution has a Processor project.)

<configuration xmlns:patch="">
                    type="MyProject.Processor.RenderField.GetFieldValueExtended, MyProject.Processor"
                    patch:after="processor[@type='Sitecore.Pipelines.RenderField.GetFieldValue, Sitecore.Kernel']" />

In your custom processor class file, set up the Process event with some Asserts and other logic needed before doing the swap. Create the tokens as constants for flexibility. Here is the full code used, which is currently running in a production environment with no issues. I highly recommend HtmlAgilityPack for spelunking in the HTML. (NOTE: The code assumes your production environment Sitecore database is web, which may not be true in your case.)

    public class GetFieldValueExtended
        private const string AltToken = "{{alt}}";
        private const string TitleToken = "{{title}}";

        public void Process(RenderFieldArgs args)
            Assert.ArgumentNotNull(args, "args");
            Assert.ArgumentNotNull(args.Item, "args.Item");
            Assert.ArgumentNotNull(args.Item.Database, "args.Item.Database");
            Assert.ArgumentNotNull(args.GetField(), "args.GetField()");

            if (args.Item.Database.Name.Equals("web"))
                if (args.GetField().Value.Contains(AltToken) || args.GetField().Value.Contains(TitleToken))
                    args.Result.FirstPart =  ReplaceTokens(args.GetField().Value);

        private string ReplaceTokens(string fieldValue)
            if (fieldValue.Contains("img") == false) return fieldValue;

            var document = new HtmlAgilityPack.HtmlDocument();

            foreach (var img in document.DocumentNode.Descendants("img"))
                var imgSrc = img.Attributes["src"];
                if (imgSrc == null) continue;

                // Remove query string from src (if it exists)
                var mediaUrl = CleanImageSource(imgSrc.Value);

                // Get media item ID based on media url
                DynamicLink dynamicLink;
                if (!DynamicLink.TryParse(mediaUrl, out dynamicLink)) continue;
                MediaItem mediaItem = Sitecore.Context.Database.GetItem(dynamicLink.ItemId,
                    dynamicLink.Language ?? Sitecore.Context.Language);

                // Replace the tokens
                if (img.Attributes["alt"] != null && img.Attributes["alt"].Value.Trim() == AltToken)
                    img.Attributes["alt"].Value = mediaItem.Alt;

                if (img.Attributes["title"] != null && img.Attributes["title"].Value.Trim() == TitleToken)
                    img.Attributes["title"].Value = mediaItem.Title;

            return document.DocumentNode.OuterHtml;

        private string CleanImageSource(string imgSrcValue)
            // First match the SHA1
            var shaMatcher = new Regex("\b[0-9a-f]{5,40}\b");
            var match = shaMatcher.Match(imgSrcValue);

            if (match.Success)
                // Setup media url
                return string.Format("/~/media/{0}.ashx", match.Value);

            return imgSrcValue;



Overall, this was a great feature that the client needed as they tried to make their website ADA compliant, by including the appropriate alt and title text values. I hope this helps you in your Sitecore development adventures.