Lately I have noticed a lot of the following exceptions in our client’s Sitecore log:
Message: The operation has timed out
This started to happen as our dedicated processing server is going through a few months of data as it was not running properly for a while.
I have spent some time trying to tweak the Solr server’s parameters such as the request time out without seeing any improvement in regards to the number of logged time out exceptions.
Eventually I approached Sitecore support and they told me that this is a known bug in Sitecore 8.1 which has been fixed for 8.2.
If you are running 8.1 same as us and you experience this problems, I recommend you reach out to Sitecore support as they have a patch for each of their support DI containers which will allow you to configure the Solr time out in the settings.
I hope this helps others to save the time investigating this issue.
In essence Andy Cohen has already described the solution to overcome the MongoCommandException in one of his blog posts.
However, when I connected to my Mongo database hosted with mLab and attempted to run the db.grantRolesToUser command I got an exception that my user was not authorized on my database to execute the command.
If you experience the same issue the following steps might help you to overcome it:
- On your admin database add a new admin user
- Use command prompt to login to admin database using the newly created admin user
- Switch to your analytics database
- Run db.grantRolesToUser command
Unfortunately, Sitecore does not support queries in the Data Source field for renderings out-of-the-box but I have found a blog that describes how a pipeline processor can be created to enable queries. However, the blog post is limited to WebForms implementations so I spent a bit of time making this feature available for all MVC friends out there.
All we need is a RenderRenderingProcessor:
public class QueryableDatasourceProcessor : RenderRenderingProcessor
public override void Process(RenderRenderingArgs args)
string dataSource = args.Rendering.DataSource;
string query = dataSource.Substring("query:".Length);
Item queryItem = args.PageContext.Item.Axes.SelectSingleItem(query);
if (queryItem != null)
args.Rendering.DataSource = queryItem.Paths.FullPath;
Following best practises we create a patch file for the configuration change:
<processor patch:before="*[@type='Sitecore.Mvc.Pipelines.Response.RenderRendering.ExecuteRenderer, Sitecore.Mvc']"
Now we can use Sitecore queries in the Data Source field:
In the second part of this series of blog posts I will describe what is required to deploy a Sitecore solution into the content editing environment using Visual Studio and how it can be setup.
The following steps will be executed when the Publish option from the Visual Studio Azure Cloud Service project is invoked:
- Compile source code using the ContentEditing build configuration
- Transform configuration files
e.g. web.config, connectionStrings.config…
- Extract archive of Sitecore 7.2 site root’s Website folder into web application temporary publishing folder
- Publish web application to temporary publishing folder
- Create Azure deployment package
- Upload Azure deployment package
- Deploy package
Since the Sitecore folder in the Website folder only contains Sitecore content editing related files that should not be changed I recommend to exclude this folder from being packaged and uploaded with each and every deployment package. The Sitecore folder alone is over 130 MB zipped and slows down the deployment process considerably. Instead the deployment setup below suggests to upload a zipped archive to the blob storage and extract that archive on role startup into the application folder on each web role.
Continue reading “Sitecore Azure deployment using Visual Studio Cloud Service project – Part 2”
This series of blog posts is going to describe a way how Sitecore 7.2 rev. 140526 (it most likely works with other versions as well but I haven’t tested it) can be deployed using Visual Studio and the Windows Azure integration. The big advantage that you will get from this is that the deployment can be automated using PowerShell scripts should you choose to setup continuous deployment using a build server such as TFS (yes I am biased, I like TFS). So the aim is not having to use the Sitecore Azure module for your cloud deployments.
Why am I not very fond of the Sitecore Azure module?
- The module is a black box, it’s not clear what it does under the hoods
- The module doesn’t allow automation
- It’s tedious to trouble shoot if something goes wrong
- To my understanding, the module doesn’t allow to include extra roles (e.g. worker roles) as part of the deployment
I am sure I could come up with more but I think you get the point. 🙂
This first blog post is concentrating on deploying the Sitecore databases to Windows Azure. If you have used the Sitecore Azure module you may have noticed that this is the starting point. Given that the content of this blog is only required once I decided that it won’t be worthwhile to automate the steps described.
Continue reading “Sitecore Azure deployment using Visual Studio Cloud Service project – Part 1”
Following my previous blog post here are the settings required to make the two new Australian data centers available in the Sitecore Azure module:
<datacenter name="Australia East">
<coordinates left="87%" top="84%" />
<datacenter name="Australia Southeast">
<coordinates left="85%" top="87%" />
Recently a couple of new data centers have become available to host your cloud based applications using Windows Azure.
The Sitecore Azure deployment module has been implemented in a flexible way so that the module doesn’t need to be updated when a new Azure region becomes available. If you want to add a new region simply open the App_Config/AzureVendors sub folder under your Sitecore website root and edit the Microsoft.xml file:
- Navigate to the
- Add new
<datacenter> nodes for each additional region
The name of the node needs to exactly match the region name which can be found here:
Windows Azure Regions
- Save the file and re-open the Sitecore Azure dialog from the Sitecore desktop.
When I first started to look at hosting Sitecore on Windows Azure using the module provided by Sitecore I noticed that the default setup is using in-role caching. This means that a portion of your web role’s memory will be dedicated to caching and cannot be used to serve web requests. Some people might say ‘no problem’ I just scale out if I have the need to handle more requests. In essence that’s true, but based on your solutions’ needs this could come at a cost. Hence I was wondering whether there were any alternative options available within Windows Azure.
Windows Azure offers various caching options:
- In-role Cache
- Managed Cache Service
- Azure Redis Cache
Option 2 and 3 are Services that allow you to take caching off your web roles which might be cost beneficial depending on your requirements. Using a dedicated caching service is sometimes cheaper and could work better in terms of scalability.
In this blog post I am going to describe how Azure Redis Cache can be configured in Sitecore but the same way you could use the Managed Cache Service.
Configure a new Redis cache in Windows Azure
I have chosen the Standard tier that comes with 1GB and replication. Based on your needs and the number of items that you have in your Sitecore solution you might want to consider another plan.
Continue reading “Leverage Azure Cache Services with Sitecore”
Sitecore out-of-the-box does not come with a feature built-in that would allow you to setup bi-directional relationship between items. Hence, I have decided to write my own solution and share it with the community.
John has done a great job describing the various ways how item updates can be intercepted in the following post.
The two options that I identified as the most viable were either write a custom Sitecore handler for the OnItemSaved event (option 1) or write a rule (option 4). The advantages for the rule mentioned by John convinced me that this would be the best option. Here are some of the reasons summarised:
- Control logic and parameters through UI from content authoring environment
- Separation of concerns: Rule condition under which the rule runs is part of the configuration
- Rule only executes on the database that it is configured
Continue reading “Bi-directional one-to-many and many-to-many relationships in Sitecore”
This is the second part of a blog series talking about enabling dynamic content place holders with meaningful names using MVC.
Let’s see how we can bring the page editor to life with what was described in the first part of this series. As a starting point I got inspired by an article on Stackoverflow.
This customisation is required so that the we only need one entry in the Placeholder Settings section. Out-of-the box Sitecore is loading these settings based on the place holder name but since in our case that name is dynamic you would have to add an entry for each dynamic place holder which would be very cumbersome.
Continue reading “Enable dynamic MVC content place holders for Sitecore – Part 2”