Web Forms for Marketers 2.5 Upgrade

What a great time to be a part of Delphic – exciting new developments are in the books, and another year to look forward to awaits. Much of our success can be attributed to Sitecore, as it has given us so many things to be thankful for in 2014, but the one aspect I would like to focus on is Web Forms for Marketers 2.5.   

With the emergence of the xDB in Sitecore 7.5 came a flood of changes to the way Sitecore collects and reports on analytics data. One area of change was in Web Forms for Marketers, the designer module form that allows marketers to create and test both landing pages and  contact forms through Sitecore. The challenge I most recently experienced with this was upgrading a client’s solution from Sitecore 6.5 (and DMS) to Sitecore 7.5 (and the xDB), as well as an upgrade from Web Forms for Marketers 2.1 to Web Forms for Marketers 2.5.  After following Sitecore’s provided upgrade documentation, I came across some gaps in the process that I’d like to share with you:

1.  Disable your old forms.config file

Since we’re upgrading an older version of Web Forms for Marketers, the configuration file for that version will need to be disabled.  Some versions use the same configuration file as WFFM 2.5 – Sitecore.Forms.config, however, older versions look to a different file named forms.config.  There are conflicts with the pipeline processors in both the old and new configuration files, as well as database connection strings in the old configuration files that are not used in Web Forms for Marketers 2.5.

To Disable Your Old Web Forms For Marketers Configuration File…

  1. Look for the App_Config/Include/forms.config file.  If you have this file, rename it to forms.config.disabled.

  2. If you have the App_Config/Include/Sitecore.Forms.config file, replace it with the Sitecore.Forms.config file in the Web Forms For Marketers 2.5 upgrade package.

2. “Save” actions inheriting ISubmit don’t work

If you have a WFFM implementation like mine, you have a few custom “save” actions in your code library.  Each of these actions needs to inherit a base class called ISaveAction.  The previous version of Web Forms For Marketers used a base class called ISubmit, which does not work in WFFM 2.5.  Not only does it not work, but there are no errors found in the Sitecore error logs because of this.

To Update Your Web Forms For Marketers Save Action Base Class…

  1. For each custom save action class, change the inherited class to ISaveAction, and update the Execute method signature to include an params object array:
class ContactFormAdminEmail : ISaveAction
{
public virtual void Execute(ID formId, AdaptedResultList fields, params object[] data) { }
}

My only clue in realizing all of this was that my debugging breakpoint never reached the Execute method of my save action.  But after updating the base class, my save action worked perfectly.  Figuring this out required me to decompile the latest WFFM DLL to see the save action implementation – also known as a very big headache! With any luck, this step will save you from experiencing a similar headache.

3. The xDB collects form submissions when the user’s session ends

Now this particular process is the step that could really save some headaches. With previous versions of Web Forms for Marketers, there was a default save action called “Save To Database” that – you guessed it- would save the form submission to the Webforms MSSQL (or SQLite) database.  This would happen almost instantaneously after the user submitted a contact form, allowing their submission to be viewed and reported on in real-time.

The xDB is not only used for collecting analytics data, but also for collecting WFFM form submissions in the FormData collection of the Analytics MongoDB.  However, the form data is not collected while the user completes the WFFM form on your website.  Instead, the form submission gets added to the MongoDB when the user’s browser session ends.  As you can imagine, this is a much more difficult scenario to test against, and requires forcing browser sessions to end, or requires a great degree of patience by the tester. The first suggestion for testing this was to change the timeout parameter on the sessionState Element in the web.config file.

Shortening the Session Timeout…

Changing this value to a shorter time span, say two minutes or so, will allow a tester to complete a form and leave the browser inactive for those two minutes as opposed to the typical 15-20 minutes. Once the browser session ends, the form submission is collected in the xDB, prompting the form submission to appear in the Form Reports tool in Sitecore.

timeout="2">



Forcing the Browser Session to End…

A two minute session timeout is much too short for a live website, so this configuration change isn’t conducive for production environments. Forcing a browser session to end can be done with an IIS reset, but that also won’t work for production environments for obvious reasons.  Instead, you can add a custom pipeline processor to abandon the session and trigger that code using a querystring parameter.

To do this, you’ll need to make a pipeline processor, which will clear two browser cookies and your ASP.NET session if there is a specific querystring parameter.

public class ForceNewAnalyticsSession
{   public void Process(PipelineArgs args)
  {     if (HttpContext.Current.Request.Cookies["SC_ANALYTICS_GLOBAL_COOKIE"] != null)
    {
      if (!string.IsNullOrEmpty(HttpContext.Current.Request.Cookies["SC_ANALYTICS_GLOBAL_COOKIE"].Value) && QueryStringHelperFunctions.GetQueryStringBool(HttpContext.Current.Request.QueryString, "forcenewvisitor", false))       {
        HttpContext.Current.Response.Cookies["SC_ANALYTICS_GLOBAL_COOKIE"].Value = "";
        HttpContext.Current.Response.Cookies["SC_ANALYTICS_SESSION_COOKIE"].Value = "";  
        HttpContext.Current.Session.Abandon();  
        HttpContext.Current.Request.Cookies.Remove("ASP.NET_SessionId");    
        HttpContext.Current.Response.Cookies.Add(new HttpCookie("ASP.NET_SessionId", string.Empty));
      }     }
    if (HttpContext.Current.Request.Cookies["SC_ANALYTICS_SESSION_COOKIE"] != null)     {
      if (!string.IsNullOrEmpty(HttpContext.Current.Request.Cookies["SC_ANALYTICS_SESSION_COOKIE"].Value) && QueryStringHelperFunctions.GetQueryStringBool(HttpContext.Current.Request.QueryString, "forcenewvisit", false))
      {
        HttpContext.C urrent.Response.Cookies["SC_ANALYTICS_SESSION_COOKIE"].Value = "";
        HttpContext.Current.Session.Abandon();
        HttpContext.Current.Request.Cookies.Remove("ASP.NET_SessionId");
        HttpContext.Current.Response.Cookies.Add(new HttpCookie("ASP.NET_SessionId", string.Empty));       }
    }   } }

Once you have your pipeline class written, you’ll need to insert it into the pipeline. You can do this using an Include configuration file, which inserts the pipeline processor just after the InitializeTracker.Initialize function in the Sitecore.Analytics.config file:


  
    
      
               
    
  

Now that the processor is in place, we can use the querystring parameter “forcenewvisitor=true” after submitting a WFFM contact form to clear the browser session, triggering the form data to then be saved.

This pipeline processor, along with my other tidbits about the inner workings of Web Forms for Marketers, should be very helpful in accurately and efficiently testing new forms and functionality. If you’re encountering other issues with your new Web Forms for Marketers 2.5 implementation, leave a comment below and our on-staff geniuses will take a look!

« Prev Article
Next Article »