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.
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.
Following a question on Stackoverflow about filtering the css classes shown in the Rich Text Editor control, I thought I would share some simple code which is useful in various scenarios.
The RTE control used in Sitecore is Telerik RadEditor. The implementation is very flexible, and a lot of the configuration can be changed by changing the profile in the
core database under
/sitecore/system/Settings/Html Editor Profiles. You can easily switch the profile used on a per field basis by setting the source on the field definition:
I’ve been using this Site Specific Link Provider for a while now and have been meaning to blog it for some time, a couple of recent blog posts from John West and the addition of the new LinkProviderSwitcher to Sitecore 8 about prompted me to finally get my thoughts onto keyboard. When I read that a new LinkProviderSwitcher had been provided I got a bit excited that we may finally have site specific link provider, alas it was just a way of allowing us to switch the provider inside a using block.
Some of you may be aware that Sitecore has allowed us to define multiple Link Providers for some time, we just add multiple
providers to the
linkManager config section, but it hasn’t really provided us a nice way of utilizing that functionality without hard-coding it:
About a year or so ago I was working on a project which involved an upgrade from Sitecore 6.4 to 7.0 (the latest version at the time). The upgrade was fairly incidental, the site was (kind of) “working fine” in production. The main reason for touching the codebase was to fix issues due to a poor implementation that was carried out initially, namely:
- Lack of Page Editor support
- Poor coding not following Sitecore Best Practices
- Sitecore section in Web.config modified directly (which made upgrading more difficult)
- Poorly structured Content Tree
- Difficulty applying a good security model for multi-site, multi-editor environment
…amongst others. It wasn’t all bad, just some common mistakes made by developers struggling with Sitecore during a first implementation.
One issue was the poorly structured content tree. It seems there was struggle with getting a handle on how to structure content whilst trying to use that same structure to create the navigation menu on the site. They had the usual “Include In Navigation Menu” checkboxes but the navigation structure did not actually completely match the content structure.
There have been a number posts about using Sitecore with a CDN provider and there is even a Sitecore CDN Connector module available Marketplace. Although the benefits of using a CDN provider are fairly well stated, such as reducing load on your server and allowing distributed datacentres, Sitecore itself does a pretty good job with its Media Library and for the vast majority of projects using a CDN may be overkill. Bedsides, there have been various projects I’ve worked on where they did not want the additional expense for little benefit or were unable to use a CDN to due to company policy or project requirements/specifications.
A project I was recently working on was utilising Edge Caching services from Akamai. If you’ve never used this type of service before, you need to re-route requests to your site to Akamai (by changing the DNS entry to point there). You can then configure Akamai as to which type of content should be served from cache and which needs to be forwarded on to your own server. There is nothing else for you to change, i.e. you do not need to provide a different domain prefix for your media items. This was an existing setup to the project from a previous vendor and seemed to work pretty well to meet the clients needs. One of the benefits we lose from not having a different domain name is the ability to domain shard.
tl;dr Use the Sitecore Configuration Factory to pass parameters to enable Pipelines to only run for specific sites
I’ve been working on a few multi-site Sitecore implementations lately and the majority of the time most brands within the same company umbrella all want similar functionality, which is very nice and easy for us developers. But as you start to work on larger implementations with different brands it will be inevitable that they all have slightly different requirements.
Pipelines provide us a great way to customize Sitecore, but they run for all requests unless we put in some hacky code:
public override void Process(HttpRequestArgs args)
if (!Sitecore.Context.Site.Name.Equals("mysite1") || !Sitecore.Context.Site.Name.Equals("mysite2"))
// run your site specific code