One of our Sitecore implementations was experiencing WFFM exceptions when trying to send emails from CD servers. This post about WFFM configuration over on the Community site for Sitecore ends with a vague answer to fix a scenario such as this via the following:
Please remove the below mentioned setting from “Sitecore.Forms.Config” from all CD instance.
<setting name=”WFM.IsRemoteActions” value=”true” />
we have also added this setting as per sitecore documents but after adding this line on CD instance, mail won’t trigger. You have to remove this setting from “Sitecore.Forms.Config”. Making value as “false” won’t fix the issue.
Unfortunately, this is a fairly common scenario on that Community site . . . there are certainly answers tucked away in there if you’re diligent in your research, but sometimes they can leave you with more questions. I think the new StackExchange site for Sitecore is a breath of fresh air on this front, but for this specific question about WFFM I was left to puzzle over this WFM.IsRemoteActions setting. Here’s what I uncovered.
The official Sitecore documentation for setting up WFFM explicitly states (on page 6 of the WFFM 8.1 Update-3 installation guide in our case, but it’s mostly the same for other versions):
In the \Website\App_Config\Include\Sitecore.Forms.Config file,
- Add the following node to the section:
- <settings> section: <setting name=”WFM.IsRemoteActions” value=”true” />
The section: <!--HOOKS--> <hooks> <!--remote events hook--> <hook type="Sitecore.Form.Core.WffmActionHook, Sitecore.Forms.Core"/> </hooks> The section: The <events> section: <!--Remote events handler--> <event name="wffm:action:remote"> <handler type="Sitecore.Form.Core.WffmActionHandler, Sitecore.Forms.Core" method="OnWffmActionEventFired" /> </event>
By removing (or setting to false) this WFM.IsRemoteActions setting we’re asking less of our Sitecore CD servers and centralizing the WFFM save behaviour to the CM server. Most Sitecore implementations are eager to find ways to reduce the demands on the CD nodes in an implementation, so this measure could be considered a best-practice if you’re using WFFM and looking to save Sitecore CD cycles (CPU!) for responding to HTTP requests for site visitors instead of performing WFFM post save actions. To me, it looks like you could take this further and delegate this responsibility to a “processing” server if you’ve got one in your scaled Sitecore architecture . . . or any node that suits you.