Sitecore Xperiences » Experience Editor

Custom Reset Layout in Content and Experience Editor Modes

Rodrigo Peplau — Fri, 09 Feb 2018 00:04:51 +0000

Recently I had to customize the code that triggers when a Reset Layout is executed. If you ever had to attach any code to it, this post is for you!

You know, that sympathetic prompt:

The first thing you need to know is that Content Editor and Experience Editor does that differently, so let’s go for them:

Round 1 – Content Editor

Content Editor uses a command for that (pagedesigner:reset), which is natively implemented by the class Sitecore.Shell.Applications.Layouts.PageDesigner.Commands.Reset. We first need to create a class that will inherit from the original, so we don’t lose the original behavior, and implement our custom logic on it.

Create a Command class like this:

using System.Web.Mvc;
using Sitecore.Shell.Applications.Dialogs.ResetLayout;
using Sitecore.Web.UI.Sheer;

namespace MyProject.Commands
{
    public class ResetLayoutCommand : Sitecore.Shell.Applications.Layouts.PageDesigner.Commands.Reset
    {
        protected override void Run(ClientPipelineArgs args)
        {
            // Runs the default behaviour
            base.Run(args);

            // Skips if the Reset Layout prompt is not submited or results is undefined
            if (!args.IsPostBack || string.IsNullOrEmpty(args.Result) || args.Result == "undefined")
                return;

            // Takes the item that has been reset
            var itemReset = DeserializeItems(args.Parameters["items"])[0];

            // And here is where your custom logic will be implemented
            // .....
        }
    }
}

Then we override the default command with our class in a config patch like this:

And this is how we run the first leg. But it is not over yet, let’s go for…

Round 2 – Experience Editor

Experience Editor, on the other hand, uses a different approach for that. It has a request node named “ExperienceEditor.ResetLayout.Execute” under that we need to replace. This request node is implemented by the native class Sitecore.ExperienceEditor.Speak.Ribbon.Requests.ResetLayout.Execute, which again we are going to inherit.

So our Request class will be like this:

using System;
using System.Web.Mvc;
using Sitecore.Diagnostics;
using Sitecore.ExperienceEditor.Speak.Attributes;
using Sitecore.ExperienceEditor.Speak.Server.Responses;
using Sitecore.Shell.Applications.Dialogs.ResetLayout;

namespace MyProject.ExperienceEditor
{
    public class ResetLayout : Sitecore.ExperienceEditor.Speak.Ribbon.Requests.ResetLayout.Execute
    {
        [HasItemPermissions(Id = "{BE98D7F0-7404-4F97-8E4C-8FEF4ACA5DA3}", Path = "/sitecore/content/Applications/WebEdit/Ribbons/WebEdit/Advanced/Layout/Reset")]
        public override PipelineProcessorResponseValue ProcessRequest()
        {
            // Instantiates the returning object and 
            var processorResponseValue = new PipelineProcessorResponseValue();

            try
            {
                // Executes the default RESET LAYOUT process
                processorResponseValue = base.ProcessRequest();

                // Takes the item that has been reset
                var itemReset = RequestContext.Item;

                // And here is where your custom logic will be implemented
                // ..... (OF COURSE, DON'T DUPLICATE YOUR LOGIC!)
            }
            catch (Exception e)
            {
                Log.Error(
                    $"[ResetLayout] Cannot execute post Layout Reset operations to item '{RequestContext.Item.Paths.Path}'", e, GetType());
            }
            return processorResponseValue;
        }
    }
}

And finally we patch it again with a config file like this:

And that’s all… You now have your custom code being triggered by both Content Editor and Experience Editor!

Sitecore 9 Update 1 - Bug saving Shared Layout in Experience Editor

Rodrigo Peplau — Thu, 01 Feb 2018 14:08:19 +0000

A few weeks ago, while upgrading one of at Nish Tech’s early-stages projects into Sitecore 9 Update 1, a very strange behavior when you try to do a very simple task: edit a Shared Layout of a page in Experience Editor.

When you try to do that, the infamous screen “Layout not Set” shows right after saving.

Initially, I observed that when saving in a _Standard Values, but later I noticed it can also happen with ordinary items. If you want to see how to reproduce the error, check this video.

Interesting enough, when you look at your Layout and Final Layout fields in Raw mode, you notice that the Shared Layout has a value such as:

Which seems to have a more appropriate syntax to be in the Final Layout field instead, as you can check if you match this against the original value:

Sitecore Helpdesk heroes

Then I reported the issue to our amazing Sitecore Helpdesk, who after a couple weeks came out with a bugfix, that now I want to share with our Sitecore Community.

I would like to thank the whole gang of superheroes at Sitecore Helpdesk, for providing this good HotFix in a proper time and allowing me to share it, in special to Igor Denisenko, Pavel Ivashchenko and Ielyzaveta Kalinchuk, the good guys who replied to my ticket. You are awesome, mates!

The cure: HotFix 203387

You can find the hotfix at this link.

Please be aware that the hotfix was built specifically for Sitecore XP 9.0 rev. 171219 (Update-1)! You should not install it on other Sitecore versions or in combination with other hotfixes unless explicitly instructed by Sitecore Support;
Note that you need to extract ZIP file contents to locate installation instructions and related files inside it.

If you have anything to add on this, please drop a comment and let me know!

Site-specific RichText Editor Profiles - custom Source in native RichText fields

Rodrigo Peplau — Sat, 06 Jan 2018 13:42:31 +0000

Everybody knows how to select different Editor Profiles using the Source property in a Rich Text field. Out of the box, you can only pass a hardcoded path to the Editor Profile, making the template totally linked to one and only one Profile.

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 “” 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:


     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 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
   {
     /// Gets or sets the source.
     /// The source.
     public new string Source
     {
       get { return GetViewStateString(nameof(Source)); }
       set
       {
         Assert.ArgumentNotNull(value, nameof(value));
         // Reuse the same Pipeline implementation here as at my  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.

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!

Prevent orphan components in Experience Editor when deleting composed components

Rodrigo Peplau — Fri, 29 Sep 2017 22:44:45 +0000

If an editor deletes a component in Experience Editor and that component has inner components, only the outer component will be actually deleted from the page rendering. Inner components will not show anymore (and often Content Editors will be happy), so why would that be a problem?

The problem

Take for instance this set of renderings of a certain page:

If in Experience Editor someone tries to delete it:

The result will be a “ghost” orphan item, which will not render when the page loads because its placeholder does not exist anymore.

That rendering will continue at the page rendering, being either forgotten forever or re-appearing when someone tries to add a new Carousel to the same Full-Width Container placeholder.

Not just me

I’ve seen more people concerned with that – such as the author of this question at Sitecore Exchange – and some other people suggested possible solutions.

One approach I tried was to follow this blog post by Mike Tschida and implement a pipeline processor to clean-up the Page Rendering, removing orphan components when the page is saved. That would be perfect, however during development or debugging, it is very common to temporarily move a component to an unexistent placeholder to make it vanish from the page. In cases like that, the component would be deleted, which is not desired.

Acting at the other end

So what if, instead of acting later at the server, we stop content editors at the root of the problem: the Experience Editor? At that case, when an editor attempts to delete a component which has inner components, a prompt like this would be displayed. In order to delete the outer component, the editor now needs to delete the inner components first.

Inspired by this simple Stack Overflow post, in which the author was looking for a way to simply ask for a confirmation before deleting a component, I ended up with the solution below.

Nip the evil in the bud

The deletion of a component is handled by javascript code located at \sitecore\shell\Applications\Page Modes\ChromeTypes\RenderingChromeType.js – more specifically at the deleteControl method. Our fix will comment out the original code (I will leave there for future reference in case of an upgrade) and add the following code:

    deleteControl: function () {
        var canDelete = this.canDeleteControl(this.chrome);
        if (canDelete === false) {
            alert("Please delete inner controls before deleting this.");
            return false;
        }
        var placeholder = this.getPlaceholder();
        if (placeholder) {
            placeholder.type.deleteControl(this.chrome);
            return true;
        }
        return false;
    },

Along of course with the new canDeleteControl method, which does the trick of verifying if the component attempted to be deleted has inner components.

    canDeleteControl: function (chrome) {
        var canDelete = true;
        var childChromes = chrome.getChildChromes();
        for (var i = 0; i < childChromes.length; i++) {
            if (childChromes[i].type.key() == "placeholder") {
                canDelete = this.canDeleteControl(childChromes[i]);
                if (canDelete === false)
                    break;
            }
            else if (childChromes[i].type.key() == "rendering") {
                canDelete = false;
                break;
            }
        }
        return canDelete;
    },

And that’s all we need! Replace this file in all instances, clean up your browser caches and don’t worry about orphan components anymore!

Advanced display of SVG Images in Sitecore

Rodrigo Peplau — Fri, 31 Jul 2015 23:56:39 +0000

SVG Images are basically vector images (coordinates, objects and properties) with data that can be manipulated with CSS styling – check out this article for details on how that works.

In short, to take advantage of CSS styling over SVG files, you must throw the XML content of the SVG file, directly into the HTML markup. So instead of the traditional

You must throw inline the content of the SVG file, which will be something like:
svg>
In Sitecore that means you can’t use the standard sc:Image control to render the content of an Image Field – that will render your SVG as an 
Usercontrol
In order to have something that is compatible both with CSS Styling and Sitecore’s Page Editor mode, my proposal is to have a custom asp usercontrol like this:
Image.ascx
<%@ Control Language="C#" AutoEventWireup="true" CodeBehind="Image.ascx.cs" Inherits="Layouts.UserControls.Image" %>


 Image.ascx.cs (Codebehind)
namespace Layouts.UserControls
{
 public partial class Image : UserControl
 {
   /// 
   /// Component's Field
   /// 
   public string Field { get; set; }
   /// 
   /// Component's Item (Default=Context)
   /// 
   public Item Item
   {
      get { return _item ?? Sitecore.Context.Item; }
      set { _item = value; }
   }
   private Item _item;
   protected void Page_Load(object sender, EventArgs e)
   {
     // When editing in Page Editor mode, always use an 
     // Escape if field is not found
     var referencedImageField = (Sitecore.Data.Fields.ImageField)Item.Fields[Field];
     if (referencedImageField == null)
     {
       ShowScImage();
       return;
     }
     // Get referenced image - Scape if image is not found
     var imageItem = referencedImageField.MediaItem;
     if (imageItem == null)
     {
        ShowScImage();
        return;
     }
     // If this is not an svg use a normal 
     ShowSvgImage(imageMediaItem);
 }
 public static string GetMediaUrlWithServer(MediaItem mediaItem, Item item = null)
 {
    item = item ?? Sitecore.Context.Item;
    var options = new UrlOptions { AlwaysIncludeServerUrl = true, AddAspxExtension = false };
    var itemUrl = LinkManager.GetItemUrl(item, options);
    var mediaOptions = new MediaUrlOptions { AbsolutePath = true };
    var mediaUrl = MediaManager.GetMediaUrl(mediaItem, mediaOptions);
    return itemUrl + mediaUrl;
 }
 private void ShowSvgImage(MediaItem mediaItem)
 {
    litImage.Visible = true;
    scImage.Visible = false;
    // Get string from Image Stream
    var stream = mediaItem.GetMediaStream();
    var reader = new StreamReader(stream);
    var svgString = reader.ReadToEnd();
    reader.Close();
    stream.Close();
    // Get SVG tag from string
    // No SVG tag found - fallback to 
    svgString = svgString.Substring(svgString.IndexOf("
 private void ShowScImage()
 {
    litImage.Visible = false;
    scImage.Visible = true;
    scImage.Item = Item;
    scImage.Field = Field;
    ReflectAttributesToControl(scImage); 
 }
 private void ReflectAttributesToControl(WebControl control)
 {
    foreach (string key in Attributes.Keys)
     control.Attributes[key] = Attributes[key];
 }
}
Streaming
The proposed solution makes use of Streaming for better performance, so rendering times are not affected.
How to Use
Now we have our custom image rendering control that renders inline SVG images when you are in Preview or Normal mode, and is compatible with Sitecore’s Page Editor mode.
To use, first you have to register the Usercontrol:
<%@ Register TagPrefix="custom" TagName="Image" Src="~/layouts/UserControls/Image.ascx" %>
Then use it just like you’d do with a standard sc:Image control:

At the code behind you can also access the properties “Field” and “Item” just like the normal Image control:
imgClear.Item = Sitecore.Context.Item;
And that’s all!