Home » 2016 » May

Monthly Archives: May 2016

Advertisements

Omit Sitecore Bucket Folder Item Names from Page Item URLs

In my two previous posts — this post and this post — I used the Sitecore Rules Engine to determine how bucket folders in the Item Buckets feature should be constructed.

I love having the freedom and flexibility to be able to do this.

However, depending on how you generate these folder structures, you might end up with some pretty yucky — ahem, I mean “interesting” — URLs if you have Actions that generate nonsense bucket folder Item names for bucketed Items.

For example, in my previous post, I built a custom Action that reversed the Item ID of the bucketed Item to generated its bucket folder path:

bucketed-links-bucketed-item-page-bucket-folders-2

Yucky, right?

Yuck

The “out of the box” Item Buckets bucket-folder-structure-generating algorithm creates a nice structure based on when the bucketed Item was created, and this is more palatable when looking at it:

bucketed-links-bucketed-item-page-bucket-folders-1

However, we may not be able to always use this “out of the box” algorithm for whatever reason — who knows what requirements will make us do — so let’s explore some code that can clean up these yucky URLs.

clean-up

Let’s first tackle cleaning up the URL generated by the “out of the box” Sitecore.Links.LinkProvider class.

I decided to implement a custom Sitecore pipeline to clean up the URL generated by the GetItemUrl() of the LinkProvider class, and will call this pipeline from a subclass of it (this code is further down in this post).

If you’re going to create a custom pipeline, you’ll need an arguments object for it — this is technically known as a Parameter Object but I will stick with the name “arguments object” and “arguments class” for the class that these objects are instantiated from throughout this post.

The following class is the arguments class for my custom pipeline:

using System;

using Sitecore.Data.Items;
using Sitecore.Links;
using Sitecore.Pipelines;

namespace Sitecore.Sandbox.Buckets.Pipelines.GetBucketedItemLinkUrl
{
    public class GetBucketedItemLinkUrlArgs : PipelineArgs
    {
        public Func<Item, UrlOptions, string> GetItemUrl { get; set; }

        public UrlOptions UrlOptions { get; set; }

        public Item ItemBucket { get; set; }

        public Item BucketedItem { get; set; }

        public string DefaultUrl { get; set; }

        public string BucketedItemUrl { get; set; }
    }
}

I defined the following abstract class which all processors of the custom pipeline must inherit:

namespace Sitecore.Sandbox.Buckets.Pipelines.GetBucketedItemLinkUrl
{
    public abstract class GetBucketedItemLinkUrlProcessor
    {
        public abstract void Process(GetBucketedItemLinkUrlArgs args);
    }
}

All subclasses must implement the abstract Process method above which takes in the arguments object with the class type defined above.

The following class whose instance is used as the first processor of the custom pipeline checks whether required property values are set on the arguments object passed to the pipeline:

using Sitecore.Diagnostics;

namespace Sitecore.Sandbox.Buckets.Pipelines.GetBucketedItemLinkUrl
{
    public class EnsureParameters : GetBucketedItemLinkUrlProcessor
    {
        public override void Process(GetBucketedItemLinkUrlArgs args)
        {
            Assert.ArgumentNotNull(args, "args");
            if(!CanProcess(args))
            {
                args.AbortPipeline();
            }
        }

        protected virtual bool CanProcess(GetBucketedItemLinkUrlArgs args)
        {
            Assert.ArgumentNotNull(args, "args");
            return args.GetItemUrl != null
                    && args.BucketedItem != null
                    && !string.IsNullOrWhiteSpace(args.DefaultUrl);
        }
    }
}

The BucketedItem, DefaultUrl — this is the “default” URL generated by the GetItemUrl() method on the “out of the box” LinkProvider class, and GetItemUrl — this is a “pointer” to the GetItemUrl method on the LinkProvider class — properties are required by the custom pipeline when initially called, and these are checked here.

This next class who instance is used for the second processor of the pipeline does some vetting of the bucketed Item passed on the arguments object:

using Sitecore.Data.Items;
using Sitecore.Diagnostics;

using Sitecore.Buckets.Extensions;
using Sitecore.Buckets.Managers;

namespace Sitecore.Sandbox.Buckets.Pipelines.GetBucketedItemLinkUrl
{
    public class InspectBucketedItem : GetBucketedItemLinkUrlProcessor
    {
        public override void Process(GetBucketedItemLinkUrlArgs args)
        {
            Assert.ArgumentNotNull(args, "args");
            Assert.ArgumentNotNull(args.BucketedItem, "args.BucketedItem");
            
            if (!IsItemContainedWithinBucket(args.BucketedItem) || !IsParentBucketFolder(args.BucketedItem))
            {
                args.AbortPipeline();
            }
        }

        protected virtual bool IsItemContainedWithinBucket(Item item)
        {
            Assert.ArgumentNotNull(item, "item");
            return BucketManager.IsItemContainedWithinBucket(item);
        }

        protected virtual bool IsParentBucketFolder(Item item)
        {
            Assert.ArgumentNotNull(item, "item");
            return item.Parent.IsABucketFolder();
        }
    }
}

The instance of the class above checks to see whether the bucketed Item is a descendant of an Item Bucket, and also sees if it is contained within a bucket folder. If one of these is not true, the pipeline is aborted.

The following class whose instance serves as the third processor of the custom pipeline gets the bucketed Item’s Item Bucket:

using Sitecore.Data.Items;
using Sitecore.Diagnostics;

using Sitecore.Buckets.Extensions;

namespace Sitecore.Sandbox.Buckets.Pipelines.GetBucketedItemLinkUrl
{
    public class SetItemBucket : GetBucketedItemLinkUrlProcessor
    {
        public override void Process(GetBucketedItemLinkUrlArgs args)
        {
            Assert.ArgumentNotNull(args, "args");
            Assert.ArgumentNotNull(args.BucketedItem, "args.BucketedItem");
            Item item = GetItemBucket(args.BucketedItem);
            if(!IsItemBucket(item))
            {
                args.AbortPipeline();
                return;
            }

            args.ItemBucket = item;
        }

        protected virtual Item GetItemBucket(Item bucketedItem)
        {
            Assert.ArgumentNotNull(bucketedItem, "bucketedItem");
            return bucketedItem.GetParentBucketItemOrParent();
        }

        protected virtual bool IsItemBucket(Item item)
        {
            Assert.ArgumentNotNull(item, "item");
            return item != null && item.IsABucket();
        }
    }
}

Code in the GetItemBucket() method uses the GetParentBucketItemOrParent() extension method of the Item class — this lives in the Sitecore.Buckets.Extensions namespace in Sitecore.Buckets.dll — to get the Item Bucket ancestor for the bucketed Item.

If the Item returned is not an Item Bucket — this check is done in the IsItemBucket() method via another Item class extension method, the IsABucket() method, which also lives in the same namespace as the extension method mentioned above — then the pipeline is aborted.

This next class whose instance serves as the last processor of the custom pipeline generates a URL without the bucket folder names in it:

using Sitecore.Diagnostics;

namespace Sitecore.Sandbox.Buckets.Pipelines.GetBucketedItemLinkUrl
{
    public class SetBucketedItemUrl : GetBucketedItemLinkUrlProcessor
    {
        public override void Process(GetBucketedItemLinkUrlArgs args)
        {
            Assert.ArgumentNotNull(args, "args");
            Assert.ArgumentNotNull(args.GetItemUrl, "args.GetItemUrlMethod");
            Assert.ArgumentNotNull(args.ItemBucket, "args.ItemBucket");
            Assert.ArgumentNotNullOrEmpty(args.DefaultUrl, "args.DefaultUrl");
            string bucketedItemUrl = GetBucketedItemUrl(args);
            if(string.IsNullOrWhiteSpace(bucketedItemUrl))
            {
                args.AbortPipeline();
                return;
            }

            args.BucketedItemUrl = bucketedItemUrl;
        }

        protected virtual string GetBucketedItemUrl(GetBucketedItemLinkUrlArgs args)
        {
            Assert.ArgumentNotNull(args, "args");
            Assert.ArgumentNotNull(args.GetItemUrl, "args.GetItemUrlMethod");
            Assert.ArgumentNotNull(args.ItemBucket, "args.ItemBucket");
            Assert.ArgumentNotNullOrEmpty(args.DefaultUrl, "args.DefaultUrl");
            string itemBucketUrl = args.GetItemUrl(args.ItemBucket, args.UrlOptions);
            if (string.IsNullOrWhiteSpace(itemBucketUrl))
            {
                return string.Empty;
            }

            string baseUrl = GetExtensionlessUrl(itemBucketUrl);
            string pageUrlPart = GetUrlPagePart(args.DefaultUrl);
            if (string.IsNullOrWhiteSpace(pageUrlPart))
            {
                return string.Empty;
            }

            return string.Join("/", baseUrl, pageUrlPart);
        }

        protected virtual string GetUrlPagePart(string url)
        {
            Assert.ArgumentNotNullOrEmpty(url, "url");
            int lastForwardSlashIndex = url.LastIndexOf("/");
            if (lastForwardSlashIndex < 0)
            {
                return string.Empty;
            }

            return url.Substring(lastForwardSlashIndex + 1);
        }

        protected virtual string GetExtensionlessUrl(string url)
        {
            Assert.ArgumentNotNullOrEmpty(url, "url");
            string extensionlessUrl = url;
            int lastDotIndex = extensionlessUrl.LastIndexOf(".");
            if (lastDotIndex < 0)
            {
                return extensionlessUrl;
            }

            return extensionlessUrl.Substring(0, lastDotIndex);
        }
    }
}

I’m not going to go too much into the details of all the code above. It is basically getting the web page name piece of the URL set in the DefaultUrl property on the arguments object, and appends it to the end of the URL of the Item Bucket without an extension (who uses extensions on URLs anyhow? ¯\_(ツ)_/¯ That’s like so 5 years ago. 😉 ).

The resulting URL is set in the BucketedItemUrl property of the arguments object.

Now that we have code to generate bucket-folder-less URLs, we need to use it. I built the following subclass of Sitecore.Links.LinkProvider which calls it:

using System.Collections.Specialized;

using Sitecore.Buckets.Extensions;
using Sitecore.Data.Items;
using Sitecore.Diagnostics;
using Sitecore.Links;
using Sitecore.Pipelines;

using Sitecore.Sandbox.Buckets.Pipelines.GetBucketedItemLinkUrl;

namespace Sitecore.Sandbox.Buckets.LinkProviders
{
    public class BucketedItemLinkProvider : LinkProvider
    {
        private string GetBucketedItemLinkUrlPipeline { get; set; }

        public override void Initialize(string name, NameValueCollection config)
        {
            Assert.ArgumentNotNullOrEmpty(name, "name");
            Assert.ArgumentNotNull(config, "config");
            base.Initialize(name, config);
            GetBucketedItemLinkUrlPipeline = config["getBucketedItemLinkUrlPipeline"];
        }

        public override string GetItemUrl(Item item, UrlOptions options)
        {
            string url = GetItemUrlFromBase(item, options);
            bool shouldGetBucketedItemUrl = !string.IsNullOrWhiteSpace(GetBucketedItemLinkUrlPipeline) 
                                                && !string.IsNullOrWhiteSpace(url) 
                                                && IsParentBucketFolder(item);
            if (!shouldGetBucketedItemUrl)
            {
                return url;
            }

            string bucketedItemUrl = GetBucketedItemUrl(item, options, url);
            if(string.IsNullOrWhiteSpace(bucketedItemUrl))
            {
                return url;
            }

            return bucketedItemUrl;
        }

        protected virtual bool IsParentBucketFolder(Item item)
        {
            Assert.ArgumentNotNull(item, "item");
            return item.Parent.IsABucketFolder();
        }

        protected virtual string GetBucketedItemUrl(Item bucketedItem, UrlOptions options, string defaultUrl)
        {
            GetBucketedItemLinkUrlArgs args = new GetBucketedItemLinkUrlArgs
            {
                GetItemUrl = ((someItem, urlOptions) => GetItemUrlFromBase(someItem, urlOptions)),
                UrlOptions = options,
                BucketedItem = bucketedItem,
                DefaultUrl = defaultUrl
            };

            CorePipeline.Run(GetBucketedItemLinkUrlPipeline, args);
            return args.BucketedItemUrl;
        }

        protected virtual string GetItemUrlFromBase(Item item, UrlOptions options)
        {
            return base.GetItemUrl(item, options);
        }
    }
}

I’ve extended the Initialize() method on the base LinkProvider class to read in the name of the custom pipeline (this is set in the patch configuration file further down in this post).

The overridden GetItemUrl() method grabs the URL generated by the same method on the base class for the passed Item. If the custom pipeline’s name is set; the generated URL isn’t null or empty; and the item lives in a bucket folder, the custom pipeline is called with the required parameters set on the arguments object.

If the custom pipeline generated a URL, it is returned to the caller. If not, the URL generated by the base class’ GetItemUrl() method is returned.

You might be thinking “Excellent, Mike! We have code that fixes the issue. Are we done yet?” Not so fast, dear reader — we need write code so Sitecore can resolve these bucket-folder-less URLs.

Since the URLs no longer contain the full path to the bucketed Item, we need a way to find this Item under the Item Bucket. I created the following interface for classes that can find a bucketed Item by name whose ancestor is the Item Bucket:

using Sitecore.Data.Items;

namespace Sitecore.Sandbox.Buckets.Providers.Items
{
    public interface IFindBucketedItemProvider
    {
        Item FindBucketedItemByName(Item bucketItem, string bucketedItemName);
    }
}

The following class implements the interface above:

using System;
using System.Linq;
using System.Linq.Expressions;

using Sitecore.Buckets.Util;
using Sitecore.ContentSearch;
using Sitecore.ContentSearch.Linq;
using Sitecore.ContentSearch.Linq.Utilities;
using Sitecore.ContentSearch.SearchTypes;
using Sitecore.ContentSearch.Utilities;
using Sitecore.Data;
using Sitecore.Data.Items;
using Sitecore.Diagnostics;

namespace Sitecore.Sandbox.Buckets.Providers.Items
{
    public class FindBucketedItemProvider : IFindBucketedItemProvider
    {
        private ID bucketFolderTemplateId;
        private ID BucketFolderTemplateId
        {
            get
            {
                if(ID.IsNullOrEmpty(bucketFolderTemplateId))
                {
                    bucketFolderTemplateId = GetBucketFolderTemplateId();
                }

                return bucketFolderTemplateId;
            }
        }

        private string PreviewSearchIndexName { get; set; }

        private string LiveSearchIndexName { get; set; }

        private ISearchIndex previewSearchIndex;
        private ISearchIndex PreviewSearchIndex
        {
            get
            {
                if (previewSearchIndex == null)
                {
                    previewSearchIndex = GetPreviewSearchIndex();
                }

                return previewSearchIndex;
            }
        }

        private ISearchIndex liveSearchIndex;
        private ISearchIndex LiveSearchIndex
        {
            get
            {
                if (liveSearchIndex == null)
                {
                    liveSearchIndex = GetLiveSearchIndex();
                }

                return liveSearchIndex;
            }
        }
       
        public virtual Item FindBucketedItemByName(Item bucketItem, string bucketedItemName)
        {
            Assert.ArgumentCondition(!ID.IsNullOrEmpty(BucketFolderTemplateId), "BucketFolderTemplateId", "GetBucketFolderTemplateId() cannot return a null or empty Item ID!");
            Assert.ArgumentNotNull(bucketItem, "bucketItem");
            Assert.ArgumentNotNull(bucketedItemName, "bucketedItemName");

            ISearchIndex searchIndex = GetSearchIndex();
            using (IProviderSearchContext searchContext = searchIndex.CreateSearchContext())
            {
                var predicate = GetSearchPredicate<SearchResultItem>(bucketItem.ID, bucketedItemName);
                IQueryable<SearchResultItem> query = searchContext.GetQueryable<SearchResultItem>().Filter(predicate);
                SearchResults<SearchResultItem> results = query.GetResults();
                if (results.Count() < 1)
                {
                    return null;
                }

                SearchHit<SearchResultItem> hit = results.Hits.First();
                return hit.Document.GetItem();
            }
        }

        protected virtual ISearchIndex GetSearchIndex()
        {
            if (Context.PageMode.IsPreview)
            {
                Assert.IsNotNull(PreviewSearchIndex, "PreviewSearchIndex is null. Double-check the SearchIndexName configuration setting!");
                return PreviewSearchIndex;
            }

            Assert.IsNotNull(LiveSearchIndex, "LiveSearchIndex is null. Double-check the SearchIndexName configuration setting!");
            return LiveSearchIndex;
        }

        protected virtual ISearchIndex GetPreviewSearchIndex()
        {
            Assert.IsNotNullOrEmpty(PreviewSearchIndexName, "PreviewSearchIndexName is empty. Double-check its configuration setting!");
            return GetSearchIndex(PreviewSearchIndexName);
        }

        protected virtual ISearchIndex GetLiveSearchIndex()
        {
            Assert.IsNotNullOrEmpty(LiveSearchIndexName, "LiveSearchIndexName is empty. Double-check its configuration setting!");
            return GetSearchIndex(LiveSearchIndexName);
        }

        protected virtual ISearchIndex GetSearchIndex(string searchIndexName)
        {
            Assert.ArgumentNotNullOrEmpty(searchIndexName, "searchIndexName");
            return ContentSearchManager.GetIndex(searchIndexName);
        }

        protected virtual Expression<Func<T, bool>> GetSearchPredicate<T>(ID bucketItemId, string bucketedItemName) where T : SearchResultItem
        {
            var predicate = PredicateBuilder.True<T>();
            predicate = predicate.And(item => item.Paths.Contains(bucketItemId));
            predicate = predicate.And(item => item.TemplateId != BucketFolderTemplateId);
            predicate = predicate.And(item => item.Parent != bucketItemId);
            predicate = predicate.And(item => item.ItemId != bucketItemId);
            predicate = predicate.And(item => string.Equals(item.Name, bucketedItemName, StringComparison.CurrentCultureIgnoreCase));
            return predicate;
        }

        protected virtual ID GetBucketFolderTemplateId()
        {
            return BucketConfigurationSettings.BucketTemplateId;
        }
    }
}

I’m leveraging the Sitecore.ContentSearch API in the class above to find a bucketed Item with a given name — this is passed as a parameter to the FindBucketedItemByName() method — which is a descendant of the passed Item Bucket.

The GetSearchPredicate() method builds up a “predicate” which basically says “hey, we need an Item that is a descendant of the Item Bucket who is not a bucket folder; isn’t a child of the Item Bucket; isn’t the Item Bucket itself; and has a certain name (though we are ignoring case here)”, and is used by the Sitecore.ContentSearch API code in the FindBucketedItemByName() method.

“Mike, what’s up with the two ISearchIndex instances on the above class?” I have defined two here: one for when we are in Preview mode — I’m using the master search index here — and the other for when we aren’t — this uses the web search index instead.

If results are found, we return the Item instance from the first result in the results collection to the caller.

“Mike, could there ever be multiple Items returned?” Yes, this could happen if we have more than one bucketed Item with the same name, and only the first one in the results collection will be returned. In a future blog post, I will share a solution which will enforce unique Item names for bucketed Items.

Now that we have code that can find a bucketed Item by name under an Item Bucket, we need a custom Item Resolver — this is just a custom <httpRequestBegin> pipeline processor — that uses an instance of the class above to set the context Item for these bucket-folder-less URLs.

The following class does just that:

using System;
using System.Collections.Generic;
using System.Linq;

using Sitecore.Buckets.Extensions;
using Sitecore.Data.Items;
using Sitecore.Diagnostics;
using Sitecore.Pipelines.HttpRequest;

using Sitecore.Sandbox.Buckets.Providers.Items;

namespace Sitecore.Sandbox.Buckets.Pipelines.HttpRequest
{
    public class BucketedItemResolver : HttpRequestProcessor
    {
        private List<string> TargetSites { get; set; }

        private IFindBucketedItemProvider FindBucketedItemProvider { get; set; }

        public BucketedItemResolver()
        {
            TargetSites = new List<string>();
        }

        public override void Process(HttpRequestArgs args)
        {
            Assert.ArgumentNotNull(args, "args");
            if(!ShouldProcess(args))
            {
                return;
            }

            StartProfilerOperation();
            string path = MainUtil.DecodeName(args.Url.ItemPath);
            if (string.IsNullOrWhiteSpace(path))
            {
                EndProfilerOperation();
                return;
            }

            int lastForwardSlashIndex = path.LastIndexOf("/");
            if (lastForwardSlashIndex < 0)
            {
                EndProfilerOperation();
                return;
            }

            string parentPath = path.Substring(0, lastForwardSlashIndex);
            Item parentItem = args.GetItem(parentPath);
            if(parentItem == null)
            {
                EndProfilerOperation();
                return;
            }

            if (!parentItem.IsABucket())
            {
                EndProfilerOperation();
                return;
            }
            
            string bucketedItemName = path.Substring(lastForwardSlashIndex + 1);
            Item bucketedItem = FindBucketedItemByName(parentItem, bucketedItemName);
            if(bucketedItem == null)
            {
                EndProfilerOperation();
                return;
            }

            Context.Item = bucketedItem;
            EndProfilerOperation();
        }

        protected virtual bool ShouldProcess(HttpRequestArgs args)
        {
            return Context.Item == null
                    && Context.Database != null
                    && IsTargetSite()
                    && !string.IsNullOrWhiteSpace(args.Url.ItemPath);
        }

        protected virtual bool IsTargetSite()
        {
            return Context.Site != null
                    && TargetSites != null
                    && TargetSites.Any(site => string.Equals(site, Context.Site.Name, StringComparison.CurrentCultureIgnoreCase));
        }

        protected virtual void StartProfilerOperation()
        {
            Profiler.StartOperation("Resolve current bucketed item.");
        }

        protected virtual void EndProfilerOperation()
        {
            Profiler.EndOperation();
        }

        protected virtual Item FindBucketedItemByName(Item bucketItem, string bucketedItemName)
        {
            Assert.IsNotNull(FindBucketedItemProvider, "IFindBucketedItemProvider must be set in configuration!");
            return FindBucketedItemProvider.FindBucketedItemByName(bucketItem, bucketedItemName);
        }
    }
}

Not to go too much into all of the code above, the Process() method basically determines whether it should move forward on processing the request.

When should it do that? If there isn’t already context Item set; the context Database is set; the request is being made in a targeted site — basically this is just a list of site names sourced in the patch configuration file below which is a list of websites we want this code to run in (we don’t want to this code to run in the “shell” website which is what the Sitecore Desktop and Content Editor use); and have an Item path, then the Process() method should continue.

Other code in the Process() method is extracting out the parent’s page’s Item path; grabs an instance of the parent Item; determines whether it is an Item Bucket — if it’s not, then the code exits; the name of the page Item from URL; and then passes the parent Item and Item name to the FindBucketedItemByName() method which delegates to the FindBucketedItemByName() method on the IFindBucketedItemProvider instance to find the bucketed Item.

If a bucketed Item was found, the Process() method sets this as the context Item. Otherwise, it just exits.

I’m also using profiling code in the above class just as can be seen in the “out of the box” Sitecore.Pipelines.HttpRequest.ItemResolver class — this lives in Sitecore.Kernel.dll.

I then super-glued all of the code above in the following patch configuration file:

<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/">
  <sitecore>
    <buckets>
      <providers>
        <items>
          <findBucketedItemProvider type="Sitecore.Sandbox.Buckets.Providers.Items.FindBucketedItemProvider, Sitecore.Sandbox">
            <PreviewSearchIndexName>sitecore_master_index</PreviewSearchIndexName>
            <LiveSearchIndexName>sitecore_web_index</LiveSearchIndexName>
          </findBucketedItemProvider>
        </items>
      </providers>
    </buckets>
    <linkManager>
      <providers>
        <add name="sitecore">
          <patch:attribute name="type">Sitecore.Sandbox.Buckets.LinkProviders.BucketedItemLinkProvider, Sitecore.Sandbox</patch:attribute>
          <patch:attribute name="getBucketedItemLinkUrlPipeline">getBucketedItemLinkUrl</patch:attribute>
        </add>
      </providers>
    </linkManager>
    <pipelines>
      <getBucketedItemLinkUrl>
        <processor type="Sitecore.Sandbox.Buckets.Pipelines.GetBucketedItemLinkUrl.EnsureParameters, Sitecore.Sandbox" />
        <processor type="Sitecore.Sandbox.Buckets.Pipelines.GetBucketedItemLinkUrl.InspectBucketedItem, Sitecore.Sandbox" />
        <processor type="Sitecore.Sandbox.Buckets.Pipelines.GetBucketedItemLinkUrl.SetItemBucket, Sitecore.Sandbox" />
        <processor type="Sitecore.Sandbox.Buckets.Pipelines.GetBucketedItemLinkUrl.SetBucketedItemUrl, Sitecore.Sandbox" />
      </getBucketedItemLinkUrl>
      <httpRequestBegin>
        <processor patch:before="processor[@type='Sitecore.Pipelines.HttpRequest.ItemResolver, Sitecore.Kernel']"
                   type="Sitecore.Sandbox.Buckets.Pipelines.HttpRequest.BucketedItemResolver, Sitecore.Sandbox">
          <TargetSites hint="list">
            <site>website</site>
          </TargetSites>
          <FindBucketedItemProvider ref="buckets/providers/items/findBucketedItemProvider" />
        </processor>  
      </httpRequestBegin>
    </pipelines>
  </sitecore>
</configuration>

Let’s see if this works.

Let’s insert some bucketed Item links into this Rich Text field on my home Item:

bucketed-links-insert-link-rtf

Let’s insert an internal link to this Item:

bucketed-links-insert-link-1

Let’s insert another link to this Item:

bucketed-links-insert-link-2

Let’s insert yet another internal link — let’s insert a link to this Item:

bucketed-links-insert-link-3

After publishing and navigating to my home page, I see this in the html for the links:

bucketed-links-html-rendered

After clicking on the first link, I’m brought to the bucketed Item but have a look at the URL:

bucketed-links-bucketed-item-page

As you can see it worked!

When I finally got this working, I found myself doing a happy dance:

techno-chicken

techno-chickens

If you have any thoughts on this, please drop a comment.

Advertisements

A Sitecore Item Buckets GutterRenderer to Convey Which Algorithm Was Used for Creating Bucket Folders

In my previous post, I gave a solution which I leverages the Sitecore Rules Engine to create a custom Item Buckets folder structure for storing bucketable Items.

Last night, I had a thought: what if you needed to know which “algorithm” created a given bucket folder structure for an Item Bucket? How could we go about conveying this type of information?

Immediately, the Sitecore Gutter came to mind — it’s a great way to communicate this type of information visually.

mind-outta-gutter

Before I move forward on the solution I started last night and completed today, let me explain what the Sitecore Gutter is, just in case you are unfamiliar with this feature.

The Sitecore Gutter lives here in the Content Editor:

smart-bucket-gutter-sitecore-gutter

If you right-click in this area, you get a context menu to turn on/off Gutter indicators:

smart-gutter-sitecore-gutter-context-menu

I turned on the Item Buckets Gutter indicator, and now can see which Items are Buckets:

smart-gutter-turn-on-buckets-gutter

There is a huge body of blog posts out on the interwebs which give examples on adding to the Sitecore Gutter. Here are a few posts from some fellow Sitecore MVPs which I highly recommend reading (in order of publish date):

I also wrote a post on how to add to the Sitecore Gutter using the Sitecore PowerShell Extensions module. I recommend having a look at that as well. 😉

Now that we are well-versed — or “wicked smaht” as we Bostonians would alternatively say — on what the Sitecore Gutter is, let’s move on to the solution I came up with.

three-stooges-ejoomicated

Just a “heads up”: there is a lot of code in this solution so don’t freak out and/or get too overwhelmed. Stay the course. 😉

curly-bug-out

I first explored Sitecore.Buckets.Gutters.BucketGutter in Sitecore.Buckets.dll to see if I should take note of anything special I need to know about when creating custom Sitecore.Shell.Applications.ContentEditor.Gutters.GutterRenderer — this lives in Sitecore.Kernel.dll and needs to be subclassed when adding to the Sitecore Gutter — subclasses for Item Buckets.

I noticed there is code in there which ascertains whether the Item Buckets feature is turned on/off, and obviously returns a null instance of Sitecore.Shell.Applications.ContentEditor.Gutters.GutterIconDescriptor — this lives in Sitecore.Kernel.dll — via its GetIconDescriptor() method.

I decided I needed to a way to also ascertain this. I came up with the following interface for classes that determined whether a feature is enabled or not:

namespace Sitecore.Sandbox.Determiners.Features
{
    public interface IFeatureDeterminer
    {
        bool IsEnabled();
    }
}

I then implemented the above interface with the following class:

using Sitecore.ContentSearch;
using Sitecore.ContentSearch.Utilities;

using Sitecore.Sandbox.Determiners.Features;

namespace Sitecore.Sandbox.Buckets.Determiners.Features
{
    public class ItemBucketsFeatureDeterminer : IFeatureDeterminer
    {
        public virtual bool IsEnabled()
        {
            return ContentSearchManager.Locator.GetInstance<IContentSearchConfigurationSettings>().ItemBucketsEnabled();
        }
    }
}

The code in the IsEnabled() method basically returns a boolean indicating whether the Item Buckets feature is turned on/off.

We now need classes whose instances can ascertain whether a bucketed Item’s path matches the paths generated by the bucketing algorithms they represent. I created the following class whose instances would serve as a parameters object to these objects:

using System;

using Sitecore.Data;
using Sitecore.Data.Items;

namespace Sitecore.Sandbox.Buckets.Ascertainers
{
    public class BucketFolderPathAscertainerParameters
    {
        public Item BucketItem { get; set; }

        public Item BucketedItem { get; set; }

        public DateTime CreationDateOfNewItem { get; set; }
    }
}

We’re just going to pass the Item Bucket, the bucketed Item and the creation date of the bucketed Item.

Next, we need those objects that ascertain whether a given Item Bucket uses a particular bucketing algorithm for its folder structure. I created the following interface for classes whose instances do just that:


namespace Sitecore.Sandbox.Buckets.Ascertainers
{
    public interface IBucketFolderPathAscertainer
    {
        string GetIcon();

        string GetToolTip();

        bool IsFolderPathMatch(BucketFolderPathAscertainerParameters parameters);
    }
}

After implementing two classes which implemented the interface above, I noticed some code similarities between them, and decided to employ Martin Fowler‘s refactoring technique Pull Up Method to move up these code similarities into a base class — I highly recommend reading his book Refactoring: Improving the Design of Existing Code which discusses this refactoring technique as well as a host of others — to make it easier for creating future subclasses and to hopefully abate the chances of code duplication. That exercise gave birth to the following abstract class:

using System;

using Sitecore.Data;
using Sitecore.Data.Items;
using Sitecore.Diagnostics;

namespace Sitecore.Sandbox.Buckets.Ascertainers
{
    public abstract class BucketFolderPathAscertainer : IBucketFolderPathAscertainer
    {
        private string icon;
        protected string Icon
        {
            get
            {
                Assert.IsNotNullOrEmpty(icon, "Icon must be set in configuration!");
                return icon;
            }
            set
            {
                Assert.IsNotNullOrEmpty(value, "Icon must be set in configuration!");
                icon = value;
            }
        }

        private string toolTip;
        protected string ToolTip
        {
            get
            {
                Assert.IsNotNullOrEmpty(toolTip, "ToolTip must be set in configuration!");
                return toolTip;
            }
            set
            {
                Assert.IsNotNullOrEmpty(value, "ToolTip must be set in configuration!");
                toolTip = value;
            }
        }
        
        public virtual string GetIcon()
        {
            return Icon;
        }

        public virtual string GetToolTip()
        {
            return ToolTip;
        }

        public bool IsFolderPathMatch(BucketFolderPathAscertainerParameters parameters)
        {
            EnsureParameters(parameters);
            ID settingsItemID = GetSettingsItemID();
            Assert.IsTrue(!ID.IsNullOrEmpty(settingsItemID), "GetSettingsItemID() cannot return null or empty!");
            Item settingsItem = parameters.BucketItem.Database.GetItem(settingsItemID);
            Assert.IsNotNull(settingsItem, string.Format("Setting Item does not exist! Make sure it exists! Item ID: {0}", settingsItemID.ToString()));

            string resolvedPath = GetResolvedPath(parameters, settingsItem);
            if (string.IsNullOrWhiteSpace(resolvedPath))
            {
                return false;
            }

            return IsPathMatch(parameters, resolvedPath);
        }

        protected virtual void EnsureParameters(BucketFolderPathAscertainerParameters parameters)
        {
            Assert.ArgumentNotNull(parameters, "parameters");
            Assert.ArgumentNotNull(parameters.BucketItem, "parameters.BucketItem");
            Assert.ArgumentNotNull(parameters.BucketedItem, "parameters.BucketedItem");
            Assert.ArgumentCondition(parameters.BucketItem.Database == parameters.BucketedItem.Database, "parameters.BucketItem.Database", "parameters.BucketItem.Database and parameters.BucketedItem.Database must be the same database");
            Assert.ArgumentCondition(parameters.BucketItem.Axes.IsAncestorOf(parameters.BucketedItem), "parameters.BucketItem", string.Format("parameters.BucketItem", "Bucket Item: {0} must be an ancestor of Bucketed Item: {1}", parameters.BucketItem.ID.ToString(), parameters.BucketedItem.ID.ToString()));
            Assert.ArgumentNotNull(parameters.BucketedItem, "parameters.BucketedItem");
        }

        protected virtual ID GetSettingsItemID()
        {
            return Sitecore.Buckets.Util.Constants.SettingsItemId;
        }

        protected abstract string GetResolvedPath(BucketFolderPathAscertainerParameters parameters, Item settingsItem);

        protected virtual bool IsPathMatch(BucketFolderPathAscertainerParameters parameters, string resolvedPath)
        {
            if (string.IsNullOrWhiteSpace(resolvedPath))
            {
                return false;
            }

            string bucketedFolderPath = parameters.BucketedItem.Paths.ParentPath.Replace(parameters.BucketItem.Paths.FullPath, string.Empty);
            if(bucketedFolderPath.StartsWith("/"))
            {
                bucketedFolderPath = bucketedFolderPath.Substring(1);
            }

            return string.Equals(bucketedFolderPath, resolvedPath, StringComparison.OrdinalIgnoreCase);
        }
    }
}

The Icon and ToolTip property values in the above class live in the patch configuration file further down in this post. The Sitecore Configuration Factory will inject those values into these properties, and the GetIcon() and GetToolTip() will return the values housed in the Icon and ToolTip properties, respectively.

The IsFolderPathMatch() gets the settingsItem Item instance — this Item lives in /sitecore/system/Settings/Buckets/Item Buckets Settings in Sitecore — which is needed by the GetResolvedPath() method — this method is declared abstract and must be implemented by subclasses — whose job it is to get the bucketed Item’s folder path via the algorithm which the subclass implementation represents.

When the algorithm path is return, it is then passed to the IsPathMatch() method which determines if there is a match. If there is a match, true is returned to the caller of the IsFolderPathMatch() method; false is returned otherwise.

The class above combined with its subclasses would be an example of the Template method design pattern in action.

Now, we need a subclass of the above to determine if a bucketed Item’s path was generated by the Sitecore Rules Engine. Since we don’t want the Rules Engine to evaluate the rules defined on /sitecore/system/Settings/Buckets/Item Buckets Settings for the bucketed Item given the Item Bucket’s current state — its “when” Condition will most likely evaluate to false — we need a way to trick the Rules Engine. I came up with the following Condition class that always evaluates to true:

using Sitecore.Rules;
using Sitecore.Rules.Conditions;

namespace Sitecore.Sandbox.Rules
{
    public class AlwaysTrueWhenCondition<TRuleContext> : WhenCondition<TRuleContext> where TRuleContext : RuleContext
    {
        protected override bool Execute(TRuleContext ruleContext)
        {
            return true;
        }
    }
}

There isn’t much going on in the above class. Its Execute() method always returns true.

The following subclass of the BucketFolderPathAscertainer class determines if a bucketed Item’s path was generated by the Sitecore Rules Engine:

using System;
using System.Collections.Generic;

using Sitecore.Data.Items;
using Sitecore.Diagnostics;
using Sitecore.Buckets.Rules.Bucketing;
using Sitecore.Rules;
using Sitecore.Sandbox.Rules;

namespace Sitecore.Sandbox.Buckets.Ascertainers
{
    public class RulesDefinedBucketFolderPathAscertainer : BucketFolderPathAscertainer
    {
        protected override string GetResolvedPath(BucketFolderPathAscertainerParameters parameters, Item settingsItem)
        {
            string bucketRulesFieldId = GetBucketRulesFieldId();
            Assert.IsNotNullOrEmpty(bucketRulesFieldId, "GetBucketRulesFieldId() cannot return null or empty!");
            BucketingRuleContext ruleContext = CreateNewBucketingRuleContext(parameters);
            RuleList<BucketingRuleContext> rules = GetRuleList<BucketingRuleContext>(settingsItem, bucketRulesFieldId);
            SetAlwaysTrueWhenConditions(rules.Rules);
            if (rules == null)
            {
                return string.Empty;
            }

            try
            {
                rules.Run(ruleContext);
            }
            catch (Exception ex)
            {
                Log.Error(ToString(), ex, this);
            }

            return ruleContext.ResolvedPath;
        }

        protected virtual string GetBucketRulesFieldId()
        {
            return Sitecore.Buckets.Util.Constants.BucketRulesFieldId;
        }

        protected virtual BucketingRuleContext CreateNewBucketingRuleContext(BucketFolderPathAscertainerParameters parameters)
        {
            return new BucketingRuleContext(parameters.BucketedItem.Database, parameters.BucketItem.ID, parameters.BucketedItem.ID, parameters.BucketedItem.Name,
                            parameters.BucketedItem.TemplateID, parameters.CreationDateOfNewItem)
            {
                NewItemId = parameters.BucketedItem.ID,
                CreationDate = parameters.CreationDateOfNewItem
            };
        }

        protected virtual RuleList<T> GetRuleList<T>(Item settingsItem, string bucketRulesFieldId) where T : BucketingRuleContext
        {
            Assert.ArgumentNotNull(settingsItem, "settingsItem");
            Assert.ArgumentNotNullOrEmpty(bucketRulesFieldId, "bucketRulesFieldId");
            return RuleFactory.GetRules<T>(new[] { settingsItem }, bucketRulesFieldId);
        }

        protected virtual void SetAlwaysTrueWhenConditions<TRuleContext>(IEnumerable<Rule<TRuleContext>> rules) where TRuleContext : RuleContext
        {
            foreach(Rule<TRuleContext> rule in rules)
            {
                rule.Condition = CreateNewAlwaysTrueWhenCondition<TRuleContext>();
            }
        }

        protected virtual AlwaysTrueWhenCondition<TRuleContext> CreateNewAlwaysTrueWhenCondition<TRuleContext>() where TRuleContext : RuleContext
        {
            return new AlwaysTrueWhenCondition<TRuleContext>();
    }
    }
}

I’m not going to go too much into all the methods of this class given that most of the magic happens in the GetResolvedPath() method. It basically replaces all Conditions in the rules Sitecore.Rules.RulesList instance with an instance of the Condition class above; calls the Rules Engine API to evaluate the rules defined on the settingsItem instance though with the Conditions always returning true; and returns the resolved path to the caller.

The following class which also subclasses the BucketFolderPathAscertainer class — if I only had a dollar for every instance of the word “class” or “subclass” in this post — basically wraps an Sitecore.Buckets.Util.IDynamicBucketFolderPath instance — ahem, I mean employs the Adapter design pattern — where its GetResolvedPath() method delegates a call to the IDynamicBucketFolderPath instances GetFolderPath() method:

using Sitecore.Buckets.Util;
using Sitecore.Data.Items;
using Sitecore.Diagnostics;

namespace Sitecore.Sandbox.Buckets.Ascertainers
{
    public class DynamicBucketFolderPathPathAscertainer : BucketFolderPathAscertainer
    {
        private IDynamicBucketFolderPath PathResolver { get; set; }

        protected override string GetResolvedPath(BucketFolderPathAscertainerParameters parameters, Item settingsItem)
        {
            Assert.IsNotNull(PathResolver, "The IDynamicBucketFolderPath instance named PathResolver must be set in configuration!");
            return PathResolver.GetFolderPath(parameters.BucketItem.Database, parameters.BucketedItem.Name, parameters.BucketedItem.TemplateID,
                                                                parameters.BucketedItem.ID, parameters.BucketItem.ID, parameters.CreationDateOfNewItem);
        }
    }
}

You might be asking “what are we using the above class for?” Well, we are going to inject an instance of Sitecore.Buckets.Util.DateBasedFolderPath into the PathResolver property via the Sitecore Configuration Factory (please see the patch configuration file further down in this post).

I thought it might be cumbersome for a class to make calls to every single IBucketFolderPathAscertainer instance — sure, we only have two above but just think about how messy things will quickly progress if more are added. I decided I would utilize the Composite design pattern via the following class:

using System.Collections.Generic;
using System.Linq;
using System.Xml;

using Sitecore.Configuration;
using Sitecore.Diagnostics;

namespace Sitecore.Sandbox.Buckets.Ascertainers
{
    
    public class CompositeBucketFolderPathAscertainer : IBucketFolderPathAscertainer
    {
        private string Icon { get; set; }

        private string ToolTip { get; set; }

        private List<IBucketFolderPathAscertainer> FolderPathAscertainers { get; set; }

        public CompositeBucketFolderPathAscertainer()
        {
            FolderPathAscertainers = new List<IBucketFolderPathAscertainer>();
        }

        public string GetIcon()
        {
            return Icon;
        }

        protected virtual void SetIcon(string icon)
        {
            Assert.ArgumentNotNullOrEmpty(icon, "icon");
            Icon = icon;
        }

        public string GetToolTip()
        {
            return ToolTip;
        }

        protected virtual void SetToolTip(string toolTip)
        {
            Assert.ArgumentNotNullOrEmpty(toolTip, "toolTip");
            ToolTip = toolTip;
        }

        public bool IsFolderPathMatch(BucketFolderPathAscertainerParameters parameters)
        {
            if(FolderPathAscertainers == null || !FolderPathAscertainers.Any())
            {
                return false;
            }

            foreach(IBucketFolderPathAscertainer ascertainer in FolderPathAscertainers)
            {
                if(ascertainer.IsFolderPathMatch(parameters))
                {
                    SetIcon(ascertainer.GetIcon());
                    SetToolTip(ascertainer.GetToolTip());
                    return true;
                }
            }

            return false;
        }

        protected virtual void AddFolderPathAscertainer(XmlNode configNode)
        {
            if(configNode == null)
            {
                return;
            }

            IBucketFolderPathAscertainer ascertainer = Factory.CreateObject(configNode, false) as IBucketFolderPathAscertainer;
            Assert.IsNotNull(ascertainer, "An IBucketFolderPathAscertainer was not defined correctly in configuration!");
            FolderPathAscertainers.Add(ascertainer);
        }
    }
}

All configuration-defined IBucketFolderPathAscertainer instances will be added to the FolderPathAscertainers List property via the AddFolderPathAscertainer() method (have a look at the configuration file below to see the AddFolderPathAscertainer() method being there for the Sitecore Configuration Factory to use).

The IsFolderPathMatch() method will then iterate over all IBucketFolderPathAscertainer instances and try to find a match. If a match is found, the instance of the class above will grab and save local copies of that IBucketFolderPathAscertainer instance’s Icon and Tooltip values, and then return true. If no match was found, it returns false.

Now, we need a way to grab one bucketed Item for an Item Bucket. I defined the following interface for a class whose instance will return one Item given another Item:

using Sitecore.Data.Items;

namespace Sitecore.Sandbox.Providers.Items
{
    public interface IItemProvider
    {
        Item GetItem(Item item);
    }
}

The following class implements the interface above:

using System;
using System.Linq;
using System.Linq.Expressions;

using Sitecore.ContentSearch;
using Sitecore.ContentSearch.Linq;
using Sitecore.ContentSearch.Linq.Utilities;
using Sitecore.ContentSearch.SearchTypes;
using Sitecore.ContentSearch.Utilities;
using Sitecore.Data;
using Sitecore.Data.Items;
using Sitecore.Diagnostics;

using Sitecore.Sandbox.Providers.Items;

namespace Sitecore.Sandbox.Buckets.Providers.Items
{
    public class BucketedItemProvider : IItemProvider
    {
        private string BucketFolderTemplateId { get; set; }

        private string SearchIndexName { get; set; }

        private ISearchIndex searchIndex;
        private ISearchIndex SearchIndex
        {
            get
            {
                if (searchIndex == null && !string.IsNullOrWhiteSpace(SearchIndexName))
                {
                    searchIndex = GetSearchIndex(SearchIndexName);
                }

                return searchIndex;
            }
        }

        public virtual Item GetItem(Item bucketItem)
        {
            ID bucketFolderTemplateId;
            Assert.ArgumentCondition(ID.TryParse(BucketFolderTemplateId, out bucketFolderTemplateId), "BucketFolderTemplateId", "BucketFolderTemplateId cannot be empty and must be a Sitecore.Data.ID! Check its configuration setting!");
            Assert.ArgumentNotNull(bucketItem, "bucketItem");
            Assert.IsNotNullOrEmpty(SearchIndexName, "SearchIndexName is empty. Double-check its configuration setting!");
            Assert.IsNotNull(SearchIndex, "SearchIndex is null. Double-check the SearchIndexName configuration setting!");

            using (IProviderSearchContext searchContext = SearchIndex.CreateSearchContext())
            {
                var predicate = GetSearchPredicate<SearchResultItem>(bucketItem.ID, bucketFolderTemplateId);
                IQueryable<SearchResultItem> query = searchContext.GetQueryable<SearchResultItem>().Filter(predicate);
                SearchResults<SearchResultItem> results = query.GetResults();
                if (results.Count() < 1)
                {
                    return null;
                }

                SearchHit<SearchResultItem> hit = results.Hits.First();
                return hit.Document.GetItem();
            }
        }

        protected virtual ISearchIndex GetSearchIndex(string searchIndexName)
        {
            Assert.ArgumentNotNullOrEmpty(searchIndexName, "searchIndexName");
            return ContentSearchManager.GetIndex(searchIndexName);
        }

        protected virtual Expression<Func<T, bool>> GetSearchPredicate<T>(ID bucketItemId, ID bucketFolderTemplateId) where T : SearchResultItem
        {
            var predicate = PredicateBuilder.True<T>();
            predicate = predicate.And(item => item.Paths.Contains(bucketItemId));
            predicate = predicate.And(item => item.TemplateId != bucketFolderTemplateId);
            predicate = predicate.And(item => item.Parent != bucketItemId);
            predicate = predicate.And(item => item.ItemId != bucketItemId);
            return predicate;
        }
    }
}

The class above is leveraging the Sitecore.ContentSearch API to get this bucketed Item.

Why am I using the Sitecore.ContentSearch API? Well, imagine if there are thousands if not tens of thousands of bucketed Items under the Item Bucket. A Sitecore query would be slow as molasses, and we need keep performance on our minds at all times for all of our solutions. Don’t lose sight of that on anything you build.

The GetSearchPredicate() method builds up and returns an Expression<Func> instance — let’s call this instance the “predicate”. The predicate basically says we want an Item who is a descendant of the Item Bucket; isn’t a Bucket Folder Item; lives under a Bucket Folder; and isn’t the Item Bucket Item.

The GetItem() method then uses that predicate and the Sitecore.ContentSearch API to gather those SearchResultItem instances, and then returns the Item instance on the first one in the result set if any were returned. If none were found, it returns null.

Since we have a lot of moving parts in this solution — just look at all of the classes you’ve just gone through — I need a way to piece all of this together for a GutterRenderer.

Unfortunately, we can’t magically inject instances into a GutterRenderer via the Sitecore Configuration Factory — well, you can call it but imagine all the calls I would need for this — so I decided to define the following interface whose classes would be used by a GutterRenderer, and these classes would be defined in Sitecore configuration:

using Sitecore.Data.Items;
using Sitecore.Shell.Applications.ContentEditor.Gutters;

namespace Sitecore.Sandbox.Shell.Applications.ContentEditor.Gutters
{
    public interface IGutter
    {
        GutterIconDescriptor GetIconDescriptor(Item item);

        bool IsVisible();
    }
}

The following class implements the interface above:

using System;

using Sitecore.Buckets.Extensions;
using Sitecore.Data.Fields;
using Sitecore.Data.Items;
using Sitecore.Diagnostics;
using Sitecore.Globalization;
using Sitecore.Shell.Applications.ContentEditor.Gutters;

using Sitecore.Sandbox.Buckets.Ascertainers;
using Sitecore.Sandbox.Determiners.Features;
using Sitecore.Sandbox.Providers.Items;
using Sitecore.Sandbox.Shell.Applications.ContentEditor.Gutters;

namespace Sitecore.Sandbox.Buckets.Gutters
{
    public class FolderPathBucketGutter : IGutter
    {
        private string DefaultIcon { get; set; }

        private string DefaultToolTip { get; set; }

        private string CreatedDatetimeFieldName { get; set; }

        private IFeatureDeterminer ItemBucketsFeatureDeterminer { get; set; }
        
        private IItemProvider BucketedItemProvider { get; set; }

        private IBucketFolderPathAscertainer FolderPathAscertainer { get; set; }

        public virtual GutterIconDescriptor GetIconDescriptor(Item item)
        {
            EnsureRequiredProperties();
            Assert.ArgumentNotNull(item, "item");

            if(!AreItemBucketsEnabled() || !item.IsABucket())
            {
                return null;
            }

            Item bucketedItem = GetBucketedItem(item);
            if(bucketedItem == null)
            {
                return CreateNewGutterIconDescriptor(DefaultIcon, DefaultToolTip);
            }

            BucketFolderPathAscertainerParameters parameters = new BucketFolderPathAscertainerParameters
            {
                BucketItem = item,
                BucketedItem = bucketedItem,
                CreationDateOfNewItem = GetItemCreatedDateTime(bucketedItem)
            };

            if(!FolderPathAscertainer.IsFolderPathMatch(parameters))
            {
                return CreateNewGutterIconDescriptor(DefaultIcon, DefaultToolTip);
            }

            return CreateNewGutterIconDescriptor(FolderPathAscertainer.GetIcon(), FolderPathAscertainer.GetToolTip());
        }

        protected virtual void EnsureRequiredProperties()
        {
            Assert.IsNotNull(FolderPathAscertainer, "FolderPathAscertainer must be defined in configuration!");
            Assert.IsNotNullOrEmpty(DefaultIcon, "DefaultIcon must be defined in configuration!");
            Assert.IsNotNullOrEmpty(DefaultToolTip, "DefaultToolTip must be defined in configuration!");
            Assert.IsNotNullOrEmpty(CreatedDatetimeFieldName, "CreatedDatetimeFieldName must be defined in configuration!");
        }

        public virtual bool IsVisible()
        {
            return AreItemBucketsEnabled();
        }

        protected virtual bool AreItemBucketsEnabled()
        {
            Assert.IsNotNull(ItemBucketsFeatureDeterminer, "ItemBucketsFeatureDeterminer must be set in configuration!");
            return ItemBucketsFeatureDeterminer.IsEnabled();
        }

        protected virtual Item GetBucketedItem(Item bucketItem)
        {
            Assert.IsNotNull(BucketedItemProvider, "BucketedItemProvider must be set in configuration!");
            return BucketedItemProvider.GetItem(bucketItem);
        }

        protected virtual GutterIconDescriptor CreateNewGutterIconDescriptor(string icon, string toolTip)
        {
            Assert.ArgumentNotNullOrEmpty(icon, "icon");
            Assert.ArgumentNotNullOrEmpty(toolTip, "toolTip");
            return new GutterIconDescriptor
            {
                Icon = icon,
                Tooltip = TranslateText(toolTip)
            };
        }

        protected virtual string TranslateText(string text)
        {
            Assert.ArgumentNotNullOrEmpty(text, "text");
            return Translate.Text(text);
        }

        protected virtual DateTime GetItemCreatedDateTime(Item item)
        {
            Assert.IsNotNullOrEmpty(CreatedDatetimeFieldName, "CreatedDatetimeFieldName must be defined in configuration!");
            Assert.ArgumentNotNull(item, "item");
            DateField created = item.Fields[CreatedDatetimeFieldName];
            if(created == null)
            {
                return DateTime.MinValue;
            }

            return created.DateTime;
        }
    }
}

The AreItemBucketsEnabled() method in the above classes determines if the Item Bucket feature is enabled via the injected IBucketFolderPathAscertainer instance. This method is then used by the IsVisible() method which represents the method by the same name on GutterRenderer instances, and is also called by the GetIconDescriptor() method.

If the Item Buckets feature is not enabled, the GetIconDescriptor() method will return null as well as when the passed Item is not an Item Bucket.

If the passed Item is an Item Bucket, the GetIconDescriptor() gets one bucketed Item via the GetBucketedItem() method — this method just delegates to the IItemProvider instance injected into the class instance — and puts this bucketed Item as well as the Item Bucket into a BucketFolderPathAscertainerParameters parameters object instance. The creation date of the bucketed is also set on this parameters object since it is required when ascertaining whether the folder structure was constructed based on its creation date.

The BucketFolderPathAscertainerParameters instance is then passed to the IsFolderPathMatch() method on the injected IBucketFolderPathAscertainer property which determines if there is a folder path match.

If there is a match, a new GutterIconDescriptor instance is returned which contains the appropriate Icon and Tooltip.

If there is no match, then a new GutterIconDescriptor is returned with default values for the Icon and Tooltip.

This next class subclasses the GutterRenderer class:

using System;

using Sitecore.Configuration;
using Sitecore.Data.Items;
using Sitecore.Diagnostics;
using Sitecore.Shell.Applications.ContentEditor.Gutters;

namespace Sitecore.Sandbox.Shell.Applications.ContentEditor.Gutters
{
    public class ConfigDefinedGutterRenderer : GutterRenderer
    {
        private IGutter gutter;
        private IGutter Gutter
        {
            get
            {
                if (gutter == null)
                {
                    gutter = GetInnerGutterRenderer();
                }

                return gutter;
            }
        }

        protected override GutterIconDescriptor GetIconDescriptor(Item item)
        {
            Assert.IsNotNull(Gutter, "Gutter wasn't set properly. Double-check it!");
            return Gutter.GetIconDescriptor(item);
        }

        public override bool IsVisible()
        {
            Assert.IsNotNull(Gutter, "Gutter wasn't set properly. Double-check it!");
            return Gutter.IsVisible();
        }

        protected virtual IGutter GetInnerGutterRenderer()
        {
            string configPath = GetConfigPath();
            if (string.IsNullOrWhiteSpace(configPath))
            {
                Log.Error("ConfigDefinedGutterRenderer: configPath must be set as a parameter!", this);
                return null;
            }

            try
            {
                IGutter gutter = Factory.CreateObject(configPath, false) as IGutter;
                if (gutter == null)
                {
                    Log.Error(string.Format("ConfigDefinedGutterRenderer: the IGutter defined in {0} isn't correctly defined. Double-check it!", configPath), this);
                    return null;
                }

                return gutter;

            }
            catch (Exception ex)
            {
                Log.Error(ToString(), ex, this);
            }

            return null;
        }

        protected virtual string GetConfigPath()
        {
            string key = "configPath";
            if (Parameters.ContainsKey(key))
            {
                return Parameters[key];
            }

            return string.Empty;
        }
    }
}

The GetInnerGutterRenderer() method above calls the Sitecore Configuration Factory to grab an IGutter instance from a configuration path which is set on the Parameters field of the definition Item for this GutterRenderer in the Core database — see the screenshot further down in this post — when the Gutter property is called for the first time, and sets this instance on a private member on the class instance.

Both the GetIconDescriptor() and IsVisible() methods delegate to the methods on the IGutter instance with the same names (quiz time: what design pattern is this class using? 😉 ).

I then duct-taped everything together via the following patch configuration file:

<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/">
  <sitecore>
    <gutters>
      <folderPathBucketGutter type="Sitecore.Sandbox.Buckets.Gutters.FolderPathBucketGutter, Sitecore.Sandbox" singleInstance="true">
        <DefaultIcon>business/32x32/chest_add.png</DefaultIcon>
        <DefaultToolTip>This item is a bucket. You can use this as a content repository.</DefaultToolTip>
        <CreatedDatetimeFieldName>__Created</CreatedDatetimeFieldName>
        <ItemBucketsFeatureDeterminer ref="determiners/features/itemBucketsFeatureDeterminer" />
        <BucketedItemProvider ref="providers/items/bucketedItemProvider" />
        <FolderPathAscertainer ref="ascertainers/buckets/compositeBucketFolderPathAscertainer" />
      </folderPathBucketGutter>
    </gutters>
    <ascertainers>
      <buckets>
        <compositeBucketFolderPathAscertainer type="Sitecore.Sandbox.Buckets.Ascertainers.CompositeBucketFolderPathAscertainer, Sitecore.Sandbox" singleInstance="true">
          <ascertainers hint="raw:AddFolderPathAscertainer">
            <ascertainer ref="ascertainers/buckets/rulesDefinedBucketFolderPathAscertainer" />
            <ascertainer ref="ascertainers/buckets/dateBasedFolderPathAscertainer" />
          </ascertainers>
        </compositeBucketFolderPathAscertainer>
        <dateBasedFolderPathAscertainer type="Sitecore.Sandbox.Buckets.Ascertainers.DynamicBucketFolderPathPathAscertainer, Sitecore.Sandbox" singleInstance="true">
          <Icon>Business/32x32/calendar_down.png</Icon>
          <ToolTip>This item is a bucket. Its bucket folders were generated based on the creation date of the bucketed items. You can use this as a content repository.</ToolTip>
          <PathResolver type="Sitecore.Buckets.Util.DateBasedFolderPath, Sitecore.Buckets" />
        </dateBasedFolderPathAscertainer>
        <rulesDefinedBucketFolderPathAscertainer type="Sitecore.Sandbox.Buckets.Ascertainers.RulesDefinedBucketFolderPathAscertainer, Sitecore.Sandbox"
        singleInstance="true">
          <Icon>Business/32x32/briefcase_add.png</Icon>
          <ToolTip>This item is a bucket. Its bucket folders were generated by the rules engine. You can use this as a content repository.</ToolTip>
        </rulesDefinedBucketFolderPathAscertainer>
      </buckets>
    </ascertainers>
    <determiners>
      <features>
        <itemBucketsFeatureDeterminer type="Sitecore.Sandbox.Buckets.Determiners.Features.ItemBucketsFeatureDeterminer" singleInstance="true" />
      </features>
    </determiners>
    <providers>
      <items>
        <bucketedItemProvider type="Sitecore.Sandbox.Buckets.Providers.Items.BucketedItemProvider" singleInstance="true">
          <BucketFolderTemplateId>{ADB6CA4F-03EF-4F47-B9AC-9CE2BA53FF97}</BucketFolderTemplateId>
          <SearchIndexName>sitecore_master_index</SearchIndexName>
        </bucketedItemProvider>
      </items>
    </providers>
  </sitecore>
</configuration>

We need to let Sitecore know about the new Gutter addition. I did this in the Core database:

smart-bucket-gutter-core-db

One thing to keep in mind is that the Sitecore Rules Engine folder path match will only work when we have an algorithm that will return the same path consistently for a bucketed Item. This unfortunately means I could not use the same Action from my previous post given that it generates random folder paths.

To over come this hurdle, I built the following Action which just reverses the bucketed Item’s ID (oh no, more code 😉 ):

using System.Collections.Generic;
using System.Linq;

using Sitecore.Buckets.Rules.Bucketing;
using Sitecore.Buckets.Rules.Bucketing.Actions;
using Sitecore.Diagnostics;

namespace Sitecore.Sandbox.Buckets.Rules.Actions
{
    public class CreateReversedIDBasedPath<TContext> : CreateIDBasedPath<TContext> where TContext : BucketingRuleContext
    {
        public override void Apply(TContext ruleContext)
        {
            Assert.ArgumentNotNull(ruleContext, "ruleContext");
            base.Apply(ruleContext);
            if (string.IsNullOrWhiteSpace(ruleContext.ResolvedPath))
            {
                return;
            }

            ruleContext.ResolvedPath = ReversePath(ruleContext.ResolvedPath);
        }

        protected virtual string ReversePath(string path)
        {
            if(string.IsNullOrWhiteSpace(path))
            {
                return string.Empty;
            }

            List<string> pieces = path.Split('/').ToList();
            pieces.Reverse();
            return string.Join("/", pieces);
        }
    }
}

I’m not going to go into details of how I set this in the rules on /sitecore/system/Settings/Buckets/Item Buckets Settings — you can see an example of how this is done from my previous post.

Now that everything is set, we can see that the new Gutter option is available:

smart-bucket-gutter-right-click-lets-turn-on

I then turned it on:

smart-gutter-new-gutter-turned-on

As you can see, we have different Gutter icons for different folder structures.

If you have any thoughts on this, please share in a comment.

Oh, by the way, if you made it all the way to the end of this post, then you deserve a treat. Go get yourself a cookie. You deserve it. 😉

cookie

Until next time, keep up the good fight, one piece of code at time. 😀

Customize How Item Bucket Folder Paths are Created Using the Sitecore Rules Engine

I bet you all love Sitecore Item Buckets, right? Everyone loves Item Buckets, even this cat:

Cat-Traps-Itself-Inside-Bucket

If you don’t know what Item Buckets are — and if you don’t I recommend having a read of this pdf — they are Items that contain a nested structure of Bucket Folder Items, and the leaf Bucket Folder Items contain bucketable Items.

What’s the purpose of this? Well, Item Buckets offer a way to store a massive amount of Items under the nested structure of Bucket Folders Items. This offers better performance over having a large amount of Items under one parent Item:

item-bucket

By default, the Bucket Folder Items are named based on a DateTime format which is housed in a configuration setting in Sitecore:

bucket-folder-date-time-format

One thing I’ve always been curious about was what code used the above setting to create path for these Bucket Folders — I wanted to see if I could override it, and add my own logic to name the Bucket Folder Items using some different algorithm.

I found that this code lives in Sitecore.Buckets.Util.BucketFolderPathResolver in Sitecore.Buckets.dll.

However, that wasn’t the only thing I saw in this class — I also saw code in there leveraging the Sitecore Rules Engine as well. Basically the Rules Engine code would execute first, and if it returned no path structure — as a string — the default DateTime format code would execute.

After talking with Sitecore MVP Robbert Hock about it on the Sitecore Community Slack, he shared the following post by Alex van Wolferen which highlights that you can create custom conditions and actions for the Rules Engine to generate a custom folder path for the Bucket Folders, and even showed how you can set this stuff up in the Content Editor. Really? How did I not know about this? I must have been asleep when the Item Buckets feature was released. 😉

The only unfortunate thing about that blog post is there is no code to look at. 😦

As an alternative method of discovery, I surfed through Sitecore.Buckets.dll to see how the existing Bucket conditions and actions were built, and then decided have a bit of fun: I created two custom conditions and one custom action.

The following class serves as my first custom condition which determines if the Item Bucket has any presentation:

using Sitecore.Buckets.Rules.Bucketing;
using Sitecore.Data.Items;
using Sitecore.Diagnostics;
using Sitecore.Pipelines.HasPresentation;
using Sitecore.Rules.Conditions;

namespace Sitecore.Sandbox.Buckets.Rules.Conditions
{
    public class WhenBucketHasNoPresentation<TRuleContext> : WhenCondition<TRuleContext> where TRuleContext : BucketingRuleContext
    {
        protected override bool Execute(TRuleContext ruleContext)
        {
            Assert.ArgumentNotNull(ruleContext, "ruleContext");
            Assert.ArgumentNotNull(ruleContext.BucketItem, "ruleContext.BucketItem");
            return !HasPresentation(ruleContext.BucketItem);
        }

        protected virtual bool HasPresentation(Item item)
        {
            Assert.ArgumentNotNull(item, "item");
            return HasPresentationPipeline.Run(item);
        }
    }
}

The Execute() method in the above class gets an instance of the Item Bucket from the BucketingRuleContext instance, and passes it off to the HasPresentation() method which determines whether the Item Bucket has any presentation components defined on it.

In order for Sitecore to know about the class above, we need to create a new Condition Item. I did just that here:

bucket-folder-path-condition-no-presentation

The following class serves as another condition though this condition determines if the Item Bucket has N or more child Items underneath it (N is an integer set on the rule which I show further down in this post):

using Sitecore.Buckets.Rules.Bucketing;
using Sitecore.Data.Items;
using Sitecore.Diagnostics;
using Sitecore.Rules.Conditions;

namespace Sitecore.Sandbox.Buckets.Rules.Conditions
{
    public class WhenBucketHasNChildrenOrMore<TRuleContext> : WhenCondition<TRuleContext> where TRuleContext : BucketingRuleContext
    {
        public string Value { get; set; }

        protected override bool Execute(TRuleContext ruleContext)
        {
            Assert.ArgumentNotNull(ruleContext, "ruleContext");
            Assert.ArgumentNotNull(ruleContext.BucketItem, "ruleContext.BucketItem");
            return ShouldExecute(ruleContext.BucketItem);
        }

        protected virtual bool ShouldExecute(Item item)
        {
            Assert.ArgumentNotNull(item, "item");
            int excessiveNumber = GetExcessiveNumberOfChildren();
            return excessiveNumber > 0 && item.Children.Count >= excessiveNumber;
        }

        protected virtual int GetExcessiveNumberOfChildren()
        {
            int excessiveNumber;
            if(!int.TryParse(Value, out excessiveNumber))
            {
                return 0;
            }

            return excessiveNumber;
        }
    }
}

The GetExcessiveNumberOfChildren() method tries to parse an integer from the value set on the Value property on the class instance. If the value is not set, it just returns zero.

The above method is called by the ShouldExecute() method which ascertains whether the value is greater zero, and if it is, whether the Item Bucket has that amount of child Items or more. If both of these are true, the method returns true; false otherwise.

The boolean value of the ShouldExecute() method is then returned to the caller via the Execute() method.

Just like the last condition class, we have to let Sitecore know about it. I did that by creating another Condition Item:

bucket-folder-path-condition-number-of-children

Now we need a class that builds up the Bucket Folder path. The following class serves as an action to do just that:

using System;
using System.Collections.Generic;

using Sitecore.Buckets.Rules.Bucketing;
using Sitecore.Diagnostics;
using Sitecore.Rules.Actions;

namespace Sitecore.Sandbox.Buckets.Rules.Actions
{
    public class CreateRandomIntegerBasedPath<TContext> : RuleAction<TContext> where TContext : BucketingRuleContext
    {
        private const int LengthOfInteger = 3;

        protected static readonly Random Random = new Random();

        public string Levels { get; set; }

        public override void Apply(TContext ruleContext)
        {
            Assert.ArgumentNotNull(ruleContext, "ruleContext");
            int levels = GetLevels();
            if(levels < 1)
            {
                Log.Error(string.Format("Cannot apply CreateRandomIntegerBasedPath action. The value of levels: {0}", Levels), this);
                return;
            }

            IEnumerable<string> integers = GetRandomIntegers(LengthOfInteger, levels);
            ruleContext.ResolvedPath = string.Join(Sitecore.Buckets.Util.Constants.ContentPathSeperator, integers);
        }

        protected virtual int GetLevels()
        {
            int levels;
            if(!int.TryParse(Levels, out levels) || levels < 1)
            {
                return 0;
            }

            return levels;
        }
        
        protected virtual IEnumerable<string> GetRandomIntegers(int lengthOfInteger, int count)
        {
            IList<string> strings = new List<string>();
            for (int i = 0; i < count; i++)
            {
                int number = GetRandomPowerOfTenNumber(lengthOfInteger);
                strings.Add(number.ToString());
            }

            return strings;
        }

        private int GetRandomPowerOfTenNumber(int exponent)
        {
            return Random.Next((int)Math.Pow(10, exponent - 1), (int)Math.Pow(10, exponent) - 1);
        }
    }
}

The class above, in a nutshell, reads in the value that governs how deep the folder structure should be (i.e. this is stored in the Levels string property which is set on the rule further down in this post); tries to parse this as an integer (we can’t do much if it’s not an integer); creates N strings composed of random numbers between 100 and 999 with endpoints inclusive (N is the integer value of Levels); builds up a string delimited by “/” to create a folder path; and returns it to the caller of the Apply() method.

Just like the condition classes, we need to register the above action class in Sitecore. I did this by creating a custom Action Item:

bucket-folder-path-action-create-random-folder-path

Now that we have our custom conditions and action ready to go, we need to piece them together into a rule. I did that in the ‘Rules for Resolving the Bucket Folder Path’ field on /sitecore/system/Settings/Buckets/Item Buckets Settings:

bucket-folder-path-item-buckets-settings

Let’s take this for a spin!

I created some test Items with some child items. The following Item has no presentation and 5 child items:

bucket-folder-path-5-items-no-presentation

Let’s turn it into an Item Bucket:

bucket-folder-path-5-items-no-presentation-click-bucket

As you can see, it has Bucket Folders with random integers as their Item names:

bucket-folder-path-5-items-no-presentation-bucket

Let’s now try this on an Item that has no presentation but only 4 child items:

bucket-folder-path-4-items-no-presentation

Let’s convert this Item into an Item Bucket:

bucket-folder-path-4-items-no-presentation-click-bucket

As you can see, the default Item Bucket folder structure was created:

bucket-folder-path-4-items-no-presentation-bucket

If you have any thoughts on this, please share in a comment.

Abstract Out Sitecore FileWatcher Logic Which Monitors Rendering Files on the File System

While digging through code of Sitecore.IO.FileWatcher subclasses this weekend, I noticed a lot of code similarities between the LayoutWatcher and XslWatcher classes, and thought it might be a good idea to abstract this logic out into a new base abstract class so that future FileWatchers which monitor other renderings on the file system can easily be added without having to write much logic.

Before I move forward on how I did this, let me explain what the LayoutWatcher FileWatcher does. The LayoutWatcher FileWatcher clears the html cache of all websites defined in Sitecore when it determines that a layout file (a.k.a .aspx) or sublayout file (a.k.a .ascx) has been changed, deleted, renamed or added.

Likewise, the XslWatcher FileWatcher does the same thing for XSLT renderings but also clears the XSL cache along with the html cache.

Ok, now back to the abstraction. I came up with the following class to serve as the base class for any FileWatcher that will monitor renderings that live on the file system:

using System;
using System.Collections.Generic;
using System.Linq;

using Sitecore.Configuration;
using Sitecore.Diagnostics;
using Sitecore.IO;
using Sitecore.Web;

namespace Sitecore.Sandbox.IO.Watchers
{
    public abstract class RenderingFileWatcher : FileWatcher
    {
        private string RenderingFileModifiedMessage { get; set; }

        private string RenderingFileDeletedMessage { get; set; }

        private string RenderingFileRenamedMessage { get; set; }

        private string FileWatcherErrorMessage { get; set; }

        private object Owner { get; set; }

        public RenderingFileWatcher(string configPath)
            : base(configPath)
        {
            SetMessages();
        }

        private void SetMessages()
        {
            string modifiedMessage = GetRenderingFileModifiedMessage();
            AssertNotNullOrWhiteSpace(modifiedMessage, "modifiedMessage", "GetRenderingFileModifiedMessage() cannot return null, empty or whitespace!");
            RenderingFileModifiedMessage = modifiedMessage;

            string deletedMessage = GetRenderingFileDeletedMessage();
            AssertNotNullOrWhiteSpace(deletedMessage, "deletedMessage", "GetRenderingFileDeletedMessage() cannot return null, empty or whitespace!");
            RenderingFileDeletedMessage = deletedMessage;

            string renamedMessage = GetRenderingFileRenamedMessage();
            AssertNotNullOrWhiteSpace(renamedMessage, "renamedMessage", "GetRenderingFileRenamedMessage() cannot return null, empty or whitespace!");
            RenderingFileRenamedMessage = renamedMessage;

            string errorMessage = GetFileWatcherErrorMessage();
            AssertNotNullOrWhiteSpace(errorMessage, "errorMessage", "GetFileWatcherErrorMessage() cannot return null, empty or whitespace!");
            FileWatcherErrorMessage = errorMessage;

            object owner = GetOwner();
            Assert.IsNotNull(owner, "GetOwner() cannot return null!");
            Owner = owner;
        }

        protected abstract string GetRenderingFileModifiedMessage();

        protected abstract string GetRenderingFileDeletedMessage();

        protected abstract string GetRenderingFileRenamedMessage();

        protected abstract string GetFileWatcherErrorMessage();

        protected abstract object GetOwner();

        private void AssertNotNullOrWhiteSpace(string argument, string argumentName, string errorMessage)
        {
            Assert.ArgumentCondition(!string.IsNullOrWhiteSpace(argument), argumentName, errorMessage);
        }

        protected override void Created(string fullPath)
        {
            try
            {
                Log.Info(string.Format("{0}: {1}", RenderingFileModifiedMessage, fullPath), Owner);
                ClearCaches();
            }
            catch (Exception ex)
            {
                Log.Error(FileWatcherErrorMessage, ex, Owner);
            }
        }

        protected override void Deleted(string filePath)
        {
            try
            {
                Log.Info(string.Format("{0}: {1}", RenderingFileDeletedMessage, filePath), Owner);
                ClearCaches();
            }
            catch (Exception ex)
            {
                Log.Error(FileWatcherErrorMessage, ex, Owner);
            }
        }

        protected override void Renamed(string filePath, string oldFilePath)
        {
            try
            {
                Log.Info(string.Format("{0}: {1}. Old path: {2}", RenderingFileRenamedMessage, filePath, oldFilePath), Owner);
                ClearCaches();
            }
            catch (Exception ex)
            {
                Log.Error(FileWatcherErrorMessage, ex, this);
            }
        }

        protected virtual void ClearCaches()
        {
            ClearHtmlCaches();
        }

        protected virtual void ClearHtmlCaches()
        {
            IEnumerable<SiteInfo> siteInfos = GetSiteInfos();
            if (IsNullOrEmpty(siteInfos))
            {
                return;
            }

            foreach(SiteInfo siteInfo in siteInfos)
            {
                if (siteInfo.HtmlCache != null)
                {
                    Log.Info(string.Format("Clearing Html Cache for site: {0}", siteInfo.Name), Owner);
                    siteInfo.HtmlCache.Clear();
                }
            }
        }

        protected virtual IEnumerable<SiteInfo> GetSiteInfos()
        {
            IEnumerable<string> siteNames = GetSiteNames();
            if (IsNullOrEmpty(siteNames))
            {
                return Enumerable.Empty<SiteInfo>();
            }

            IList<SiteInfo> siteInfos = new List<SiteInfo>();
            foreach(string siteName in siteNames)
            {
                SiteInfo siteInfo = Factory.GetSiteInfo(siteName);
                if(siteInfo != null)
                {
                    siteInfos.Add(siteInfo);
                }
            }

            return siteInfos;
        }

        protected virtual IEnumerable<string> GetSiteNames()
        {
            IEnumerable<string> siteNames = Factory.GetSiteNames();
            if(IsNullOrEmpty(siteNames))
            {
                return Enumerable.Empty<string>();
            }

            return siteNames;
        }

        protected virtual bool IsNullOrEmpty<T>(IEnumerable<T> collection)
        {
            if (collection == null || !collection.Any())
            {
                return true;
            }

            return false;
        }
    }
}

The above class defines five abstract methods which subclasses must implement. Data returned by these methods are used when logging information or errors in the Sitecore log. The SetMessages() method vets whether subclass returned these objects correctly, and sets them in private properties which are used in the Created(), Deleted() and Renamed() methods.

The Created(), Deleted() and Renamed() methods aren’t really doing anything different from each other — they are all clearing the html cache for each Sitecore.Web.SiteInfo instance returned by the GetSiteInfos() method, though I do want to point out that each of these methods are defined on the Sitecore.IO.FileWatcher base class and serve as event handlers for file system file actions:

  • Created() is invoked when a new file is dropped in a directory or subdirectory being monitored, or when a targeted file is changed.
  • Deleted() is invoked when a targeted file is deleted.
  • Renamed() is invoked when a targeted file is renamed.

In order to ascertain whether the code above works, I need a subclass whose instance will serve as the actual FileWatcher. I decided to build the following subclass which will monitor Razor files under the /Views directory of my Sitecore website root:

namespace Sitecore.Sandbox.IO.Watchers
{
    public class RazorViewFileWatcher : RenderingFileWatcher
    {
        public RazorViewFileWatcher()
            : base("watchers/view")
        {
        }
        
        protected override string GetRenderingFileModifiedMessage()
        {
            return "Razor View modified";
        }

        protected override string GetRenderingFileDeletedMessage()
        {
            return "Razor View deleted";
        }

        protected override string GetRenderingFileRenamedMessage()
        {
            return "Razor View renamed";
        }

        protected override string GetFileWatcherErrorMessage()
        {
            return "Error in RazorViewFileWatcher";
        }

        protected override object GetOwner()
        {
            return this;
        }
    }
}

I’m sure Sitecore has another way of clearing/replenishing the html cache for Sitecore MVC View and Controller renderings — if you know how this works in Sitecore, please share in a comment, or better yet: please share in a blog post — but I went with this just for testing.

There’s not much going on in the above class. It’s just defining the needed methods for its base class to work its magic.

I then had to add the configuration needed by the RazorViewFileWatcher above in the following patch include configuration file:

<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/">
  <sitecore>
    <settings>
      <setting name="ViewsFolder" value="/Views" />
    </settings>
    <watchers>
      <view>
        <folder ref="settings/setting[@name='ViewsFolder']/@value"/>
        <filter>*.cshtml</filter>
      </view>
    </watchers>
  </sitecore>
</configuration>

As I’ve discussed in this post, FileWatchers in Sitecore are Http Modules — these must be registered under <modules> of <system.webServer> of your Web.config:


<!-- lots of stuff up here -->

<system.webServer>
    <modules runAllManagedModulesForAllRequests="true">

		<!-- stuff here -->
      
		<add type="Sitecore.Sandbox.IO.Watchers.RazorViewFileWatcher, Sitecore.Sandbox" name="SitecoreRazorViewFileWatcher" />

		<!-- stuff here as well -->

	</modules>

	<!-- more stuff down here -->

</system.webServer>

<!-- even more stuff down here -->

Let’s see if this works.

I decided to choose the following Razor file which comes with Web Forms For Marketers 8.1 Update-2:

razor-view-file-watcher-cshtml-1

I first performed a copy and paste of the Razor file into a new file:

razor-view-file-watcher-cshtml-2

I then deleted the new Razor file:

razor-view-file-watcher-cshtml-3

Next, I renamed the Razor file:

razor-view-file-watcher-cshtml-4

When I looked in my Sitecore log file, I saw that all operations were executed:

razor-view-file-watcher-log

If you have any thoughts on this, please drop a comment.

Upload Files via the Sitecore UploadWatcher to a Configuration Specified Media Library Folder

In my previous to last post, I discussed the Sitecore UploadWatcher — a Sitecore.IO.FileWatcher which uploads files to the Media Library when files are dropped into the /upload directory of your Sitecore website root.

Unfortunately, in the “out of the box” solution, files are uploaded directly under the Media Library root (/sitecore/media library). Imagine having to sift through all kinds of Media Library Items and folders just to find the image that you are looking for. Such would be an arduous task at best.

I decided to dig through Sitecore.Kernel.dll to see why this is the case, and discovered why: the FileCreated() method on the Sitecore.Resources.Media.MediaCreator class uses an empty Sitecore.Resources.Media.MediaCreatorOptions instance. In order for the file to be uploaded to a specified location in the Media Library, the Destination property on the Sitecore.Resources.Media.MediaCreatorOptions instance must be set, or it will be uploaded directly to the Media Library root.

Here’s the good news: the FileCreated() method is declared virtual, so why not subclass it and then override this method to include some custom logic to set the Destination property on the MediaCreatorOptions instance?

I did just that in the following class:

using System.IO;

using Sitecore.Configuration;
using Sitecore.Data.Items;
using Sitecore.Diagnostics;
using Sitecore.IO;
using Sitecore.Pipelines.GetMediaCreatorOptions;
using Sitecore.Resources.Media;

namespace Sitecore.Sandbox.Resources.Media
{
    public class MediaCreator : Sitecore.Resources.Media.MediaCreator
    {
        private string UploadLocation { get; set; }

        public override void FileCreated(string filePath)
        {
            Assert.ArgumentNotNullOrEmpty(filePath, "filePath");
            if (string.IsNullOrWhiteSpace(UploadLocation))
            {
                base.FileCreated(filePath);
                return;
            }

            SetContext();
            lock (FileUtil.GetFileLock(filePath))
            {
                string destination = GetMediaItemDestination(filePath);
                if (FileUtil.IsFolder(filePath))
                {
                    MediaCreatorOptions options = MediaCreatorOptions.Empty;
                    options.Destination = destination;
                    options.Build(GetMediaCreatorOptionsArgs.FileBasedContext);
                    this.CreateFromFolder(filePath, options);
                }
                else
                {
                    MediaCreatorOptions options = MediaCreatorOptions.Empty;
                    options.Destination = destination;
                    long length = new FileInfo(filePath).Length;
                    options.FileBased = (length > Settings.Media.MaxSizeInDatabase) || Settings.Media.UploadAsFiles;
                    options.Build(GetMediaCreatorOptionsArgs.FileBasedContext);
                    this.CreateFromFile(filePath, options);
                }
            }
        }

        protected virtual void SetContext()
        {
            if (Context.Site == null)
            {
                Context.SetActiveSite("shell");
            }
        }

        protected virtual string GetMediaItemDestination(string filePath)
        {
            if(string.IsNullOrWhiteSpace(UploadLocation))
            {
                return null;
            }

            string fileNameNoExtension = Path.GetFileNameWithoutExtension(filePath);
            string itemName = ItemUtil.ProposeValidItemName(fileNameNoExtension);
            return string.Format("{0}/{1}", UploadLocation, itemName);
        }
    }
}

The UploadLocation property in the class above is to be defined in Sitecore Configuration — see the patch include configuration file below — and then populated via the Sitecore Configuration Factory when the class is instantiated (yes, I’m defining this class in Sitecore Configuration as well).

Most of the logic in the FileCreated() method above comes from its base class Sitecore.Resources.Media.MediaCreator. I had to copy and paste most of this code from its base class’ FileCreated() method as I couldn’t just delegate to the base class’ FileCreated() method — I needed to set the Destination property on the MediaCreatorOptions instance.

The Destination property on the MediaCreatorOptions instance is being set to be the UploadLocation plus the Media Library Item name — I determine this full path in the GetMediaItemDestination() method.

Unfortunately, I also had to bring in the SetContext() method from the base class since it’s declared private — this method is needed in the FileCreated() method to ensure we have a context site defined.

Now, we need a way to set an instance of the above in the Creator property on the Sitecore.Sandbox.Resources.Media.MediaProvider instance. Unfortunately, there was no easy way to do this without having to subclass the Sitecore.Sandbox.Resources.Media.MediaProvider class, and then set the Creator property via its constructor:

using Sitecore.Configuration;

namespace Sitecore.Sandbox.Resources.Media
{
    public class MediaProvider : Sitecore.Resources.Media.MediaProvider
    {
        private MediaCreator MediaCreator { get; set; }

        public MediaProvider()
        {
            OverrideMediaCreator();
        }

        protected virtual void OverrideMediaCreator()
        {
            Sitecore.Resources.Media.MediaCreator mediaCreator = GetMediaCreator();
            if (mediaCreator == null)
            {
                return;
            }

            Creator = mediaCreator;
        }

        protected virtual Sitecore.Resources.Media.MediaCreator GetMediaCreator()
        {
            return Factory.CreateObject("mediaLibrary/mediaCreator", false) as MediaCreator;
        }
    }
}

The OverrideMediaCreator() method above tries to get an instance of a Sitecore.Resources.Media.MediaCreator using the Sitecore Configuration Factory — it delegates to the GetMediaCreator() method to get this instance — and then set it on the Creator property of its base class if the MediaCreator obtained from the GetMediaCreator() method isn’t null.

If it is null, it just exits out — there is a default instance created in the Sitecore.Resources.Media.MediaCreator base class, so that one would be used instead.

I then replaced the “out of the box” Sitecore.Resources.Media.MediaProvider with the new one above, and also defined the MediaCreator above in the following patch include configuration file:

<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/">
  <sitecore>
    <mediaLibrary>
      <mediaProvider patch:instead="mediaProvider[@type='Sitecore.Resources.Media.MediaProvider, Sitecore.Kernel']"
                     type="Sitecore.Sandbox.Resources.Media.MediaProvider, Sitecore.Sandbox" />
      <mediaCreator type="Sitecore.Sandbox.Resources.Media.MediaCreator, Sitecore.Sandbox">
        <UploadLocation>/sitecore/media library/uploaded</UploadLocation>
      </mediaCreator>
  </mediaLibrary>
  </sitecore>
</configuration>

Let’s see how we did.

As you can see, I have an empty uploaded Media Library folder:

upload-watcher-not-uploaded-to-folder

Let’s move an image into the /upload folder of my Sitecore instance:

upload-watcher-upload-to-folder

After reloading the “uploaded” Media Library folder, I see that the image was uploaded to it:

upload-watcher-uploaded-to-folder

I would also to like to mention that this solution will also work if there is no uploaded folder in the Media Library — it will be created during upload process.

If you have any thoughts on this, please share in a comment.

Augment the Sitecore UploadWatcher to Delete Files from the Upload Directory After Uploading to the Media Library

In my previous post I discussed the Sitecore UploadWatcher — a Sitecore.IO.FileWatcher which monitors the /upload directory of your Sitecore instance and uploads files dropped into that directory into the Media Library.

One thing I could never find in the UploadWatcher is functionality to delete files in the /upload directory after they are uploaded into the Media Library — if you know of an “out of the box” way of doing this, please drop a comment.

After peeking into Sitecore.Resources.Media.UploadWatcher using .NET Reflector, I discovered I could add this functionality quite easily since its Created() method — this method handles the uploading of the files into the Media Library by delegating to Sitecore.Resources.Media.MediaManager.Creator.FileCreated() — is overridable. In theory, all I would need to do would be to subclass the UploadWatcher class; override the Created() method; delegate to the base class’ Created() method to handle the upload of the file to the Media Library; then delete the file once the base class’ Create() method was done executing.

After coding, experimenting and refactoring, I built the following class that subclasses Sitecore.Resources.Media.UploadWatcher:

using System;
using System.Collections.Generic;
using System.IO;
using System.Linq;
using System.Xml;

using Sitecore.Configuration;
using Sitecore.Diagnostics;
using Sitecore.IO;
using Sitecore.Resources.Media;
using Sitecore.Xml;

namespace Sitecore.Sandbox.Resources.Media
{
    public class CleanupUploadWatcher : UploadWatcher
    {
        private IEnumerable<string> PathsToIgnore { get; set; }

        private IEnumerable<string> FileNamePartsToIgnore { get; set; }

        private bool ShouldDeleteAfterUpload { get; set; }

        public CleanupUploadWatcher()
            : base()
        {
            Initialize();
        }

        private void Initialize()
        {
            IEnumerable<XmlNode> configNodes = GetIgnoreConfigNodes();
            PathsToIgnore = GetPathsToIgnore(configNodes);
            FileNamePartsToIgnore = GetFileNamePartsToIgnore(configNodes);
            ShouldDeleteAfterUpload = GetShouldDeleteAfterUpload();
        }

        protected virtual IEnumerable<XmlNode> GetIgnoreConfigNodes()
        {
            string configNodeRoot = GetConfigNodeRoot();
            if (string.IsNullOrWhiteSpace(configNodeRoot))
            {
                return Enumerable.Empty<XmlNode>();
            }

            XmlNode rootNode = Factory.GetConfigNode(configNodeRoot);
            if (rootNode == null)
            {
                return Enumerable.Empty<XmlNode>();
            }

            return XmlUtil.GetChildNodes(rootNode, true);
        }

        protected virtual string GetConfigNodeRoot()
        {
            return "mediaLibrary/watcher/ignoreList";
        }

        protected virtual IEnumerable<string> GetPathsToIgnore(IEnumerable<XmlNode> nodes)
        {
            if (IsEmpty(nodes))
            {
                return Enumerable.Empty<string>();
            }

            HashSet<string> pathsToIgnore = new HashSet<string>();
            foreach (XmlNode node in nodes)
            {
                string containsValue = XmlUtil.GetAttribute("contains", node);
                if (ShouldAddContainsValue(containsValue, node, "ignorepath"))
                {
                    pathsToIgnore.Add(containsValue);
                }
            }

            return pathsToIgnore;
        }

        protected virtual IEnumerable<string> GetFileNamePartsToIgnore(IEnumerable<XmlNode> nodes)
        {
            if (IsEmpty(nodes))
            {
                return Enumerable.Empty<string>();
            }

            HashSet<string> partsToIgnore = new HashSet<string>();
            foreach (XmlNode node in nodes)
            {
                string containsValue = XmlUtil.GetAttribute("contains", node);
                if (ShouldAddContainsValue(containsValue, node, "ignore"))
                {
                    partsToIgnore.Add(containsValue);
                }
            }

            return partsToIgnore;
        }

        protected virtual bool ShouldAddContainsValue(string containsValue, XmlNode node, string targetNodeName)
        {
            return !string.IsNullOrWhiteSpace(containsValue)
                    && node != null
                    && string.Equals(node.Name, targetNodeName, StringComparison.OrdinalIgnoreCase);
        }

        protected static bool IsEmpty<T>(IEnumerable<T> collection)
        {
            return collection == null || !collection.Any();
        }

        protected override void Created(string filePath)
        {
            Assert.ArgumentNotNullOrEmpty(filePath, "filePath");
            if (!ShouldIgnoreFile(filePath))
            {
                base.Created(filePath);
                DeleteFile(filePath);
            }
        }

        protected virtual bool GetShouldDeleteAfterUpload()
        {
            XmlNode node = Factory.GetConfigNode("watchers/media/additionalSettings");
            if (node == null)
            {
                return false;
            }

            string deleteAfterUploadValue = XmlUtil.GetAttribute("deleteAfterUpload", node);
            if(string.IsNullOrWhiteSpace(deleteAfterUploadValue))
            {
                return false;
            }
            
            bool shouldDelete;
            bool.TryParse(deleteAfterUploadValue, out shouldDelete);
            return shouldDelete;
        }

        protected virtual bool ShouldIgnoreFile(string filePath)
        {
            Assert.ArgumentNotNullOrEmpty(filePath, "filePath");
            foreach (string path in PathsToIgnore)
            {
                if (ContainsSubstring(filePath, path))
                {
                    return true;
                }
            }

            string fileName = Path.GetFileName(filePath);
            foreach (string part in FileNamePartsToIgnore)
            {
                if(ContainsSubstring(fileName, part))
                {
                    return true;
                }
            }

            return false;
        }

        protected virtual bool ContainsSubstring(string value, string substring)
        {
            if(string.IsNullOrWhiteSpace(value) || string.IsNullOrWhiteSpace(substring))
            {
                return false;
            }

            return value.IndexOf(substring, StringComparison.OrdinalIgnoreCase) > -1;
        }

        protected virtual void DeleteFile(string filePath)
        {
            Assert.ArgumentNotNullOrEmpty(filePath, "filePath");
            if(!ShouldDeleteAfterUpload)
            {
                return;
            }

            try
            {
                FileUtil.Delete(filePath);
            }
            catch(Exception ex)
            {
                Log.Error(ToString(), ex, this);
            }
        }
    }
}

You might thinking “Mike, there is more going on in here than just delegating to the base class’ Created() method and deleting the file. Well, you are correct — I had to do a few things further than what I thought I needed to do, and I’ll explain why.

I had to duplicate the logic — actually I wrote my own logic — to parse the Sitecore configuration which defines the substrings of file names and paths to ignore since these collections on the base UploadWatcher class are private — subclasses cannot access these collections — in order to prevent the code from deleting a file that should be ignored.

I also wedged in configuration with code to turn off the delete functionality if needed.

I then created the following patch include configuration file to hold the configuration setting to turn the delete functionality on/off:

<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/">
  <sitecore>
    <watchers>
      <media>
        <additionalSettings deleteAfterUpload="true" />
      </media>
    </watchers>
  </sitecore>
</configuration>

I then registered the new CleanupUploadWatcher in the Web.config — please see my previous post which explains why this is needed:

<system.webServer>
    <modules runAllManagedModulesForAllRequests="true">

      <!-- stuff here -->

      <!-- <add type="Sitecore.Resources.Media.UploadWatcher, Sitecore.Kernel" name="SitecoreUploadWatcher" /> -->
      <add type="Sitecore.Sandbox.Resources.Media.CleanupUploadWatcher, Sitecore.Sandbox" name="SitecoreUploadWatcher" />

      <!-- more stuff down here -->

    </modules>

    <!-- and more stuff down here -->
    
<system.webServer>

Let’s see this in action!

As you can see, there is no Media Library Item in the root of my Media Library (/sitecore/media library) — this is where the UploadWatcher uploads the file to:

cleanup-uploadwatcher-media-library-no-file

I then copied an image from a folder on my Desktop to the /upload directory of my Sitecore instance:

cleanup-uploadwatcher-move-file

As you can see above, the image is deleted after it is dropped.

I then went back to my Media Library and refreshed. As you can see here, the file was uploaded:

cleanup-uploadwatcher-media-library-file

If you have any thoughts on this or suggestions on making it better, please share in a comment.

Automagic File Uploads to the Media Library via the “Out of the Box” UploadWatcher in Sitecore

In a previous post I gave a proof of concept on a custom Content Editor Image field which gives content authors the ability to download an image from a URL and save to the downloaded image to the Media Library.

During my testing of this solution, I noticed some odd behavior where I was seeing my image being uploaded twice to the Media Library — one Media Library Item being placed in a folder selected by the user and then another being placed right under the Media Library root Item (/sitecore/media library).

At first I thought I had a bug in my code though could not track it down. I even made many attempts at refactoring the code I had, thinking I was missing something during the debugging process. Still, to no avail, the “bug” was popping its head up during my testing.

However, after a few more passes at refactoring, the “bug” magically disappeared. I figured “hey, I somehow fixed it but have no idea how. Let’s move forward on writing a blog post.”

Unfortunately, the “bug” popped up again when writing my last post. I was quite taken aback given I was repurposing most of the code from the previous solution with the “bug”, and had thought I fixed it. Trust me, I was completely baffled.

Then it dawned on me: I was using the /upload folder in those two solutions — I was placing downloaded images I retrieved from the internet via code into the /upload directory of my Sitecore instance — and remembered Sitecore had an “out of the box” feature which uploads images that are placed into the /upload directory into the Media Library automatically (btw, I remember this feature has existed since I started on Sitecore 9 years ago, so it’s been around for a while; I only forgot about it because I haven’t had any clients use it for many years). Once I changed where I was saving these images on disk, the “bug” magically disappeared.

So that mysterious and baffling — not to mention frustrating — experience brings me to this post. How does Sitecore know there is an image in the /upload directory ready to be uploaded into the Media Library?

Let me introduce you to the UploadWatcher, a Sitecore.IO.FileWatcher which lives in the Sitecore.Resources.Media namespace in Sitecore.Kernel.dll — if you don’t know what a Sitecore FileWatcher is, please see my post on what they are and how to create a custom one in Sitecore.

Like all FileWatchers in Sitecore, the UploadWatcher is defined in the Web.config under /configuration/system.webServer/modules:

upload-watcher-config-0

You might be asking “Mike, why are these defined in the Web.config and not in a patch include configuration file?” Well, all Sitecore FileWatchers are essentially HTTP Modules and, unfortunately, that’s where they must be defined.

How does the UploadWatcher know to monitor the /upload directory in the website root of my Sitecore instance? Well, this is defined in Sitecore configuration under /configuration/sitecore/settings/setting[@name=’MediaFolder’]:

upload-watcher-config-1

You can use a patch configuration file to change the above value if you do not want the UploadWatcher to read from the /upload directory.

The UploadWatcher instance also checks other parts of Sitecore configuration. The following configuration is used specifically by the UploadWatcher:

upload-watcher-config-2-a

It appears you can also change things in the above configuration but I would suggest you don’t unless you have a good reason to do so.

The UploadWatcher also reads the following Sitecore configuration:

upload-watcher-config-3-a

What’s the above configuration all about? Basically, the UploadWatcher instance loads these into a private collection on itself, and uses this collection when checking to ignore files with certain substrings in their file names. You can also include elements that define substrings in a file path to be ignored — you would do so by using <ignorepath contains=”some substring” /> elements. These elements would be siblings of the <ignore /> elements, and are read into a separate private collection on the UploadWatcher instance.

In my next post, I will give an example on how to add functionality to the UploadWatcher. Until then, keep on Sitecoring.