Sitecore Xperiences » WFFM

WFFM - Sitecore Context Item NULL inside a Save Action

Rodrigo Peplau — Sun, 06 Aug 2017 14:10:26 +0000

Business requirements

There is a use case in one of our clients at Nish Tech, where a WFFM form, with a Submit E-mail Save Action, is supposed to be reused at several different parts of the website. It should have the same fields and look & feel at every place we want to reuse it, the only difference would be that the e-mail would be submitted to different addresses depending on what page the form is located.

The pages where this form will be allowed are what we call “Communities”. Each of them has a couple of fields with e-mails (Eg: Sales E-mail, Human Resources E-mail) from which we wanted to have WFFM looking for, instead of using the one hardcoded at the WFFM itself.

One may ask: why not duplicate the WFFM form and hardcode a different e-mail for each page we need? The answer is plenty clear: we will have more than 80 communities, and growing. That would mean more than 80 duplications of the WFFM form, which sound quite abusive. If we happen to need some kind of maintenance at these forms, this would be a nightmare.

The resulting implementation will be subject of a future blog post, this one in particular will focus in a specific challenge: how to access the Sitecore.Context.Item inside a WFFM Save Action.

Technical challenge

So the idea is that WFFM should look into a field at the item where it is located, grabbing the destiny e-mail from there instead of the hardcoded e-mail at the WFFM Form itself. To achieve this we will need to access the current context item (Sitecore.Context.Item), which surprisingly is not available inside a Save Action, as confirmed by Sitecore in a Helpdesk ticket we created.

To be fair, Sitecore.Context.Item is available in Preview Mode because Sitecore explicitly sets the current item ID at the querystring. However, in publish mode there are no such parameter at the querystring, which happens to let Sitecore.Context.Item with value NULL when you are inside a Save Action. This happens because the Item Resolver only runs AFTER the Save Action, thus Context.Item will only be filled after the Save Action is executed.

Implementing a Solution

So here is the solution we ended up arranging, with best possible reusing of same WFFM and not jeopardizing WFFM’s or Sitecore’s normal pipelines and flows.

Step 1 – Create a new WFFM field for Sitecore.Context.Item

This would be a hidden field at the form, responsible for carry on the Sitecore.Context.Item.ID, available at the time when the form is rendering, to the Save Action where that is not available.

At /sitecore/system/Modules/Web Forms for Marketers/Settings/Field Types/Simple Types start by duplicating the “Single-Line Text” field to serve as a basis for our new field;
Rename it to “Sitecore Context Item ID”;
Fill the field “MVC Type” with the assembly we are going to create to our new field:
ClientName.Website.Core.WFFM.Fields.SitecoreContextItemId, ClientName.Website.Core
Create a view called “SitecoreContextItemId.cshtml” for this field under /Views/Form/EditorTemplates and add the following content. Notice the surrounding the field, which will make it hidden when the form renders

@using Sitecore.Forms.Mvc.Html
@model Sitecore.Forms.Mvc.ViewModels.FieldViewModel

@using (Html.BeginField())
{      
    @Html.BootstrapEditor("Value")    
}

Step 2 – Make that field comes auto-populated with Context.Item

This class, which is tied to the field at the bullet 3 of Step 1, implements the logic that makes the field renders with Sitecore.Context.Item.ID auto-populated. Notice that this is simply inheriting from SingleLineTextField, adding the ID to the field Value, and nothing else.

using Sitecore.Forms.Mvc.ViewModels.Fields;
namespace ClientName.Website.Core.WFFM.Fields
{
    public class SitecoreContextItemId : SingleLineTextField
    {
        public override void Initialize()
        {
            if (this.MaxLength != 0)
                return;
            this.MaxLength = 256;
            this.Value = Sitecore.Context.Item.ID.ToString();
        }
    }
}

Step 3 – Make Context.Item be automatically filled from that field

We could very well now just go ahead and read from that field, couldn’t we? But to make things pretty, instead of that we are going to implement a pipeline processor to populate Sitecore.Context.Item.

Create an include file “Sitecore.WFFM.SetContextItem.config” with following content:

Then let’s implement this class to make Sitecore.Context.Item be populated.

using System.Linq;
using Sitecore.Data;
using Sitecore.Diagnostics;
using Sitecore.Forms.Mvc.Interfaces;
using Sitecore.Forms.Mvc.Models;
using Sitecore.Forms.Mvc.Pipelines;
namespace ClientName.Website.Core.WFFM.Pipelines
{
    public class SetContextItem : FormProcessorBase
    {
        public override void Process(FormProcessorArgs args)
        {
            Assert.ArgumentNotNull((object)args, "args");
            var model = args.Model as FormModel;
            if (model == null || Sitecore.Context.Item!=null)
                return;
            var contextField = model.Item.Fields.FirstOrDefault(p => p.MVCClass.Contains(typeof(Fields.SitecoreContextItemId).FullName));
            if (contextField == null)
                return;
            var contextFieldResult = model.Results.FirstOrDefault(p => p.FieldName == contextField.Name);
            if (contextFieldResult == null)
                return;
            var contextItem = Sitecore.Context.Database.GetItem(new ID(contextFieldResult.Value.ToString()));
            Sitecore.Context.Item = contextItem;
        }
    }
}

Pay special attention to the following lines:

var contextField = model.Item.Fields.FirstOrDefault(p => p.MVCClass.Contains(typeof(Fields.SitecoreContextItemId).FullName));

Where the assembly name we created at Step 2 is used to find our field and next:

var contextFieldResult = model.Results.FirstOrDefault(p => p.FieldName == contextField.Name);

Where the ID value is taken to later populate Sitecore.Context.Item:

var contextItem = Sitecore.Context.Database.GetItem(new ID(contextFieldResult.Value.ToString()));
Sitecore.Context.Item = contextItem;

Step 4 – Add the field to your WFFM Form

Easy part, but if forgotten nothing will work. Make sure your new field is present at your WFFM Form:

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!