I've implemented my own IAppendExtraInfoToRedirection and registered it with the container, following the below post.
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
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).
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?
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.
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.ExecuteStepImpl(IExecutionStep step)
at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)",
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?
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 :(
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" />
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"
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
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.