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”
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”