Hardcoded???

But what if we could make this dynamic and site-specific? That way, the same template could present different Editor Profiles for different websites.

Something like this:

Then at each of your websites you can have your own Source definition item:

Cool?

Site-specific field Sources

If you ever happen to play with Habitat you might have noticed it has a Multisite Module, that implements something similar for Component’s Datasources. My solution is based on that, working perfectly with Droplists and other listing fields.

Not so fast…

But unfortunately, it doesn’t work with the RichText field since it is attached to the “<getLookupSourceItems>” pipeline. The RichText field has a different implementation which does not trigger this pipeline.

Custom Source for Rich Text fields!

So how can this be customized? After a long web research and decompiling Sitecore DLLs, here is what I came out.

If you take a look at the Field item definition under core:/sitecore/system/Field types/Simple Types/Rich Text you will notice it has the following content at the Control field:

I found out that this is similar to how a Command is registered, however no such a Command called “content:RichText” exists anywhere at my Sitecore configs. This is actually registered by the following config entry:

<controlSources>
    <source assembly="Sitecore.Kernel" namespace="Sitecore.Shell.Applications.ContentEditor" prefix="content" mode="on"/>

The secret here is the prefix=”content” which is used as the basis to register the whole namespace, taking classes dynamically by its name (“RichText” in this case).

Step 1 – Extend native class

Create your class that extends the Rich Text field – we will inherit from the original “Sitecore.Shell.Applications.ContentEditor.RichText” and only overwrite the Source property. Notice that I am re-using the same code used at my <getLookupSourceItems> to apply the same logic to the Rich Text field.

using Sitecore.Diagnostics;
using Sitecore.Pipelines.GetLookupSourceItems;
using Website.Core.Multisite.Pipelines;
namespace Website.Core.Fields
{
   public class RichText : Sitecore.Shell.Applications.ContentEditor.RichText
   {
     /// <summary>Gets or sets the source.</summary>
     /// <value>The source.</value>
     public new string Source
     {
       get { return GetViewStateString(nameof(Source)); }
       set
       {
         Assert.ArgumentNotNull(value, nameof(value));
         // Reuse the same Pipeline implementation here as at my <getLookupSourceItems> pipeline
         var processor = new LookupItemsFromField();
         var args = new GetLookupSourceItemsArgs()
         {
           Source = value,
           Item = Sitecore.Context.ContentDatabase.GetItem(ItemID)
         };
         processor.Process(args);
         value = args.Source;
         SetViewStateString(nameof(Source), value);
       }
    }
  }
}

Step 2 – Patch Sitecore to use our custom class

Now we need to patch Sitecore. Our custom class needs to be registered BEFORE the native one so it can assume its place.

<?xml version="1.0"?>
  <configuration xmlns:patch="http://www.sitecore.net/xmlconfig/">
    <sitecore>
      <controlSources>
        <source patch:before="source[@namespace='Sitecore.Shell.Applications.ContentEditor']" mode="on" namespace="Website.Core.Fields" assembly="Website.Core" prefix="content"/>
      </controlSources>
    </sitecore>
</configuration>

Now that you can intercept the native RichText implementation, you can implement your own logic for Source resolving!

You know a better way of doing this? Please let me know!