powered by Swissworx Pty Ltd, your Sitecore experts
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> <datacenter name="Australia Southeast"> <coordinates left="85%" top="87%" /> </datacenter>
Happy deployment!
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:
<datacenters> node<datacenter> nodes for each additional region
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:
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.
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:
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.
GetAllowedRenderingsThis 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”
In one of my projects I have the requirement to allow the content administrator to create content using a large set of pre-defined content blocks (renderings). The provided design required the responsive website to wrap content rows into div tags. For this project we had to allow the content administrator to mix and match content blocks for 1 colomn, 2 column and 3 column layouts on the same page. Here’s an example of how a sample page could look like:
This is a simplified view of the various different content blocks. Also the number of required rows and columns vastly wary from page to page.
Since the numbers of rows would not be known at the time of creating the Sitecore layout view, only the ‘Header’, ‘Menu’ and ‘Main’ place holders could be defined in the mark-up. Each of the content rows rendered in the main content place holder would be wrapped in a row rendering that contains a place holder used to render content blocks.
In Sitecore it does not make sense to declare a content place holder with the same name more than once on a particular page. If you were trying to do that, Sitecore would render everything in the first occurrence of the place holder and ignore the others.
In order to overcome this limitation I realised that I had to find a way to declare content place holders on the fly from the content authoring environment. The following stackoverflow article describes how to do that but I didn’t like that it uses a Guid as the dynamic part of the name. Hence I decided to blog how I overcame that limitation allowing to declare more meaningful dynamic place holder names.
Continue reading “Enable dynamic MVC content place holders for Sitecore – Part 1”