I recently wrote a detailed post about all the config changes in Sitecore 9. I highly recommend taking a read if you have not done so already.
I suggested in that post that we could introduce custom configuration roles in order to allow us to configure specific settings for different environments, such as UAT or Pre-Prod for example. After a conversation with Alen Pelin he told me of a much better way to achieve this, which is both cleaner and semantically more correct.
I assumed there was something hardcoded in code to worked against specific AppSettings keys during the patching process. Turns out there is way more magic happening here than that – we can define whatever keys we want and follow a convention to have those applied. Looking at it again and with this additional info, it turns out this is exactly the same as how the configuration works to switch search providers.
I’d be very surprised if you were not using some sort of implementation of dynamic placeholders in your projects already. Most of us have probably been using a variant of Dynamic Placeholders that Nick Wesselman wrote way back in 2011, my personal favourite being Fortis Dynamic Placeholders by Jason Bert. This is also the most requested feature on the Sitecore Developer Uservoice and Sitecore Community Uservoice.
The wait if finally over. Sitecore 9 introduces support for dynamics placeholder implementation within the core product.
I’ve previously written several posts on Sitecore Configs. Well Sitecore 9 just landed so it time for a big update! This is not going to get your marketers all giddy but will certainly make all you developer and developers super happy.
Over the years the number of configs in Sitecore has grown and grown and grown. Then so did the number of folders. Sitecore has a new trick up it’s sleeve to clean this all up.
What’s new? Rules Based Configuration.
It’s a new configuration approach designed to drastically improve how server roles are configured and how all the config files are now organised, making it both easier to manage and deploy.
Sitecore 9 is here!
It seems like just the other day that 8.0 was released. Sitecore 9 has been released! The next major version also packs a lot of punches and a lot of new features, both in the core platform and updates to keep all the developers happy. It also sets the platform up for more extension points for the future.
As a Sitecore MVP we were given access to an early release to play with. Here is a summary of some of the exciting new features.
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.