SharePoint Mobile: Automating Image Rendition Deployments

What’s one of the biggest topics people talk about in the business world (and in particular, IT departments)? 

I’ll give you hint… it’s not VGA, USB, COM+ or DHTML.  It’s mobile, and BYOD (Bring Your Own Device)! 

Currently, IT departments across the world are scrambling to determine how to make their web sites and line-of-business applications work on a variety of mobile devices.

If you are a SharePoint developer and you haven’t already been asked to develop a mobile-enabled SharePoint site, it’s just a matter of time until you will be. 

Three years ago it was rare to implement mobile technology with SharePoint, but now it’s part of practically every project. 

A Trick for Saving Time When Using Image Renditions

Over the past few years I’ve had the opportunity to work on many SharePoint projects that have a mobile component on one level or another, and I’d like to share with you some of the tips and tricks I’ve learned along the way.  In this post, I’d like to share a simple and easy-to-implement trick that saves you lot of time when you use image renditions in a SharePoint web site.

Every developer likes automating processes, don’t they?  I know my team and I do! 

Here is a little trick you can use to automate the provisioning of Image Renditions in SharePoint 2013.  Before I dive into the code, let’s take a moment to see how much time this approach saves.

Consider a typical SharePoint 2013 Internet web site that you want to mobile enable. 

One of the things you may use to improve the web page load times for mobile device users are image renditions.  Image renditions allow you to serve images that are specifically sized and cropped for mobile devices. 

As you analyze the requirements and designs for a SharePoint web site you're about to architect and develop, you will determine the different image renditions that are necessary to support target mobile devices.  Depending on the design for the web site, you might have anywhere from a handful to dozens of image renditions that support the site.

As a point of reference, on a recent project where we created a typical SharePoint 2013 web site that uses three page layouts (one for the home page, one for a secondary page, and one for a tertiary page) we used 16 image renditions to support three different device channels.

Creating image renditions manually is a very easy process which involves filling out a form in the Image Renditions page in Site Settings (http:///_layouts/15/ImageRenditionSettings.aspx)to define a new image rendition. 

But what about when you have an entire team of developers working on the project who all use their own virtual machine (VM)?  And what about when you need to move the code to the test server, the pre-production server, and the production server?

Do you want to provide a deployment document that requires all your developers, testers, and operations personnel to recreate all the image renditions on each and every environment? 

Of course you don’t!  That sounds almost as bad as being the first person in the lift line on a powder day and then finding out the ski lift is broken.

Instead, you want to find a way to automate the process to save time, money, and ensure consistency across all the environments.  To automate the creation of image renditions, I like to create a SharePoint feature and include it in the WSP with the other branding components that are provisioned on a SharePoint site. 

The feature deploys the PublishingImageRenditions.xml file which stores all the image renditions that support the SharePoint site. 

Looking at the Code

In the elements.xml file in the feature I use a Module to deploy the PublishingImageRenditions.xml file to the master page gallery.  Here’s what that code looks like.

Notice the Level attribute in the example code above.  I set the Level attribute to Published, which automatically publishes the file. 

Also, note the ReplaceContent attribute.  Setting this value to true causes SharePoint to overwrite the content of this file upon provisioning.

Here you can see an example that creates three image renditions.  Notice the ImageRendition element which correlates to a specific image rendition. 

  4        1  Home Page Hero  1  325  128              2  Home Page Hero - iPad  1  325  128              3  Home Page Hero - iPhone  1  325  128          

Inside each ImageRendition element, I define the Id, Name, Version, Width, and Height for each image rendition.  As you can see, it’s pretty simple. 

The Id property is important to note because when you integrate image renditions with field controls in page layouts or custom components you need the Id to reference a particular image rendition.

Also note the NextId element at the top of the file. 

The NextId element tells SharePoint the integer value to use for the next image rendition created in the list.  In this example, the NextId element has a value of 4 because I am creating 3 image renditions via the feature.

If you feel like being clever, you could use the NextId value to reserve a range of Ids for image renditions which you create via SharePoint features. 

This might be helpful in the scenario where you are deploying a web site in a multi-phase approach, and you would like all image renditions created by features to remain in subsequent order, while still allowing content authors to create image renditions on the fly via the Site Settings page.

For example, let’s say you have identified there will be a total of 48 image renditions in a SharePoint web site you are developing. 

In phase one, you implement 16 of them, and in subsequent phases you plan to implement the rest.  In this case, you could set the NextId element value to 49 to accommodate the other image renditions that will be deployed via features associated with subsequent phases. 

If your content authors manually create additional image renditions between the time phase one is deployed and the project is finished, their image renditions will be assigned an Id value greater than 48.  Over time, this makes it easy in the future to understand if a given image rendition was created by a developer or a content author. 

This not only makes it easier on a developer to locate the image renditions they developed, but it also helps you understand if the process you're using to define image renditions during the architecture phase is working or needs some tuning. 

For example, if you find your content authors created a dozen image renditions manually, then you have a clue that your specifications for image renditions aren't taking into account all the images rendered on your web site, and you should adjust your requirements gathering and architecture processes accordingly.

You can also use code to automate the creation of image renditions.  The ImageRenditionCollection class in the microsoft.sharepoint.publishing namespace allows you to do this.

Hope you found this simple tip helpful. Next week I’ll share another with you.