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