SXA Rendering Variants – The Hidden Gem of Sitecore Experience Accelerator (SXA)

Sitecore Experience Accelerator  (SXA) is a great productivity tool as it reduces your development time by giving you pre-built components. There were few new concepts and features that were also introduced with SXA like Page design and Partial design, pluggable themes, grid and column layout etc, but as the topic suggest, I will be focusing upon “Rendering Variant” concept and will try to explain how can this change the way you architect your website (assuming that is based on SXA).

Problem Statement

Let’s begin with a problem statement, the UX team have prepared a landing page and they have the various content components on the page displaying Image, Rich Text and Link all in a box but in various styles as below:

  1. Half-width component with Image and Text
  2. Half-width component with Image, Text and Link
  3. Full-width component with Image on Left, Text and Link on Right
  4. Full-width component with Image on Right, Text and Link on Left

They also want the content authors to have the ability to add them, remove them and order them in any way they like.

Sounds familiar ?

If I am not using SXA module, one of the approach would be to make these different components available via Experience Editor which content editor can add/remove/order from the content page. This means that there will be different “View Renderings” for each of the components types. Different view rendering mean different Data Source Templates and Data Folder Templates. So for the simple content based components above, we end up having 4 different view renderings, which more or less have same content but it is displayed differently.

SXA Approach


There is nothing wrong with the above approach, but if you website is based on SXA module you would have another tool to  meet your goal in a more effective manner.

The SXA provides a feature called Rendering Variant which optimizes the process of showing different variations of the same component. The variations can be setup via content editor and can also be supplemented with predefined styles and scripts.

The best way to explain Rendering Variants is by an example. I will be using the out of the box “Promo” component that comes with SXA. I am only interested in 3 data fields PromoText, PromoIcon and PromoLink (there are other properties too, but let’s keep it simple)

Promo Data Template

Rendering Variants are located under the /Site/Presentation/Rendering Variants node. In my case, the location was:

/sitecore/content/Tenant Folder/Tenant 1/Site 1/Presentation/Rendering Variants/Promo

Out of the box there was one rendering variant already present as ‘Default’.

Default rendering variant

I made a copy of that component and called it ‘Promo with Image and Text’

Promo with Image and Text rendering variant definition

I then deleted last child item ‘Promo Link’ from the recently created rendering variant and clicked save. The ‘Default’ rendering variant was renamed to  ‘Promo with Image Text and Link’ for readability purposes. And just by doing these few content item operations, I was able to achieve my 2 component variations (under like 1 minute, thanks to SXA)

To verify my changes I tested them out in experience editor. First I added a column splitter component to divide the page into 2 equal halves, then I  uploaded some stock images, added the Promo component from the Toolbox in each of the half , added random text and selected my variants via the dropdown. They worked like a charm!

Promo with Image and Text, Promo with Image, Text and Link

Similarly, I created a copy of the existing variants and called it “Promo with Image left” . I then added a ‘Section’ item for the variant definition and called it ‘Container’. I then moved “Promo Icon” under it. I also added the bootstrap class of ‘col-xs-6’ to ‘Container’ item and to the ‘Promo Text’ item.

Section item surrounding PromoIcon field in rendering variant definition

As you can see in the screen shot above, there are other types of variant definition items as well, check them out from the official site and see how flexible they are to give you almost any kind of rendering variation that you like.

For “Promo with Image Right” I created a copy of the “Promo with Image Left” and just reversed the order ‘Promo Text’ and ‘Container’ sections:

Image Left and Image Right rendering variant definitions

To verify my changes, I navigated to the Experience Editor, dropped the ‘Promo’ component on the page and changed its rendering variant via the dropdown to get the results below:

Promo component with Image Left

Promo component with Image Right

And that’s it, without even writing a single line of code, I was able to get all 4 component variations. In theory the number of variations that could be achieved using rendering variants are unlimited and totally depend upon your UX and Design.


If you are starting a new website based upon SXA module, you must consider rendering variants for your components as it will change the way you architect the website. This was a simple post but it showed the true power of SXA and how Rendering Variants can reduce back-end development efforts and also improve the content authoring experience. Kudos to SXA development team for this awesome feature!

Have fun

Note: If you want to play around with the, here is the link to the rendering variant package. I have used Sitecore 8.2 update 5 and SXA 1.5.



Sitecore 9 was announced at the recently held Sitecore Symposium 2017 and it comes with lots of new features and improvements. One of the major change to the platform is the way you install Sitecore on a server or local machine. The standard .exe installer has been replaced with a Windows PowerShell module which is called Sitecore Installation Framework (SIF). The SIF comes with Sitecore related pre-built tasks and configuration files to facilitate installation of Sitecore.

As a Sitecore enthusiast, I wanted to get my hands dirty with this new SIF module. After reading the official guide, I found out there were few pre-requites that were required even before running the SIF module. The 2 main ones were SQL Server 2016 and SOLR 6.6.1. In addition, the Solr instance must be running over https to make sure all the communication is secured.

The details of the installation process is given in the official guide but I will just mention few high level steps for local install:

Step 1: Configure and Install SOLR

So lets install Solr, sounds easy as I have done it few times before and I am sure you would have too. However, installing the secure certificate was bit tricky on localhost, but thanks to the Sitecore community, this SSL script from Kam’s blog worked like a charm and I had Solr 6.6.1 running over https in no time.

Step 2: Install SQL Server 2016

I had multiple versions of SQL Server (2012,2014) running side by side on my machine and installation of SQL Server 2016 Express wasn’t a problem as well. I ran the standard SQL Server 2016 installer and it was installed as expected (or I thought so).

Step 3 : Install Sitecore via SIF

As per the installation guide, I registered the SIF module via PowerShell and ran the following script: (I just added -Verbose at the end of each command so I can see the debug information during install)

I was expecting it to install Sitecore 9, but after the first run I got this error:

The error suggested that I have to install additional SQL server modules for Web Deploy to work, as given on the Microsoft’s website



The group of 3 errors listed above share the following diagnosis and resolution:

Diagnosis: SQL DAC and its dependencies are not installed.

Resolution: Use Web Platform Installer to install:

  1. Microsoft SQL Server 2012 Data-Tier Application Framework
  2. SQL Server 2012 Transact-SQL ScriptDom
  3. SQL Server System CLR Types 11.0

I installed the above dependencies and ran the script. It failed again with the same error message.

I was sure that my SQL server installation is correct and I have installed module related to ScriptDom but what is wrong with Web Deploy ?

Then I found this article on Sitecore KB for Sitecore Azure Toolkit 1.1 which mentioned to add registry values for the Web Deploy for DAC dependencies path.

I was bit skeptical at first but decided to go ahead with this approach. I added the 2 registry values via regedit. For one of the values, I have to point the path to the recently installed SQL Server 2016 SDK folder. For the second registry value, I have to point the path towards VS 2015 DAC folder. I do want to mention here I also had multiple versions of VS (2013, 2015 and 2017) installed on my local machine.

The registry values were:

DacFxDependenciesPath : C:\Program Files (x86)\Microsoft SQL Server\130\SDK\Assemblies

DacFxPath : C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\Extensions\Microsoft\SQLDB\DAC\130

The actual screen shot of the registry values for Web Deploy:

Ran the script again and BOOM! it worked.

So it turns out since I had multiple version of SQL servers and also multiple versions of VS installed on my local machine, the Web Deploy 3.6 was not able to figure out what is the path for the SQL dependency dlls to install the SQL DAC packages for Sitecore 9.

By the way, if you are installing Sitecore 9 for the first time,  Do check out the following posts:
How to Install Sitecore 9 with the Sitecore Install Framework 
Gotchas while installing Sitecore 9 using the Sitecore installation framework

The lazy developer’s way to install Sitecore 9
Introducing SIF-less for Easy Sitecore 9 Installation
Low-effort SOLR Installs 

I hope this blog will help any other developer facing the same error.

Happy Sitecoring 🙂

Sitecore Ship not working with 8.2-update-1 or failing silently

Back in May 2017, we started working an new and exciting project with Sitecore version 8.2 update-3. I was setting up the continuous integration/auto deployment for the project. Once CI/CD was setup as described in my previous blog posts I encountered the issue that Sitecore Ship module, which is responsible for synchronizing the Sitecore content items, was not working as expected. It was showing a 200 OK response in the Team City logs but in reality it was failing silently.

Doing a quick google about the issue I found at that I am not the only one having the issue, there are other people who are experiencing the same issue as well. I also came across this blog by another Sitecore developer who was facing exactly the same issue and he decided to switch to TDS package deployer instead of Sitecore Ship.

I haven’t personally tried out the TDS Sitecore package deployer before and looking at the blog post decided to take this approach. It was fairly easy to configure package deployer and after adjusting some of the Team City build steps, the .update package deployment started working!!

After testing package deployer with the continuous integration setup for few days, I realized that although the build process is copying across the .update files, there is no feedback from the package deployer (or a 200 OK response) that package has been installed successfully. In order to confirm, I have to RDP or FTP to the server and  check that .update files have been correctly installed or if they have failed for any reason.

So back to square 1, let’s figure out what is wrong with Sitecore Ship ?

Looking at the open issues list of the Sitecore Ship GitHub repository, I saw people reporting similar issues where Sitecore Ship was failing silently or not working on Azure Deployments.

Interestingly, there was also a pull request #69 submitted to fix this issue with 8.2 update-2 in Jan 2017 which had some really positive feedback.  As of today, this pull request has not been merged to the main repository or available via NuGet gallery.

In my case, the project was on 8.2 update-3 (one update higher than the submitted pull request version), and it wasn’t a straight forward fix. I was skeptical but I decided to repeat what has been done in pull request #69 and compile it against 8.2 update-3 version of the Sitecore and try it out.

This is what I did to get my fix:

1-Cloned the GitHub repository locally

2-Updated the solution’s .NET version to 4.5.2

3-Updated the Sitecore NuGet package version to 8.2 update 3

4-Modified the code for Sitecore.Ship.Update.UpdatePackageRunner class as mentioned in the comment section (and below)

5-Build and compiled the code and then replaced the dlls in the bin folder on QA server.

6-Ran the Team City build server script again and it worked like MAGIC!

The underlying issue, as mentioned in one of the comments ,was that there has been some updates to the Sitecore.Update.dll and the code that was responsible for deploying the items was not working any more. Also the solution’s target .NET version has to be upgraded to 4.5.2.

I believe that the pull request will be tested and merged into the main repository soon so everything is available via standard NuGet packages. However if have read till here and using either 8.2 update 3 or update 5 for your CI/CD setup, you can download the compiled dlls from my dropbox and give it a go!

For 8.2 udpate-4 you either wait for the NuGet package or do what I mentioned above.

Happy Sitecoring 🙂



Sitecore DevOp Series – Part 4 – Setup Sitecore Glass

This is the part 4 of the Sitecore DevOp series. Previously, we have installed a local instance of Sitecore, created it’s VS project solution and added TDS projects. In this blog post, we will configure Sitecore Glass Mapper for automated code generation using T4 templates. The blog series is aimed at newer audience and developers who are setting up CI for the first time.

Sitecore Glass

Sitecore Glass is an Object-Relation-Mappper (ORM) for Sitecore items. A common ORM that you may have worked previously would be Linq to SQL. Sitecore Glass helps in referencing Sitecore data item properties by using strongly typed C# objects. It is an open-source project and more information and tutorials are available from their official website.

Step 1 : Install Sitecore Glass for domain project

Sitecore Glass Mapper is available as NuGet package from the official Nuget feed server.
Assuming you have setup the ‘MyProject.Domain’ as per the previous post of the blog series, add a reference to the ‘Sitecore.Kernel.dll‘ within ‘MyProject.Domain‘ project:


Then add the official package via NuGet:


Remove the ‘App_Config‘ and ‘App_Start‘ folders from the ‘MyProject.Domain‘ project and add a custom class file as ‘Models.Generated.cs


Step 2 : Install NuGet package for main project

Install the same NuGet package for the ‘MyProject‘ , which is your main MVC project.


As of now, upon successful installation, you should see references to Glass.Mapper, Glass.Mapper.Sc and Glass.Mapper.Sc.Mvc. 

Step 3 : T4 Templates for Auto-Code Generation

As a starter, download the T4 templates as provided by the HedghogDevelopment github repository .

  1. Navigate to ‘TDS.Master’ project properties > code generation tab and check the box for ‘Enable Code Generation’. A folder will appear in the VS tree view as ‘Code Generation Templates’.
  2. Copy the downloaded T4 Templates files (with extensions .tt) that you downloaded from github within that folder and include them in the project via VS.
  3. Set the Target Project as ‘MyProject.Domain
  4. Set the code generated file as ‘Generated.Models.cs
  5. Set the base name as ‘Models
  6. Set the header transform file as
  7. Set the base project transform file as



When you hit save, the Models.Generated.cs should give you auto-generated code for the ‘Sample Item‘ template as below:


This is pretty amazing if you are doing it for the first time as now you can auto-generate your Sitecore data template properties and reference them in your main project as strongly typed objects. Every time you make a change to Sitecore templates, all you have to do is right-click the TDS.Master project, do a sync with Sitecore and it will update the code base. You can also ‘Re-Generate code for all items‘ as shown below:

Adding reference to Glass mapper and configuring TDS project with code generation will make sure that any field name changes that you make in data templates are reflected back in the code. If there are any compilation issues due to referencing make sure you .NET version is correct.

We are all done in setting up the project locally, the next step is to add our project to a choice of our source control so it can be shared with rest of the team and with our build server. This will be explained in the next blog post.

Stay tuned.


Related Blogs

  1. Part 1 – Continuous Integration – Why your Sitecore project deployments must be automated ?
  2. Part 2 – Setup and Configure Visual Studio Sitecore Project
  3. Part 3 – Setup and Configure TDS
  4. Part 4 – Setup Sitecore Glass
  5. Part 5 – Setup Source Control (Git)
  6. Part 6 – Setup QA Server, DB server and CI server
  7. Part 7 – Setup Continuous Integration using Team City
  8. Part 8 – Setup Slack Notifications with TeamCity and Bitbucket

Sitecore DevOp Series – Part 1 – Continuous Integration – Why your Sitecore project deployments must be automated ?

Over past few years with Sitecore, I have worked with various technical teams to deliver Sitecore powered websites. Sometimes we all are located in the same office, but most of the times, we are located in different offices and in different countries.

Part of my job role is to make sure that all of the development work is ready for testing (QA) at agreed time intervals (end of development sprint).

Quality Assurance (QA) is an important part of delivering any project and when a QA team member discovers a defect in the system, my usual conversation with the QA team member goes something like this:

QA : “Naveed, this feature is not working on the QA site?

Me: “Hey John (the fellow developer who did the original code), can you check why is it not working on the QA website?

John: “I am not sure, all my code is checked-in and it works on my machine as expected!

If you have worked on a Sitecore project, you must have had a similar conversation. The reason we have this conversation is because the deployment was done “manually”, which is an unreliable and error-prone process. A file or a package can very easily be missed during the deployment or a wrong version of a file can be deployed.

Moreover, the “manual deployment” process is very time consuming and it will increase the development cost. A typical Sitecore project may have numerous environments like QA, UAT and Production and each environment may have multiple CM and CD servers. As each server may be configured differently and may have different set of config files or config settings, the “manual” deployment process becomes even more complex. So you can see the “manual deployment” process, which started with one QA server, can quickly become very time consuming (read costly).

In an ideal world, what we would like for a Sitecore powered project, is that if someone has written a piece of code and/or updated Sitecore items, it should work on their local machine, it should work on the QA server (or any other non-production servers) and it should work on the production servers. The effort required should be minimal and nothing should be missed during deployment process. And for audit purposes every deployment should be documented.

Automated Deployments (Continuous Integration)

The best possible way to achieve this to make sure that the deployment process is fully automated from start to finish. All pieces of code and related Sitecore items should be packaged, deployed and published with “one single click” of a button.

To achieve our goal of ‘one-click-deployment’, there are tools and techniques available today (well actually since few years) which we can configure for continuous integrations and automated deployment. This will solve our 2 main issues:

  • Our deployments will be reliable and consistent.
  • We will be saving time and money.

If you are still doing “manual deployments” within your organization, it is time to re-think and re-evaluate this process.

The purpose of the blog series is to target newer audience/developers/tech teams, who have never done CI before and take them through a ‘hello world’ type of continuous integration process (automated builds).

Server Architecture

For the automated deployments to work, the code udpate workflow should be as following:

1- Developers should work locally and check-in their code in the source control (use of feature branches, fix branches and pull-requests is highly recommended)

2-Continuous Integration server  builds and deploys the code to the QA server

The diagram below shows a typical server architecture for the local and QA environment:



The important thing to notice here is that Sitecore items (templates, layouts, renderings, sub layouts) can be sourced control using tools such as TDS or Unicorn tools. I will be referring to TDS within the blog series.

As a minimum, automated deployment process for the above mentioned QA environment will require three servers :

1 – QA Server – Sitecore CM/CD combined on same instance

2- DB Server – Sitecore SQL server databases and MongoDB

3 – CI Server  – TeamCity server for continuous build and deployment

In theory, you can use only server, but it will have performance issues for the QA website.

Tools Stack

The tools stack that I will use to demonstrate the process in the series is as below :

  1. Sitecore CMS 8.2
  2. Visual Studios 2015
  3. SQL Express 2014
  4. Hedgehog Team Development (TDS) (licenses required)
  5. Sitecore Glass
  6. SlowCheetah
  7. Git
  8. TeamCity
  9. Chocolatey
  10. Sitecore Ship

There are other tools that can be used for the dev ops, for example, Jenkins can be used in place for TeamCity. Octopus Deploy can be used solely for deployment purposes, leaving CI server to do one job, that is to build the latest code. The decisions to choose the correct stack tools should be dependent upon your business requirements.

For simplicity purposes and for the newer audience, I will be using TeamCity for both build and deployment processes. Once you get confident with simpler process, you can enhance it/supplement it with different tools as you see fit for your project.

Assumptions for the blog series

I will assume that you starting a new project and have a blank machine/servers with only Windows on it or it is your first day at your new job. You can skip any of the below steps if you feel necessary:

  1. Download and install latest version of Visual Studios on your local machine or VM. At the time of writing this post, I have used VS 2015.
  2. Download and install latest version of SQL Express on you local machine or VM. At the time of writing this post, I have used SQL Express 2014
  3. Download and install TDS for VS2015 (requires commercial license, you can use 30 days evaluation for free)

I will also assume that you have RDP and FTP access to the QA, DB and CI servers as described in the architecture diagram to setup continuous integration.

As mentioned before, the blog series is intended for the  ‘new audience’, developers or teams who have never done CI integrations. The series will be pretty detailed and a single blog post will not do any justice, therefore it is divided into smaller logical parts of the setup process all of which will be posted in coming weeks.

The next part of the series are:

Sitecore DevOp Series – Part 2 – Setup and Configure Visual Studio Project

Sitecore DevOp Series – Part 3 – Setup and Configure TDS

Sitecore DevOp Series – Part 4 – Setup Sitecore Glass

Sitecore DevOp Series – Part 5 – Setup Source Control (Git)

Sitecore DevOp Series – Part 6 – Setup QA Server, DB server and CI server

Sitecore DevOp Series – Part 7 – Setup Continuous Integration using Team City

Sitecore DevOp Series – Part 8 – Setup Slack Notifications with TeamCity and Bitbucket


Local Sitecore Installation

Assuming it is a new project, the first part will be to install a blank Sitecore on your local machine. There are various options for installing Sitecore on your local machine

  1. You can install using the official .exe installer
  2. You can install using the official .zip file and attaching databases
  3. You can install using SIM module.
  4. You can install using Sitecore Rocks VS extension.

Every developer will have their preferred way for installing a brand new Sitecore website, I mostly prefer official .exe installer and will be referring to this in future posts as well.

Please refer to the official documents for installing the basic Sitecore website and do not forget to do the post-deployment steps.




For the purpose of the blog series, the project will be called ‘myproject‘. Once you have installed Sitecore locally and you can navigate the link http://myproject.local on your machine you are ready for the next step. By default, the installation location will be C:\inetpub\wwwroot\myproject\

In the next part of the series we will setup a VS project locally, configure a publish profile and add XML config transforms.

Stay tuned.


 Related Blogs

  1. Part 1 – Continuous Integration – Why your Sitecore project deployments must be automated ?
  2. Part 2 – Setup and Configure Visual Studio Sitecore Project
  3. Part 3 – Setup and Configure TDS
  4. Part 4 – Setup Sitecore Glass
  5. Part 5 – Setup Source Control (Git)
  6. Part 6 – Setup QA Server, DB server and CI server
  7. Part 7 – Setup Continuous Integration using Team City
  8. Part 8 – Setup Slack Notifications with TeamCity and Bitbucket

Sitecore : Adding a Twitter Pod using LINQ To Twitter

In almost all the projects I have done in past year or so, a common requirement among the clients have been that they want the ability to add Twitter Pods on pages and also have the ability to change the account name based upon their campaign or department.

For the purpose of the post, I will be using Sitecore CMS and LINQ To Twitter library to show how simple it is to create a Twitter Pod/module.

Let suppose we only want to display top  tweet from an account/twitter handle, which is define in the Sitecore CMS


1. Create a data template property in the CMS as ‘Twitter Account Name’ or whatever you like

2. Create a standard .NET User Control and lets call it ‘TwitterPod.ascx’

3. Reference LINQ to Twitter library in your project (download it from here and also read its documentation)

4. As per Twitter API 2.0 you need to get Consumer Key, Consumer Secret, Access Token, Access Token Secret values from for any applications that you are creating. Log-in there and follow the steps to get these values.

5. Add these Twitter API 2.0  values to web.config

6. Let suppose this is your .ascx control markup

<div><asp:HyperLink ID="HyperLinkFollowAccount" runat="server" Target="_blank"></asp:HyperLink></div>

<div class="twitter">
<asp:HyperLink ID="HyperLinkFirstTweet" runat="server">
<p><asp:Literal ID="LiteralFirstTweet" runat="server"></asp:Literal>
<p>Posted <asp:Literal ID="LiteralFirstPostedTime" runat="server"></asp:Literal></p>

7. Add these ‘static strings’ to your User Control class

private static string ConsumerSecret


get { return WebConfigurationManager.AppSettings["ConsumerSecret"]; }


private static string ConsumerKey


get { return WebConfigurationManager.AppSettings["ConsumerKey"]; }


private static string AccessToken


get { return WebConfigurationManager.AppSettings["AccessToken"]; }


private static string AccessTokenSecret


get { return WebConfigurationManager.AppSettings["AccessTokenSecret"]; }


8.  Twitter API 2.0 requires OAuth Authentication, to get that add this to Page_Load of your User Control

protected void Page_Load(object sender, EventArgs e)
if (!Page.IsPostBack)
var auth = new SingleUserAuthorizer
Credentials = new InMemoryCredentials
ConsumerKey = ConsumerKey,
ConsumerSecret = ConsumerSecret,
OAuthToken = AccessToken,
AccessToken = AccessTokenSecret

using (var twitterCtx = new TwitterContext(auth))
catch(Exception ex)
Sitecore.Diagnostics.Log.Error(ex.Message, this);

9.  LoadTwitterFeeds(twitterCtx) is your custom function where you can add your logic of getting tweets via Twitter API 2.0 and displaying them


private void LoadTwitterFeeds(TwitterContext service)

string accountName = Sitecore.Context.Item["Twitter Account Name"] as string;

var tweets = (from tweet in service.Status

where tweet.ScreenName == accountName &&
tweet.Count == 1 &&
tweet.ExcludeReplies == true &&
tweet.IncludeRetweets == true &&
tweet.Type == StatusType.User
select tweet).FirstOrDefault();

if (tweets != null)

HyperLinkFollowAccount.NavigateUrl = "" + accountName.Replace("@", "");
HyperLinkFollowAccount.Text = "Follow " + accountName + " on Twitter";

LiteralFirstTweet.Text = tweets.Text;
LiteralFirstPostedTime.Text = tweets.CreatedAt.ToString();
HyperLinkFirstTweet.NavigateUrl = "" + tweets.User.Identifier.ScreenName + "/status/" + tweets.StatusID.ToString();}

catch (Exception ex)
Sitecore.Diagnostics.Log.Error(ex.Message, this);

11. Create a Sublayout for this User Control and add it to the Sitecore Layouts.

Note: You can also pass in the ‘Twitter Account Name’ as a parameter of the SubLayout
Note++: Umbraco and Episerver CMS can also use the same code with different CMS based API.


Sitecore : Getting image field in code behind

This is just a quick post to show how to get image URL via code behind.

This is mostly useful when you are binding children items to a repeater or returning image URL in a JSON webservice

public static string GetImageURL(Item currentItem)
          string imageURL = string.Empty;
          Sitecore.Data.Fields.ImageField imageField = currentItem.Fields["Image"];
          if (imageField != null && imageField.MediaItem != null)
            Sitecore.Data.Items.MediaItem image = new Sitecore.Data.Items.MediaItem(imageField.MediaItem);
            imageURL = Sitecore.StringUtil.EnsurePrefix('/', Sitecore.Resources.Media.MediaManager.GetMediaUrl(image));
return imageURL;