Since 7.5, Sitecore introduced Media Request Protection that is essentially a hash added to some URL’s. Some people find this annoying, but I think this was a good move. If someone would just hammer your site by downloading media images with random width and height parameters, it would cause a lot of image resizing and consequently eat up all CPU.

The idea behind the Media Request Protection is to avoid these kind of denial of service attacks, by having a hash parameter on the URL. On an incoming media request, Sitecore calculates the hash of the request query string parameters and compares it with the given hash. If they are equal, Sitecore performs the resizing options (or whatever parameters are provided). If they are not equal, Sitecore will just send the original file as-is.
Continue reading →

Serving optimized images on websites is essential to get high performances website and get a good user experience. There are numerous implementations of this and here is yet another one. Inspired by Anders Laub previous posts on cropping and compressing images, I decided to make one that makes optimized progressive images.

Normal images are loaded from top to bottom, aka baseline images. The advantage of progressive images is that the entire image is shown almost right away, but the image is blurry at first when only a portion of the image is loaded and the image then becomes clearer as more image data is loaded in the browser. This makes the perceived load speed faster to the viewer.
Continue reading →

There are always room for improvements of the Experience Editor. Here are a few simple ones to fix.

Since Sitecore 8.1, field validation results are shown inline in text fields. This is quite useful for content editors, both for showing errors, but also to give soft errors, such as warnings or suggestions.

One can argue that all non-valid results from validators are errors, but I think it makes more sens to say “Show suggestion” instead of “Show error” next to a validation suggestion.
Continue reading →

This post is about extending Sitecore to simplify reuse of content. It’s nothing new and has been done many times before. This is just my take on a common scenario. The solution is only tested on Sitecore 8.0 & 8.1, but will probably work on older versions as well. There are many usages for this extensions, but I’ll first try to explain the requirement I had and why this extension was needed.
Continue reading →

When you schedule an item in Sitecore, it doesn’t mean that the item gets published or unpublished at that date. It just means that it is possible to publish the item within the given period. One have to perform an actual publish for it to actually happen.

There are many great modules already that handles this, such as Scheduled Publish Module for Sitecore by Hedgehog.

In my scenario, we just wanted to trigger a publish for items as they are scheduled. Scanning through the whole database is very expensive though, so I decided to make one that utilizes our search index instead. We use Solr in our solution, but it’ll probably work as good with Lucene as well.
Continue reading →

There are different approaches that can be taken when managing multi-lingual web sites in Sitecore. Sometimes your authors might have to manage content in multiple languages and the might need to switch between site trees that are built on different languages.

Updated 26 September 2016: The OpenExperienceEditor command needs to be replaced in order to make this work properly. Code for that added below.

In that scenario, editor often faces the message that there is no version on the current language, and they have to find the right one in a long list of languages. This isn’t very convenient. Using the new Experience Editor it’s even worse, because authors are not given this information at all, so they might start editing a page in the wrong language by mistake.

I wanted to make this easier for the authors, so I decided to change the built-in Content Editor warning, and add an equivalent function to the Experience Editor.
Continue reading →

There has been many posts about unlocking Sitecore items, and here’s yet another one that perhaps fits your needs.

In one of our projects, we decided that users that are not logged into Sitecore, doesn’t need to retain locks on any items, so we wanted a solution where Sitecore automatically releases all item locks where the user doesn’t have an active session.
Continue reading →

Thank you Sitecore for awarding me “Technology Most Valuable Professional (MVP)” again! Fourth year in a row! This year, Sitecore has designated 177 Technology MVPs, 35 Digital Strategist MVPs, and nine Commerce MVPs, which brings the total group to more than 200 spread across 25 countries worldwide.
Continue reading →

In Sitecore 8.1 we finally got language fallback built into the core product. This gives us the option to specify, per field, if we want to inherit a field value from another language when the field itself is null.

I guess we all have some sort of love and hate relation to the built in Display Name field of Sitecore. It solves a lot of potential issues, but it causes tons of other problems as well. With language fallback, there is another one. If you enable language fallback on the Display Name item, nothing happens. This is because the default LanguageFallbackFieldValuesProvider ignores all standard fields. Well, all fields starting with a double underscore to be exact.

So in order to have language fallback on Display Name or any other standard field (though the need for it on other fields are probably very rare), we’ll have to replace the default implementation, with an overridden version where the bool IsValidForFallback(Field field) method doesn’t return false just because its internal name is "__Display Name".

If you need details on how to replace the default implementation, look at my post about editor friendly language fallback.

After upgrading some of our solutions to Sitecore 8.1 update-1 we started seeing errors in our log files, such as this:

... ERROR Error in FileWatcher. Internal buffer overflow.
Exception: System.IO.InternalBufferOverflowException
Message: Too many changes at once in directory:path-to-data-dir\Data.
Continue reading →

Language fallback is really nice when working multi lingual websites. It save a lot of time and makes the solution very flexible. However, among content editors it can cause some headaches since the content shown to editors may not be the actual content being published.
Continue reading →

If you’ve spent some time with Sitecore 8.x, you’ve probably experienced the tremendously slow SPEAK driven Experience Editor (formerly known as Page Editor). This is due to multiple problems. The design of SPEAK is really chatty and cache is vital, some XHR requests are really slow and some are caused by heavy precompilations.
Continue reading →

Today, my colleagues stumbled upon a strange behavior in one of our projects. I won’t go into all the details about it, but it let me think about how Sitecore indexes fields and how it can be improved. We use Solr, so at this stage, I don’t know if this applies to Lucene as well, but I guess it does.

We typically auto generate our domain model from a TDS project using a T4 template. Having that, we can easily map all Sitecore template fields to typed properties in our domain model and we can also map those to the fields in a Solr index. This means we can use the same model when using the ContentSearch API as well as with the traditional API. We can also lazy load fields from the original item if they are not marked as stored in the index.
Continue reading →

This post describes a concept of resolving content during publish in Sitecore 8.1, but most of it will apply to older versions as well.

With Sitecore 8.1 we get language fallback out of the box. Previously we’ve had the Partial Language Fallback module written by Alex Shyba. The new built-in one is a rewritten one.
Continue reading →

With the new version 8.1 of Sitecore we get a some really nice new features that’s been talked about a lot over the last few weeks. In this post I’d like to highlight one of the minor changes that I think is well worth spreading as well, since it makes life a bit easier for us developers.
Continue reading →

At yesterdays Nordic Sitecore Conference, I was asked about how we deal with clone notifications in Sitecore. So here I’ll try to do a brief blog post of my thoughts on this and how we’ve solved it. It may be gaps in here and room for improvements, but perhaps it’s a start to get your solution work well in this area.
Continue reading →

Home again after a long Nordic Sitecore Conference day at Sankt Gertrud in Malmö, Sweden. A fully packed day with great topics, speakers and a few minutes of networking in between the sessions.
Continue reading →

In Sitecore, we build pages adding renderings to a page. Renderings typically have datasources pointing to items carrying the content. Thereby it’s really easy to reuse content. In a scenario where a piece of content is used on multiple pages, it’s maybe not clear to content author that changes to the content will actually affect more pages.

So I wrote a little indicator that will show a warning indicator in the Sitecore Experience Editor (aka Page Editor) when the content of a rendering is being used on other pages as well.
Continue reading →

Today I faced a Sitecore website rollout problem I’ve never thought of before. When doing a multi language/multi market solution, it’s common to use cloning or other kinds of fallback techniques. This is typically very good, but sometimes it brings some new problems as well.

The scenario I faced was that I wanted to make sure that certain fields did not inherit any value from standard values, default values or via cloning. In my particular case, I wanted to ensure that certain integration settings where defined for each website, even if the sites were cloned. Maybe not a very common requirement, but here’s another example:

Let’s say you have a field that stores a Google Analytics UA code, maybe that code should be defined on each locations where it’s used. Not inherited between sites. (Depending on how you’ve configured GA of course.)
Continue reading →

Update: As of version 5.7.0.8, released on October 24, 2017, this setting is now default in Team Development for Sitecore Classic. If you upgrade to this version, you may have to hit “Reset” on the ignore fields list. Thank you Charles Turano!

After a fresh install of my whole dev environment onto a new nice machine, I realised that Hedgehog Team Development for Sitecore (TDS) isn’t by default configured the way I like it.

In the Options window in Visual Studio, there is a section for TDS Options. In the Sync Window you can specify a set of field names that the Sync with Sitecore should ignore when comparing Sitecore items with your project items. By default, TDS ignores “__Created by“, “__Owner“, “__Revision“, “__Updated” and “__Updated by” which makes perfectly sense. Essentially, this means that if you open an item in Sitecore and just hit Save, some of those fields will be changed but nothing else. Therefore is no meaning in synchronising those items with you project, unless other fields are changed as well.

For some reason the “__Created” field isn’t there by default and I guess one could argue that it should be, but I found it better to ignore that field as well. The main reason for that is as projects evolve, we may upgrade Sitecore to a newer version or a new team member may join that hasn’t followed the same upgrade path as the rest of the team. Instead (s)he just installs the current version used by everyone else in the team. In this case, Sitecore items will have new Created dates and therefore a whole bunch of items are marked as different from the ones you have in the project.

TL;DR In Visual Studio, open Options, navigate to TDS Options and add “__Created” in the Sync window.