Once in a while when working with Sitecore, it happens that you stumble across a nice little feature. Recently, I learned about the Sitecore Registry, which I didn't know about before.

The Registry is a class in the Sitecore.Web.UI.HtmlControls namespace in Sitecore.Kernel. It gives you an simple way to store information in the current user profile as well as reading it back later.

public static class Registry
{
    public static bool GetBool(string key)
    public static bool GetBool(string key, bool defaultvalue)
    public static int GetInt(string key)
    public static int GetInt(string key, int defaultvalue)
    public static string GetString(string key)
    public static string GetString(string key, string defaultvalue)
    public static void SetBool(string key, bool val)
    public static void SetInt(string key, int val)
    public static void SetString(string key, string value)
    public static string GetValue(string key)
    public static void SetValue(string key, string value)
}

As you see in the code example, you can directly use bool, int and string types and optionally provide a default value.

Choose your key wisely

Sitecore itself is using the Registry heavily so you want to choose a unique key to avoid overwriting any Sitecore functionality by accident. Furthermore, if you use Current_User in your key, it will be replaced with the actual user name. As an example, the UserOptions class uses the following key to know if you wanted to see the raw values of an item:

Registry.GetBool("/Current_User/UserOptions.ContentEditor.ShowRawValues", false)

You should always have Current_User in your key, if you want to store any information on the user profile. The next section will tell you why.

The Registry wants to be your friend, but sometimes it isn't

The Registry is using a Sitecore cache internally. This is in general a good idea, but can lead to some unwanted behavior in specific situations. As you see in the following decompiled Sitecore code, the cache is site sensitive:

namespace Sitecore.Web.UI.HtmlControls
{
    public static class Registry
    {
        [...]
        
        public static string GetValue(string key)
        {
            [...]
            RegistryCache registryCache = CacheManager.GetRegistryCache(Context.Site);
            [...]
        }
        
        [...]
    }
}

This can be an issue when using the Registry in the experience editor. When setting a Registry value within a command triggered by a button in the ribbon, you will most likely be in the context of the shell. If you then access the value, let's say to show or hide a custom experience button for a component on your page, your context will be set to the current site. Therefore, you might end up with the wrong value from the cache. I only realized this, because I happened to run into exactly this gnarly behavior. Dear reader, consider yourself warned :)

A possible solution could be to always make sure you are in the same site context when accessing a value from the Registry.

public string GetExampleValue(string key)
{
    using (new SiteContextSwitcher(SiteContext.GetSite("shell")))
    {
        return Registry.GetString(key);
    }
}

Fun fact

Oh my, did I really just add a section called fun fact? Sitecore uses this caching behavior in a few cases to share information between users. By using Current_Users instead of Current_User (see the additional "s"?) in the key, it for example shares a list of recent users logged into the backend.