[su_note note_color=”#fafafa”]I like Web Forms For Marketers. I thinks it’s a great module and definitely the first option to consider when implementing marketing forms on Sitecore.[/su_note]
This rather short post is a collection of gotchas that I and the teams I work with came across when implementing WFFM with Sitecore MVC.
Controller Rendering for GET and POST
WFFM for MVC is implemented as a controller rendering. The form is basically POST-ed back to the item. Two potential gotchas here:
- If you have more than one WFFM form on a page (or other POST-aware controller renderings) they all will receive the POST with obvious side effects (read more on forms and controller renderings here).
- You can’t use WFFM on dynamic pages without some customizations (read more here).
An alternative implementation might consider POST-ing to a route. WFFM is already using routed requests for dropout tracking.
Conflicts with Rendering Model
WFFM for MVC is using a custom metadata provider that conflicts with certain usages of the RenderingModel. There is a workaround and a patch here. I filed #432761 with Sitecore Support and I will sure update this post once I hear back from them.
Customizing the metadata provider is in general a rather aggressive technique as it’s set globally. MVC 5, for example, uses a different provider by default – a cached implementation of the default provider. I am sure there was a good reason Microsoft changed it plus what if my solution has its own metadata provider?
An alternative implementation might try and avoid having to customize the model metadata provider altogether. I haven’t looked into whether WFFM could cope without it but I would definitely try.
Conflicts with Personalization
Sitecore.Forms.Mvc.config is patched in before Sitecore.Mvc.*.config and it breaks the order of processors in the mvc.getRenderer pipeline. As a result it accidentally gets in a way of certain personalization actions. You will be fine with the datasource personalization but you won’t see your rendering change if that’s what you’re doing. Read more here.
An alternative solution would probably just put the WFFM config patches into App_Include/Sitecore.Forms folder to ensure they’re not patched in too early. Maybe it was done in Sitecore 8, I haven’t yet looked at the latest and greatest WFFM.
Custom Renderer
The developers who built WFFM decided to use dependency injection for their controller rendering. They had to make it unobtrusive not to interfere with the surrounding Sitecore and the websites it’s running so they introduced a custom renderer that uses its own controller runner to inject the dependencies into the controller rendering using Simple Injector. The GetFormControllerRenderer picks the custom renderer based on the rendering item ID.
If you take a rendering of your own and point it to their controller rendering class it won’t work. You will also need to patch the GetFormControllerRenderer and make it recognize your rendering as a legit WFFM’s form component.
An alternative solution would either go by the controller class name or approach dependency injection a little differently. Rolling a custom renderer and a custom controller runner sounds a little too much. I would look at the controller factory instead. Here’s one example.
Heavy AJAX
You would probably expect that if your form is marked as AJAX it sends a JSON data to the server and receives instructions back. You would think it’s lightweight. It’s not. The AJAX will submit the form the same way the non-AJAX form does (back to the item and have the controller rendering handle it) and it will render the full page back. WFFM’s client-side JavaScript will then replace the form you have with whatever came back from the server – form with validation errors or a Thank You message, for example.
Not a gotcha per se but good to know.
Redirect with AJAX
As it was noted by Ryan Tuck you can’t use a redirect action with the AJAX form. I added some more details in my answer to his comment (see more below). The workaround is to use a traditional (non-AJAX) form if you want the form to redirect upon successful submission.
I filed #433414 with Sitecore Support (accepted as a defect) and here’s the workaround they suggested:
Modify ViewsFormEditorTemplatesFormModel.cshtml file and replace
if (Model.IsAjaxMvcForm)with
if (Model.IsAjaxMvcForm && !Model.SuccessRedirect)Dropout Tracking
If you enable dropout tracking WFFM will collect all form entries in the analytics database to later report on it. The collection actually happens regardless of this checkbox. You can see in you browser’s console on the Network Tab how the form is chatting with the server. The data won’t be saved unless the dropout options is ON but it travels down the wire anyway.
Again, not a gotcha per se but good to know.
[su_divider][/su_divider]
That’s it for today. I know I need to get back to my Product Details Pages series but I have one post I can’t wait to share. It will be about SPEAK pipelines and Experience Editor ribbon’s request in Sitecore 8. Interested? Stay tuned!
Hey guys,
Regarding the Heavy AJAX section, have you guys had issues with WFFM AJAX Forms where the success action is set to redirect?
As you have stated above, ‘WFFM’s client-side JavaScript will then replace the form you have with whatever came back from the server – form with validation errors or a Thank You message, for example’, when the Success action is set to redirect, the response returned appears to be the HTML of the page you chose to redirect to, which it then attempts to replace with the markup of the submitted form…
Due to time constraints we chose to change the form to not be AJAX, but if you have also encountered this, and found a resolution, that would be great to hear about 🙂
You’re right. Redirect doesn’t work with AJAX forms. I will add it to the list of gotchas and the reason is exactly as you described it. The form is POST-ed via AJAX back to the item. The server-side code in 2.4 and 2.5 (again, I haven’t looked at the version that comes with Sitecore 8) can’t tell AJAX from non-AJAX submission and it just runs its normal rendering. A redirect result will send a 302 upon successful submission. Browser transparently handles redirects so their
$.ajax()will eventually receive that other page and it won’t be able to do anything with it. It will appear as if nothing happened. Unfortunately you can’t patch it easily (stackoverflow is full of these questions – http://stackoverflow.com/questions/199099/how-to-manage-a-redirect-request-after-a-jquery-ajax-call, for example) as you ultimately need to change what WFFM sends back to the client to do the right thing there.The WFFM itself is a decent module. It’s the MVC rendering implementation that is somewhat lacking. We have submitted a number of issues to the Sitecore support and I also had them read my blog posts on WFFM so maybe we will see some of it fixed in the upcoming updates.