Don’t forget this when upgrading to SC9

For one of our clients we have been upgrading the Sitecore environment from 8.1 (rev. 160519) to 9.0.1 (rev. 171219). The upgrade process was doable after reading the upgrade documentation thoroughly, and just like every upgrade there are some things to look out for when upgrading your solution.

Dynamic Placeholders

Dynamic placeholders are now integrated with Sitecore and we don’t need to install extra modules anymore to make use of them. You can easily remove the reference to the old dynamic placeholder module (remove assemblies and config) and start using the Sitecore ones by just using the Sitecore Html helper and rendering a placeholder just like that. One thing to keep in mind is that the functionality is extended, and it’s now possible to render multiple placeholders by adding an integer value to the placeholder key itself: row_{FDDF4C6C-C1B8-5C6D-2B41-DB83D241634C}-2

This example will render a row placeholder with x instances of that row which can be used to nest other renderings in. Pretty handy when you need to setup a page template with 5 rows, as you don’t have to add 5 row to the page by hand. When upgrading your instance this however can be an issue if you are already using dynamic placeholders. The new format as described above is a little different then the older format. More details about this can be found here. The powershell script that is provided can be used to transform everything to the new format, but make sure that any customizations done to either the rendering of a dynamic placeholder or overall rendering of renderings to the page might need some little tweaks to the powershell script. In our case we had created a custom way of rendering a navigation element, so running this powershell would get us into trouble. Therefor we created our own script, which was suitable for this particular case.

Configs files rearranged

Sitecore has done something great again, the config files have been rearranged and are structured in a much more logical way then before. This has multiple reasons. It’s very much easy to find the relation between the functionality Sitecore offers and the folder structure in the app_config folder. For example ‘Launchpad’ now has it’s own folder, so all processors and pipelines related to the launchpad are now residing together in one folder. Offcourse only changing the way configuration files are stored doesn’t automatically mean that all configuration that can be done to an element are now done on one place as this also depends on having everything patched and sorted out in the right way, but it’s clear that Sitecore is going for a much more module / functionality based approach. The more you have already chosen for a config patching approach when customizing Sitecore, the easier it is to adept to this new way of storing the configuration by Sitecore. When merging and setting up while upgrading you will notice that some of the somewhat bigger configuration files might have been split up in 3 or more new different configuration files. Just make sure to use the right merge tools and understand the new structure before starting the merge.


In the past Sitecore has been forcing us to make use of MongoDB for the saving of our xPerience data (interactions, contacts, devices etc.) but with the feedback they got from the community a new approach has been  taken. In Sitecore 9 and with the first update there is no provider implemented for saving xPerience through MongoDB. This is a rather fundamental change and might cause some issues for the ones that have embraced MongoDB (like us). The reason being that Sitecore doesn’t support MongoDB for xPerience data yet, but seems to already ship the newer MongoDB drivers with a clean Sitecore 9 install. Therefor if you are using MongoDB in you application to for example store some of your application’s data you will have to upgrade to the newer MongoDB drivers, to already prevent any mismatches in the comming release of Sitecore 9 that will support MongoDB again.

Queryable datasource

Queryable datasources can be used to make sure that datasources that can be chosen for renderings can be queried from a certain context. For example:
I am placing a rendering on a website and I want the content to be chosen from a shared content folder under that particular website, so I create the following queryable datasource: ancestor-or-self::*[@@templatename=’Website’]/Shared Content/Content/*

This query will make sure that content can be picked from the ‘Content’ folder that resides under the Shared content folder of the website we are creating a new rendering on. This is cool, cause this allows us to have 1 rendering defenition that will be able to be used on more then just 1 website, and we don’t have to bother our content editors with the choice of which shared content folder the content should be picked from (as the queryable datasource will make that choice).

We ourselves found this way of working really cool and actually extended Sitecore to also be able to work with Queryable datasources in the actual datasource of a rendering itself. This means that we have the option to give our content editors the freedom of choosing content, but we can also create standard versions of pages that will have predefined renderings on the page that have queryable datasources prefilled.

For example: I have 5 footer blocks that I want to setup on standard values of the ‘Content’ page template. Every time a page gets created those blocks should be on the page. I have a multisite setup, so I cannot set the content of this footer blocks to one particular datasource as this would cause the links in that footerblock to always point to one website and I want the foolterblocks to be specific to the website itself. Instead of just creating the blocks with a set datasource i create a query like this:


Now when this rendering is added to the page it will look for the FooterBlock1 item under the shared content folder of the current website. We created our own MVC Controller base class that will deal with this and has a method implemented that will retrieve the datasource item:

Cool things, but in Sitecore 9 the way a datasource gets validated might cause the rendering from being displayed! In the  Sitecore.Mvc.ExperienceEditor.Pipelines.Response.RenderRendering.AddWrapper class a datasource validator is validating all the datasources. If a datasource was not validated correctly this AddWrapper class will abort the pipeline and give the following warning ‘”‘{0}’ is not valid datasource for {1} or user does not have permissions to access.” We solved this by using the AddWrapper as a base class in a new processed that we patch instead of the AddWrapper class and introduced our own Datasource validator based on the interface ‘IDatasourceValidator’.


AddWrapper method:

Datasource validator:

This made sure that renderings would be rendered even if the datasource was invalid according to Sitecore, but was valid according to our own customization (using the query: prefix on a datasource in a rendering)

Core database

We had some issues with the core database after upgrading to Sitecore 9. This may have several causes, for example a not well performed SQL script that should be run in one of the upgrade steps. For now we have just solved this the most easy way by just placing a new Sitecore 9 Core database and migrating any customizations we have done by creating Sitecore packages between the old (Sitecore 8.1) core and the new Sitecore 9 database. Offcourse this is not enough, as also users / roles and some other key things should be taken into account when migrating data from the core database, but for now this was the simple way to get ourselves ready to start fixxing the really important issues like code breaking changes and missing renderings.

Well, this concludes it all for now, I hope there are some things that will eventually help out other people that come along any of the issues described above, and I wish you all happy Sitecore-ing!








Why is my time not displaying correct after upgrading to 8.1?

I upgraded one of our Sitecore solutions from Sitecore 6.2 (rev. 100507) to Sitecore 8.1 (rev. 151207). After the upgrade we noticed that the display of time on the website was slightly off. Instead of showing the GMT + 1 time it showed the UTC time (which is 2 hours off in our case). This caused that all newly created items (wheter it be reactions on news or news items itself) showed the wrong time. An item created on 11-04-2016 – 11:04 would be shown as 11-04-2016 – 09:04. As you might guess this wasn’t really what our customer was looking for and I haven’t stumpled upon any tips regarding this issue in the upgrade guide while upgrading the solution.

Now I have decompiled the Sitecore.Kernel and read some other posts regarding this issue I would like to share my solution to this problem. As per Sitecore documentation provided in the Sitecore.config file I looked for the Timezone I would like to use on msdn:

MSDN Article – Timezones

In my case I chose to use the “W. Europe Standard Time” so my settting in the sitecore.config file looked like this:

Now this seems all nice and ready to roll, but you aren’t done yet. If you are using for example “Sitecore.Statistics.Created” as your DateTime object and just format this date and .toString() it in any format with a time specification you will not yet see the correct time displayed. I therefor used the Sitecore.DateUtil.ToServerTime() method, which uses the ServerTimeZone setting we just specified to convert between the UTC and server time.

This results in the right date / time being shown on your website.

Hope you will find this article useful!


Lucene MaxClauseCount error after upgrading to Sitecore 7.2 (rev. 140228)

After upgrading your solution from an early release of Sitecore 7 (ie. 7.0 / 7.1) you might get the following error:

Message: maxClauseCount is set to 1024
Source: Lucene.Net
bij Lucene.Net.Search.BooleanQuery.Add(BooleanClause clause)
bijLucene.Net.Search.MultiTermQuery.ScoringBooleanQueryRewrite.Rewrite(IndexReaderreader, MultiTermQuery query)
bij Lucene.Net.Search.Spans.SpanFirstQuery.Rewrite(IndexReader reader)
bij Lucene.Net.Search.BooleanQuery.Rewrite(IndexReader reader)
bij Lucene.Net.Search.BooleanQuery.Rewrite(IndexReader reader)
bij Lucene.Net.Search.IndexSearcher.Rewrite(Query original)

You can’t solve this by adjusting the setting:

in your Sitecore.ContentSearch.Lucene.DefaultIndexConfiguration.config file, but by adding the following lines of code to your SaerchProvider:

Somehow adjusting the setting in your config file won’t have any effect.