One of the most useful custom WFFM fields we use is a custom hidden token field. I’ve used this on several projects for various reasons.
<input type="text" name="firstname" placeholder="First Name">
So very useful to provide hints for the type of format the field is expecting, such as email addresses or telephone number formats.
WFFM does provide this functionality out-of-the-box, although it’s not something we have found useful due to the implemenation, so we opt for a custom field instead.
Hopefully a very simple one, however unfortunately it is not possible to add snippets of text in the forms, only to the header/footer or section titles. We often have to provide additional details which may also include HTML links/content.
We solved this problem by creating a custom Label field. There is not suitable existing field to inherit and extend, but it’s such a simple field we can inherit from the
CssClassControl field as a base.
A common field requirement seems to be a checkbox which also allows some HTML text, such as when including a checkbox that the user agrees to some Terms & Conditions, Privacy or Legal policy. It’s usually a requirement that links to the policies are provided within the text.
There’s nothing out-of-the-box with WFFM but it’s simple enough to create a custom field.
This is a re-post of an answer I provided on Sitecore StackExchange.
If you are using the MVC version of the WFFM module then you probably know that by default the templates for the fields are located under
/Views/Form/EditorTemplates folder. If you have a multisite implementation then this leads to an issue if you need to render different markup for different sites. Generally speaking, my recommendation has always been to try style around the default WFFM markup rather than bending it to your will only to be struck down later when upgrading, but we should try to follow this same advice for most of Sitecore whenever possible anyway.
But sometimes you really really need something different per site.
With the release of Sitecore 8.1 we have had the added benefit of being able to use MVC Areas. We can take advantage of this feature to allow different markup for forms per site.
There were a number of changes in the 8.1 release of the Web Forms For Marketers module, it was a fairly significant rewrite but not unusual given the introduction of a number of abstractions within the core product itself. In hindsight, all this was just setting the stage for the introduction of Dependency Injection in Sitecore 8.2.
One of the big changes in WFFM now allows us to inject dependencies into Save Actions using configuration. I’ve not seen this blogged previously and the documentation is a little sparse on this subject so thought it is worth reviewing since it has also come up on StackExchange before.
I previously blogged about a Switching Link Provider for Sitecore, allowing you use a different LinkProvider for different sites.
There were a number of changes in Sitecore 8.2 to LinkManager/Provider as a result of the Dependency Injection changes, unfortunately one of them being the
Providers collection being marked
[Obsolete]. The code in the old post should still work, but you’ll get that annoying warning.
The previous code worked by creating a Link Provider which acted as a switcher that in turn called a different Provider. This was a hack because we could not switch out the Link Manager itself. Well the DI changes in Sitecore 8.2 allow us to do that instead and provide our own implementation of LinkManager instead.
The legend that is John West, a.k.a. SitecoreJohn.
Following the move of the blog posts from the old site to the Community Site last year things have not been quite right. Luckily John West had an archive of the code samples, so I’ve put them all on Github:
I’ve uploaded both the protoype code samples and compressed archives, hopefully this will make it easier to quickly view the code rather than having to download/extract the zip files like before!
You might also be looking for these handy gems:
Thank you John West for providing the archive of the code samples!
A few weeks ago on Sitecore Slack chat, fellow MVP Neil Shack discovered a tucked away setting in the
renderField pipeline. Enabling this causes the field name to be rendered in the default placeholder text in Experience Editor mode:
tl;dr; Custom HTML Helper to wrap Glass Edit Frame and JS code to immediately open the modal dialog for editing
As I’m sure most of you are aware, I 😍 Glass Mapper. So much so that I struggle with the native Sitecore API 😂
Version 4 of the framework added an amazing feature which allows you to very simply and quickly create/bind to Edit Frames purely from code. Normally this is a bit of an annoying and long winded processing: switch over to the core database, create an item with names of the fields, serialize/sync to source control, do this for every combination of fields you have, hook it up to EditFrame code that until recently did not work in native Sitecore MVC 😆
I’m sure you’ve been using this feature, it’s super simple from code to add an EditFrame wherever you need and the best part is it’s bound against your strongly typed model:
@using (BeginEditFrame(Model.Page, "Edit Metadata", x => x.DisplayInMenu, x => x.Closed))
<div>Let's add an Edit Frame around our rendering</div>
If you need to add another field then simply add it to the list of fields and Glass handles everything for you.