[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.
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.
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:
ViewsFormEditorTemplatesFormModel.cshtml file and replace
withif (Model.IsAjaxMvcForm &amp;amp;&amp;amp; !Model.SuccessRedirect)
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.
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!