Form Thank you page - DefaultAppendExtraInfoToRedirection doesn't work

Member since: 2008
 

I've implemented my own IAppendExtraInfoToRedirection and registered it with the container, following the below post.

https://world.episerver.com/documentation/developer-guides/forms/redirecting-to-thank-you-page/

However it doesn't work and the code never gets hit when debugging. Also, when I remove my custom implementation it doesn't look like the default implementation (DefaultAppendExtraInfoToRedirection)  works anymore in my solution (CMS 10.10.1 + Forms 4.7). My understanding is that this should add the following querystring parameters onto any thank you page redirects

  •  __FormSubmissionId
  • __FormGuid
  • __FormLanguage

Why might this not be working? Could it be related to any form configuration (we work in non JS mode), or could it be related to any custome actors I have (that are working in sync mode as they set cookies on the response). 

Any ideas?

#187142 Jan 13, 2018 1:41
  •  

    I have check on Alloy template and it is working on lastest Forms. The URL looks like: "?__FormGuid=002c5114-0410-4f45-9c43-2b6ab5cb5f15&__FormLanguage=en&__FormSubmissionId=54d92b26-90fe-466e-85bb-2f7590464c18" for both js and non-js mode. Could you try to reproduce on the alloy template and if it work or not?

    #187150 Jan 15, 2018 4:46
  • Member since: 2008
     

    Thanks for the reply.

    I also can't reproduce on latest Alloy. I don't think its necessarily a bug with the core Forms product. I was just trying to get an idea of where might be a good place to start. Redirection happens fine, its just any additional parameters aren't added.

    I guess I'll start transfering our custom form implementation to the latest Alloy to see if I can reproduce - we have a fair few extensions, custom actors, external system information mappings, custom form blocks etc etc. I was just hoping there might be an obvious place to start or logging that might help

    Our custom actor is feels like the right place to look at as this has IsSyncedWithSubmissionProcess = true and so modifies the response. 

    #187167 Jan 15, 2018 10:30
  • Member since: 2008
     

    Update: I've found this exception appears on Form submission, which feels related, though I'm not sure what the content link that could be missing is

    System.ArgumentNullException: The provided content link does not have a value.
    Parameter name: contentLink
       at EPiServer.Core.Internal.DefaultContentLoader.Get[T](ContentReference contentLink, LoaderOptions loaderOptions)
       at EPiServer.Web.Routing.Internal.DefaultSimpleAddressRouteHandler.GetContentReference(UrlBuilder urlBuilder, SegmentContext segmentContext)
       at EPiServer.Web.Routing.Internal.DefaultSimpleAddressRouteHandler.GetRouteValues(String urlSegment, ContentReference routeRoot, SegmentContext segmentContext)
       at EPiServer.Web.Routing.Segments.Internal.SimpleAddressSegmentRouter.ResolveContentForIncoming(ContentReference contentlink, String urlSegment, SegmentContext context)
       at EPiServer.Web.Routing.Segments.Internal.SimpleAddressSegment.GetIncomingNode(ContentReference contentLink, SegmentContext context)
       at EPiServer.Web.Routing.Segments.Internal.SimpleAddressSegment.RouteDataMatch(SegmentContext context)
       at System.Linq.Enumerable.All[TSource](IEnumerable`1 source, Func`2 predicate)
       at EPiServer.Web.Routing.Internal.DefaultContentRoute.RouteSegmentContext(SegmentContext segmentContext)
       at EPiServer.Web.Routing.Internal.DefaultContentRoute.GetRouteData(HttpContextBase httpContext)
       at System.Web.Routing.RouteCollection.GetRouteData(HttpContextBase httpContext)
       at System.Web.Routing.UrlRoutingModule.PostResolveRequestCache(HttpContextBase context)
       at System.Web.HttpApplication.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
       at System.Web.HttpApplication.ExecuteStepImpl(IExecutionStep step)
       at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)",
    #187235 Jan 16, 2018 16:09
  •  

    It look like no code in Forms invoke in your exception. Could you try with a new simple Form to see if the problem still there?

    #187256 Jan 17, 2018 3:17
  • Member since: 2008
     

    That stack trace may have been a red herring. However your idea of setting up a simple form helped. Thanks

    I've discovered that the issue is because of an overidden FormContainer view. If I remove that from the project (or rename the ElementBlocks views folder) the redirection functionality starts working again!

    Any ideas what could cause this? What could be removed changed in FormsContainer.ascx that could cause this?

    This exact thing (View html changes breaking core functionality) is one of my main frutrations with the Forms solution. There is a lot of logic within the views (the FormContainer.ascx) is complex. Styling / markup class changes are a definite implemetation requirement, but changing them can often break other functioinality. I'm never sure what class names / form params are needed etc. It makes the whole thing a little fragile and absolutely not a great developer experience :(

     

    #187291 Jan 18, 2018 1:06
  •  

    There are some hidden fields which rendered by FormContainerBlock.ascx, could you check those are still there in your custom view

    <input type="hidden" class="Form__Element Form__SystemElement FormHidden FormHideInSummarized" name="__FormGuid" value="<%: Model.Form.FormGuid %>" data-f-type="hidden" />
    <input type="hidden" class="Form__Element Form__SystemElement FormHidden FormHideInSummarized" name="__FormHostedPage" value="<%: FormsExtensions.GetCurrentPageLink().ToString() %>" data-f-type="hidden" />
    <input type="hidden" class="Form__Element Form__SystemElement FormHidden FormHideInSummarized" name="__FormLanguage" value="<%: FormsExtensions.GetCurrentPageLanguage() %>" data-f-type="hidden" />
    <input type="hidden" class="Form__Element Form__SystemElement FormHidden FormHideInSummarized" name="__FormCurrentStepIndex" value="<%: ViewBag.CurrentStepIndex ?? "" %>" data-f-type="hidden" />
    <input type="hidden" class="Form__Element Form__SystemElement FormHidden FormHideInSummarized" name="__FormSubmissionId" value="<%: ViewBag.FormSubmissionId %>" data-f-type="hidden" />

    #187292 Jan 18, 2018 3:23
  • Member since: 2008
     

    Ok, so the above hint set me on the right path and I've got to the bottom of this. 

    First step was to remove our custom FormContainerBlock.ascx and fall back to the default. When submitting data using the default FormContainer the redirection querystrings from our custom were included in the redirection url.

    Next I checked the difference in the post requests that were generated by each of the form submissions (one using our custom FormContainerBlock and one using the default). There was a singular difference/.

    The following form value was missing from form submissions from our custom FormContainerBlock

    --

    Content-Disposition: form-data; name="submit"

    1419ed9c-2c75-400a-8b40-a81969b64fee

    --

    Looking at the form elements I could see that this is the GUID that is set on the html button element that acts as the submit button for the form. Including this value in the form submission caused the redirection paremeters to be added.

    I guess Episerver forms must use this submitted value to check if any of the parameters on the button should be used - such as finalising form, a specific redirect etc. 

    THE ROOT CAUSE

    Well if you've made it this far, then the root cause was a piece of custom javascript we put in to prevent double submission of form data. We hooked into the button click event and disbaled the button. All good, apart from disabled form element values aren't included by the browser in form submissions (hence themissing submit value).

    The fix was to modify the submitbuttonelementblock and include an additional hidden form element with the form name of submit and a value of the guid, meaning that the relevant data is always submitted regardless of the state of the actual submit button.

    #187543 Jan 25, 2018 14:03