Sitecore Xperiences » Bug fixing

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!

Corey Peplau wrote this - WFFM conflict with Unity DI and a lesson on how Sitecore community is so amazing

Rodrigo Peplau — Mon, 24 Jul 2017 13:35:09 +0000

This blog was since the beginning, a space to share my own experiences with Sitecore development, always trying to bring that something new, not easily seen, or showing my interpretation of common problems. But this time I need to break my own rule and bring a story starred by another person. I’m talking about my good friend Corey Smith, the most willful person I ever met.

First a small parable

An engineer was hired to fix a complex machine, which he did in less than an hour by simply twisting a single screw.

How much it cost? Asks the client.
10 thousand dollars, sir…
But that is a lot of money just to twist a screw! I need you to do an invoice with details of your job to justify this price.

And the invoice listed:

Twist a screw: $ 5.00
Know what screw to twist: $ 9,995.00

Corey is a step ahead of this story and managed to not only twist the right screw, but made that remotely, and for free.

The WFFM issue

Everything started when, at my first project as new member of Nish Tech Inc, I had to install WFFM 8.2 rev. 170413 (Update-3) up above an existent solution. Starting from there, any MVC WFFM form were dying with the following error:

Error Rendering Controller: Sitecore.Forms.Mvc.Controllers.FormController, Sitecore.Forms.Mvc. Action: Index: Could not create controller: ‘Sitecore.Forms.Mvc.Controllers.FormController, Sitecore.Forms.Mvc’. The item being rendered is: ‘/sitecore/content/Website/Home/Community/Cincinnati’. The context item is: ‘/sitecore/content/Website/Home/Community/Cincinnati’. The current route url is: ‘{*pathInfo}’. This is the default Sitecore route which is set up in the ‘InitializeRoutes’ processor of the ‘initialize’ pipeline.

at Sitecore.Mvc.Controllers.SitecoreControllerFactory.CreateController(RequestContext requestContext, String controllerName)
  at Sitecore.Mvc.Controllers.ControllerRunner.GetController()
  at Sitecore.Mvc.Controllers.ControllerRunner.Execute()
  at Sitecore.Mvc.Presentation.ControllerRenderer.Render(TextWriter writer)
  at Sitecore.Mvc.Pipelines.Response.RenderRendering.ExecuteRenderer.Render(Renderer renderer, TextWriter writer, RenderRenderingArgs args)

Inner Exception: Resolution of the dependency failed, type = “Sitecore.Forms.Mvc.Controllers.FormController”, name = “(none)”. Exception occurred while: while resolving. Exception is: InvalidOperationException – The current type, Sitecore.Forms.Mvc.Interfaces.IRepository`1[Sitecore.Forms.Mvc.Models.FormModel], is an interface and cannot be constructed. Are you missing a type mapping? ———————————————– At the time of the exception, the container was: Resolving Sitecore.Forms.Mvc.Controllers.FormController,(none) Resolving parameter “repository” of constructor Sitecore.Forms.Mvc.Controllers.FormController(Sitecore.Forms.Mvc.Interfaces.IRepository`1[[Sitecore.Forms.Mvc.Models.FormModel, Sitecore.Forms.Mvc, Version=8.2.0.0, Culture=neutral, PublicKeyToken=null]] repository, Sitecore.Forms.Mvc.Interfaces.IAutoMapper`2[[Sitecore.Forms.Mvc.Interfaces.IFormModel, Sitecore.Forms.Mvc, Version=8.2.0.0, Culture=neutral, PublicKeyToken=null],[Sitecore.Forms.Mvc.ViewModels.FormViewModel, Sitecore.Forms.Mvc, Version=8.2.0.0, Culture=neutral, PublicKeyToken=null]] mapper, Sitecore.Forms.Mvc.Interfaces.IFormProcessor`1[[Sitecore.Forms.Mvc.Models.FormModel, Sitecore.Forms.Mvc, Version=8.2.0.0, Culture=neutral, PublicKeyToken=null]] processor, Sitecore.WFFM.Abstractions.Shared.IAnalyticsTracker analyticsTracker) Resolving Sitecore.Forms.Mvc.Interfaces.IRepository`1[Sitecore.Forms.Mvc.Models.FormModel],(none)

at Microsoft.Practices.Unity.UnityContainer.DoBuildUp(Type t, Object existing, String name, IEnumerable`1 resolverOverrides)
  at Microsoft.Practices.Unity.UnityContainer.Resolve(Type t, String name, ResolverOverride[] resolverOverrides)
  at Sitecore.Mvc.Controllers.SitecoreControllerFactory.CreateControllerInstance(RequestContext requestContext, String controllerName)
  at Sitecore.Mvc.Controllers.SitecoreControllerFactory.CreateController(RequestContext requestContext, String controllerName)

Inner Exception: The current type, Sitecore.Forms.Mvc.Interfaces.IRepository`1[Sitecore.Forms.Mvc.Models.FormModel], is an interface and cannot be constructed. Are you missing a type mapping?

at Microsoft.Practices.ObjectBuilder2.DynamicMethodConstructorStrategy.ThrowForAttemptingToConstructInterface(IBuilderContext context)
  at lambda_method(Closure , IBuilderContext )
  at Microsoft.Practices.ObjectBuilder2.DynamicBuildPlanGenerationContext.<>c__DisplayClass1.b__0(IBuilderContext context)
  at Microsoft.Practices.ObjectBuilder2.BuildPlanStrategy.PreBuildUp(IBuilderContext context)
  at Microsoft.Practices.ObjectBuilder2.StrategyChain.ExecuteBuildUp(IBuilderContext context)
  at Microsoft.Practices.ObjectBuilder2.BuilderContext.NewBuildUp(NamedTypeBuildKey newBuildKey)
  at lambda_method(Closure , IBuilderContext )
  at Microsoft.Practices.ObjectBuilder2.DynamicBuildPlanGenerationContext.<>c__DisplayClass1.b__0(IBuilderContext context)
  at Microsoft.Practices.ObjectBuilder2.BuildPlanStrategy.PreBuildUp(IBuilderContext context)
  at Microsoft.Practices.ObjectBuilder2.StrategyChain.ExecuteBuildUp(IBuilderContext context)
  at Microsoft.Practices.Unity.UnityContainer.DoBuildUp(Type t, Object existing, String name, IEnumerable`1 resolverOverrides)

The greatness of Sitecore community

After some googling I found this article from Corey Smith, where he describes a similar issue after an upgrade, which he solved by moving his Dependency Injection declaration before the InitializeControllerFactory. I know that recent versions of WFFM are using Dependency Injection, so it sounded like a good clue to start my investigation.

But in my case we were using Unity Dependency Injection, nothing registered at Sitecore Pipeline, so I thought – why not asking Corey himself for an idea? He is a great guy, as per what we’ve seen during his presentation at the Sitecore Usergroup Brazil (video can be seen here).

What followed was a real lesson for me, breaking my paradigms of balance between personal and professional life, and showing to my amazed eyes how strong, powerful and great is the Sitecore community in general, and Corey Smith in particular.

Our investigation

It was 3rd July, I was stuck at the hotel in Cincinnati with my family and this issue to solve. Corey were safe at his home in Atlanta, at the convenient distance of a single click to interrupt the chat. We were texting like crazy thru Twitter private messages. Fortunately, we both had beers at our side, would you do without some?

We started focusing at the Unity Dependency Injection setup. Under my App_Start folder I had a class called UnityMvcActivator with following decorations above the namespace:

[assembly: WebActivatorEx.PreApplicationStartMethod(typeof(UnityWebActivator), “Start”)]

[assembly: WebActivatorEx.ApplicationShutdownMethod(typeof(UnityWebActivator), “Shutdown”)]

namespace MyClient.Website.Core.App_Start

{

   public static class UnityWebActivator

   {

       public static void Start()

       {

Line in bold is specifically setting the start-up of Dependency Injection. That would be automatically invoking (at some point in the Application_Start event) the method Start(). The exact point, however, was a mystery for us, so we managed to increase a little of our control over this. Perhaps changing the order here would make any difference?

So we removed the line in bold, then registered the method Start as an Initialize Pipeline processor. For that, the Start signature had to change into a valid Process method, as seem below:

public void Process(PipelineArgs args)

That way we would be able to control the timing when the DI start-up would occur. Promising? I thought so! However unfortunately, no matter where the registration is made, before or after everything, still the same error was showing.

Root cause

After digging a bit more, Corey came up with the root cause, and a possible solution. Happens that the controller for WFFM forms (FormController), which is the affected class at the error message, has actually two constructors: one without any parameter

public FormController()

And a second one with more parameters

public FormController(IRepository repository, IAutoMapper mapper, IFormProcessor processor, IAnalyticsTracker analyticsTracker)

When Unity tries to instantiate this class it is automatically choosing the controller with most parameters. And that is making the whole thing blow up to the sky.

Temporary (quick) solution

The temporary solution we ended up doing was:

Roll back the pipeline modification and allow Unity to registry itself again
Add the following new line to UnityConfig, RegisterTypes method:

public class UnityConfig

{

       public static void RegisterTypes(IUnityContainer container)

       {

           // Workaround to solve WFFM issues

           container.RegisterType(new InjectionConstructor());

What the line above does is to tell Unity to register, only at the FormController class, the constructor with no parameters. This, however, is an ad-hoc solution which brings a very important indagation: What else are we breaking in Sitecore? What other controllers and dependencies do we need to register?

“You will probably find out in production, I suppose” says Corey.

Appropriate (hard) solution

Best thing to do is to abandon Unity Dependency Injection at this project and have Sitecore’s built-in Dependency Injection (Microsoft.Extensions.DependencyInjection) to handle all injections at our system. We are not gaining anything using Unity at this project, but actually we are creating problems.

Sitecore’s OOTB Dependency Injection is shipped from factory with all proper Dependency Injection configurations. That means that all Sitecore modules play very nice with it, so the whole issue we are having with Unity, for instance, simply wouldn’t even happen at first place.

Along with that, in Sitecore 8.2, we can do Dependency Injection into pipeline processors, which has always been a requirement at Nish Tech, and is also totally awesome!

Language specific MediaProvider breaking icons at Media Library

Rodrigo Peplau — Tue, 14 Feb 2017 15:00:30 +0000

UPDATE: Kamruz Jaman has contributed with a comment for a simpler, less intrusive and more generalist solution: Inside the GetMediaUrl method of your custom MediaProvider, check for the “Thumbnail” property of your MediaUrlOptions parameter. If it is true, make your code fall back to the base, such as:

if (mediaOptions.Thumbnail)
return base.GetMediaUrl(mediaItem, mediaOptions);

During an upgrade from Sitecore 6.5 to Sitecore 8.1 one issue were noticed at the Media Library: when a Media Item is uploaded, the icon appears broken.

A custom MediaProvider is used at this build to modify the way Sitecore generates Media Item urls. All it does is to add the language at beginning of the media URL so we can have language-specific media items. This is important to allow the same Media Item (etc: an image or PDF) to be served in multiple languages.

Root cause

When a media item is uploaded to the Media Library, Sitecore will fill the “Icon” field with the URL of the media item itself. Because of the custom MediaProvider, language is being added to the beginning of the generated URL. Apparently that was not a problem in Sitecore 6.5, but things seems to have changed at Sitecore 8.

Technical explanation by Sitecore

A Support Ticket #476256 were created to allow further investigation from Sitecore on this issue. According to the technical team:

“The behavior you reported is expected as tree node icons are rendered by Sitecore.Shell.Applications.ContentManager.Sidebars.Tree.RenderIcon(Item item) method which does not use language definition, embedded to URL, to resolve item language. So when the Icon field contains URL with language definition embedded, it breaks the method functionality and leads to incorrect resolution of the item’s icon.

When you have versioned media item, the icon is rendered for specific language automatically even when language is not specified deliberately. For instance, if you have media item with two language versions and different images for each language, and use -/media/ItemGUID.ashx?h=16&thn=1&w=16 string in the Icon field, language specific icon will be rendered when you switch the language in the Content Editor.”

This explains the causes but doesn’t fix the issue: how can we skip or bypass the custom MediaProvider, avoiding the language to be added to the URL when the “Icon” field is filled?

Solution

In order to fix that we will need to extend and override the Sitecore.Resources.Media.Media class, responsible for the upload and update of metadata when a Media Item is uploaded to the Media Library, then modify all Media Types to use your class instead of the original.

Step 1 – Extend the Media class

This is going to be responsible for removing the language from the URL when a Media Item is uploaded. In bold you see the code responsible for that, rest is basically native code to ensure compliance with default Sitecore behavior.

using Sitecore;
using Sitecore.Configuration;
using Sitecore.Data.Items;
using Sitecore.Data.Proxies;
using Sitecore.Diagnostics;
using Sitecore.Resources.Media;
using Sitecore.SecurityModel;

namespace CustomMediaProvider
{
  public class Media : Sitecore.Resources.Media.Media
  {
    public override Sitecore.Resources.Media.Media Clone()
    {
      return new Media();
    }

    public override void UpdateMetaData(MediaStream mediaStream)
    {
      Assert.ArgumentNotNull(mediaStream, "mediaStream");
      var innerItem = MediaData.MediaItem.InnerItem;
      if (!innerItem.Paths.IsMediaItem) return;
      using (new EditContext(innerItem, SecurityCheck.Disable))
      {
        innerItem["extension"] = mediaStream.Extension;
        innerItem["mime type"] = mediaStream.MimeType;
        innerItem["size"] = mediaStream.Length.ToString();
        if (Settings.Media.AutoSetAlt)
        {
          innerItem["Alt"] = innerItem.Name;
        }
        var shellOptions = MediaUrlOptions.GetShellOptions();
        shellOptions.Thumbnail = true;
        shellOptions.Height = 0x10;
        shellOptions.Width = 0x10;
        var realItem = ProxyManager.GetRealItem(innerItem, true);
        // CODE ADDED TO REMOVE LANGUAGE FROM URL WHILE UPLOADING
        var iconUrl = MediaManager.GetMediaUrl(realItem, shellOptions);
        var prefix = "/" + Context.Language.Name + "/";
        if (iconUrl.StartsWith(prefix)) iconUrl = iconUrl.Replace(prefix, "");
        innerItem.Appearance.Icon = iconUrl;
      }
    }
  }
}

Step 2 – Register the Media class to all Media Types

This is the painful part: we will need to register our class to every Media Type we want to cover. There is no easy way for that other than adding a node for each Media Type, paying attention to the correct way for patching that specific node (some nodes may have a Media class already defined and thus needs correct patching, others don’t).


 
 
 
 
 CustomMediaProvider.MediaProvider,CustomMediaProvider