I presented at the SharePointFest Chicago in October 2013. During my presentations, I mentioned that I would upload my PowerPoint presentations.
Session 1: Search Customizations
This session covered customizations for search in SharePoint 2013.
1. Display Templates
2. Server side search web parts.
3. Boosting and segmentation
Here is the link : http://www.slideshare.net/perficientinc/search-customizations
Session 2: Public Websites in SharePoint 2013
In this session I spoke about all the considerations and options one has while creating a public web site in SharePoint 2013. I covered some of the quirks of SharePoint 2013 and workarounds.
Here is the link to the PowerPoint presentation : http://www.slideshare.net/perficientinc/creating-public-facing-websites-with-sharepoint-2013

Scenario: While building a search based application in SharePoint 2013, I observed a behavior which I thought was quirky. A page on a publishing site had a Search Results web part and a Content by Search web part. While configuring them, I set them to have the same query and result source.

Expected result would’ve been the exact same result set and count. But for some reason, the Content By Search web part was returning all the pages as expected but the search results web part was only returning a subset of it. What was even quirkier was that the search preview on the search results web part would display all the results.

I initially thought that some pages might not have been published and hence search results web part would not display them, but that was not the case. I started to debug what was being returned to the browser. I looked at the objects that the search results returned and did not find anything there. Starting to analyze the data, I realized all the pages that were not showing up had some content that was similar, even though they were unique pages the content had a similar tone to it. I think in the earlier versions of the Search Result Web Parts, the user had an option to “Trim Duplicates” which is no longer present in the SharePoint 2013 Search Result Web Part’s properties.

Digging a bit deeper, I found a way to set the Trim Duplicates to false.

1. Export the Search Results Web Part from your page.

2. Open the .webpart file in your favorite editor.

3. Search for “Trim Duplicates”, you will find it as part of the DataProviderJSON property.

4. Set the Trim Duplicates property to False.

5. Upload the web part.

6. Add the web part to your page.

SharePoint will exclude content that it thinks is similar. Even though the pages have a unique name and the content might not be the same, if it has some content that is similar, then search will collapse them in the result set. I think the user should have the option in the user interface to turn off the “Trim Duplicates” setting.

Once the option is set, you will get the results that you would expect and the result set from a Content By Search web part will match the result set from a Search Result web part (i.e. if they configured to fire the same query).

Here is a good article on Display Templates and Result Sets in SharePoint 2013. jQuery comes to mind when you think of the most common framework people use to manipulate and display content on the client side. There are a huge number of plugins that transform your HTML structure into a visually appealing format. These plugins need to be invoked after the html has been loaded in DOM.

Display Templates work a little differently. The skeleton gets loaded in DOM and then when the search results are fetched, they are transformed into the HTML structure that the Item Template defines.

So, as a developer you need to know when to invoke your plugin. If you invoke your plugin before the content is rendered, the plugin won’t find any child elements and will not work as expected.

SharePoint 2013 provides an array called OnPostRender as part of the context. Any function that is added to this array will be invoked after the search results have been transformed using the Item Template.

In your List Display Template add the following in the first DIV under the BODY tag.

<!–#_

ctx.OnPostRender = [];

ctx.OnPostRender.push(function(){

/* invoke your plugin code here to ensure the plugin has the content to work against */

});

_#—>

You will need to use this to create carousels, jQuery Mobile transformations, accordions, etc.

Scenario: In your organization you are using SharePoint to manage your projects. Tasks are created in each project site and assigned to you. To keep track of your tasks, you have to go each project site to view, edit those tasks. If you are involved in multiple projects then it can certainly become a time consuming task to manage all the tasks in all the project sites that you are assigned a task.
In SharePoint 2013, there is a much better way of going about managing your tasks. When you go to your My Site in SharePoint 2013 there is a link on the left hand navigation menu called “Tasks”.

Clicking on this link will show you all the tasks that are assigned to you across all site collections. You, as a user can now just go to your My Site and manage all your tasks, make changes and create new ones. SharePoint also displays those tasks on a nice timeline.

Features:

• All tasks can be managed from one location (My Site)
• Displayed on a time line. Ability to add tasks to the time line from the same screen.
• Sync to Outlook.
• Categorized/grouped by project sites or “locations”.
• Ability to mark tasks as important.
• Search your tasks.

In my opinion this feature will really boost the productivity of the users.
To setup the task management feature:

1. Setup the Search Service Application
2. Setup the User Profile Service Application
3. Setup My Site Host.
4. Setup the Work Management Service application
5. Make sure the Work Management Service is started (Look under Manage Services section under System Settings)
6. Create a project site in one of your site collections and assign a task yourself.
7. Run a Crawl.

Once the crawl is finished you can go to your My Site, click on the Tasks link on the left and you will see the tasks assigned to you.
Now since it is aggregating tasks, does it have the capability to aggregate tasks from other systems? Yes and No. No, because this is not out of the box. Yes, because SharePoint 2013 provides a framework to plug in different task providers. For example, you can write a Task provider which will connect to TFS and pull in the work items that are assigned to the user or a provider to connect to CRM and pull the tasks from there. The possibilities are endless.
Now to write a provider is definitely not an easy job by any chance but it’s not impossible too. I have written a provider which will connect to TFS and pull in the tasks and display them grouped by my projects.
Here is a very high level process:

1. Create a class and implement a few interfaces.
2. Compile and build your assembly.
3. Create an XML file and drop it in the following folder
   1. C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\15\CONFIG\WorkManagementService\Providers
4. Name the xml file in the following format providers.NameOfYourProvider.xml
5. Structure of the xml file is as follows

<Provider ProviderKey=”Guid” OverrideProviderKey=”” Assembly=” ” Class=” ” ></Provider>
6. IISReset.
When you first hit the tasks aggregation page, SharePoint will go through each of the xml files, parse through them and load the assembly specified in the xml file and starts calling certain methods in the class that was specified in the xml file.
I have a blog coming up which will go into details about which interfaces to implement and how the tasks get created and grouped.
 
 

In all the previous releases, creating master pages and layouts was definitely not easy for a designer considering the technical aspects of it. The designers would have to understand SharePoint and what components are mandatory on the master page and how they render to make their designs come alive.

In SharePoint 2013, there is a new feature called Design Manager which will help to separate the design aspects from the technical requirements to create a master page. Designer does not need to know which components are necessary on a master page. The Design Manager assists in creating the master page from simple HTML, CSS files.  The designer now only has to worry about his design and convert that into HTML, CSS and Images. Once these artifacts are ready, the design manager can process these to generate a master page.

The process to create a master page is really simple:

1.       Create the layout that you want using the HTML editor of your choice.

2.       Create the CSS file that supports your design.

3.       Add the images that are a part of your design.

4.       Upload all the files to the Master Page gallery. (There is a very convenient way to do this and make edits while developing and tweaking your HTML).

a.      Open your master page gallery in windows explorer.

b.      Copy the html, CSS and Images folder to the master page gallery.

5.       When you upload the HTML file, assign the HTML master page as the content type. (optional)

6.       All other files can be assigned the Design Files content type. (optional)

7.       Go to the Site Settings page.

8.       Click on Design Manager under the “Look & Feel” category.

9.       Or you could click on the new Site Actions button on the right and click Design Manager.

10.   Jump to the Import Master Pages.

11.   Click on “Convert an HTML file to SharePoint master page” link.

a.       This will open up a dialog box for you to select a html file from the master page gallery.

b.      Select the html file that you just uploaded.

12.   Once you select a file, SharePoint will generate a master page for that design. If any errors are encountered during the conversion process, it will notify you.

13.   At this point, the master page has been generated.

14.   To customize the master page click on the “Conversion successful” link.

a.       This will take you to a preview page. As you can see from the screen shot below SharePoint has converted and created the master page. 

Adding SharePoint components to the master page using Snippets Manager:

1.  Before we customize the master page, in the windows explorer window where you have opened the master page gallery, open the Html file that you uploaded in the editor of your choice.

2.  To add the SharePoint components like the top navigation and other controls, web parts, click on the Snippets link in the top right corner of the preview page.

3.       This will open up the snippets gallery page.

4.       Let’s say you want to add the top navigation to your master page.

a.       Click the Top Navigation button in the ribbon.

b.      This will create the HTML snippet you need.

c.       Copy the snippet to the clipboard.

d.      (You can customize the properties of the top navigation control and click on “Update” to generate the new snippet.

5.       Switch to the html file that you have opened up in an editor in step 1.

6.       Paste the html snippet wherever you want the top navigation to appear in your design.

7.       Save the html file.

8.       Refresh the Preview page in your browser and you will see that the master page was generated again and your changes are visible.

9.       This way you can quickly create and work on your master page.

10.   To publish the master page, select the html file in the master page gallery and publish it. This will automatically publish the master page file also and you will be able to set the master page for the site.

Screen Shot: The generated master page with the top navigation.

Tips:

1.    The html file and the master page are associated with each other.

2.     SharePoint will not let you delete the master page as long the association is still there.

3.       To remove the association, go to the master page gallery.

a.       Select the Html file

b.      Edit Properties

c.       Uncheck the “Associated File” check box.

d.      Save

4.       Now you can work on the master page directly by editing it.

5.       Also, while the html and the master files are associated, you cannot publish the master page file directly. You have to select the html file and publish it. This will publish the master page and you will be able to set the master page for the site.

6.       Suggestion: Once you build the master page to your satisfaction, disassociate the html file, package the master page in a wsp and then deploy it to your test, production environments.

In all the previous versions of SharePoint, the traditional way of retrieving content was using CAML queries and displaying them using your custom UI or use one of the OOTB web parts like Content Query Web Parts or List web parts. Search was not used that often or effectively. When CAML queries are not created carefully, then can be pretty expensive in terms of resources. You can see SQL resources go up, huge SQL queries getting created. To avoid all of this and make the querying and rendering process a lot simpler and efficient, SharePoint 2013 introduces the Content By Search Web Parts.
Search Driven Web Parts:
In SharePoint 2013, all the content can now be surfaced using search.  The “Search driven “  web parts have their own Querying Builder user Interface which makes it very easy to select, filter and display the data that you want. The SDWP (Search Driven Web Parts) web parts will also show you a preview of the search results.

Catalogs:
Another new feature in SharePoint 2013 is the “catalogs”. This is particularly interesting and powerful. Any SharePoint list in any site collection in any web application (in the same farm) can be published so that other site collections can connect to it and consume that data. This enables the user to author the content in one site collection and then consume the list in another site collection which might be in a different web application altogether. E.g. Authoring content in a authoring web application which might be internal facing and then another web application which might be internet facing which consumes the data from the published lists in the authoring web application.
To publish a list as a catalog, go to the List Settings-> Catalog Settings
The Catalog Settings Page:
Check the Catalog Sharing checkbox to enable sharing. Select the field(s) that make up the primary key to uniquely identify the record/item. Specify the managed metadata field that the consuming site can use to integrate in its own navigation. E.g. If you tag your items with Category Term set, then on the consumer side, your navigation could potentially integrate the terms in the top navigation, so that people can easily get to the information and based on your catalog your navigation will remain up to date.
Once you click okay, you will see a popup telling you that certain fields are not managed properties and you would have to map them manually. (Title, HTML field type, Client ID, etc.). If you have your own columns which are site columns then you should be okay and they will be available for refining.
To consume the list from another site collection, go to the Site Settings of that site collection and click on “Manage Catalog Connections” under “Site Administration”.
Clicking on “Connect to a Catalog” link, will take the user to a screen where all the catalogs that have been published will be listed.
Note: The catalogs are only picked up after a crawl. So, if you have published a list and don’t see the list in the catalogs list, then run a crawl and then it should be in the list.
Click on “Connect”.


There are a couple of options to choose from on this screen.
1. Connection Integration: It gives the option to integrate the catalog in the navigation in addition to making the content available. Or just to make content available and not integrate in the navigation.
2. Navigation Hierarchy: Select the column from the list that will drive the navigation. The category values will appear in the navigation itself.
3. Navigation Position: This is pretty self-explanatory. It provides the option of adding the catalog’s item category terms as a root navigation node or under an existing one.
4. Navigation Pinning: Pinning a term will not allow any changes to the term set.
5. Catalog Item URL Behavior: When you display the contents decide where you want your users to navigate to. Should the URL’s be relative to the site where the data is consumed or should the URL’s be pointing to the site where the catalog exists.
6. Catalog Item URL Format: Lets the user define the URL of the items

1. Defined by the catalog
2. Manually define it using tokens.
3. Use the UI and properties to define the format of the URL.

7. Category Page: Creates a new page layout for the catalog or lets you choose an existing one. This acts a rollup page.
8. Item Page: Creates a new page layout for a catalog items which will display the item information in detail or lets the user choose an existing one.
Once you click “OK” the catalog items are now available for you access.
You can use the “Items from a catalog” web part to display the results. Add the web part to a page. Click on Edit Web Part Properties link. Click on “Search Query”.
This allows modifying your search results, defining your refiners and settings (Priority, Loading Behavior, etc.).The query builder will also show you the results that the query will return.

Once you have set the query and get the expected results, you can choose what template to use to display the results.

You can choose to map the properties that are used in template to the properties that you have the content in.

Once you set the properties, the web part will display the content using the display template that was selected.

You can use other Search Driven web parts to display content. The search driven web parts along with catalogs is really a cool feature that in my opinion will be very efficient to manage and deliver content.

In one of my earlier blog posts, I showed how term sets can be translated manually using XLIFF files. This post will step through the process of setting up machine translations for a term set.
Process:
1. Go to Central Administration and create a SharePoint Translation Service application if it’s not already setup.


2. Once the service application is setup successfully, go to System Settings –> Manage Services on Server.
3. Select the Application server that you want to run the translation service and start the SharePoint Translation Service.

4. At this point the translation service is all set to go.
To translate a term set:
1. Go to the Managed Metadata service application.
2. Select a term store
3. In the Working Languages section, select the languages that you need the terms translated in.

4. Hit Save.
5. Select the term set that you want to translate.
 
6. Select the Translation tab on the far right.
Note: You only see the “Translation” tab if you have selected the languages you want the term store in Step 3.
7. Select Machine Translate click on “Continue” and then select the language you want to translate the term set to.

8. In this example, I selected the German language. Click Continue.
9. You will now see a progress/status screen after which the terms will be translated if the system has access to the internet.
10. This is all that is needed to translate a term set. To see the translation, select the language from the drop down in the top left corner.

The results are shown below side-by-side for comparison:
 

English	German

I am not sure how good the translations are but it’s a good starting point.

In my previous blog post, I described how the mobile panels work and what their shortcomings are.
This blog will outline the solution that will solve the problems that the OOTB panel has.
Problem Definition:
The Out Of The Box mobile panel when added to the layout has the following issues:
1. To author content in the panel you have to add the markup in the layout inside the panel markup.
2. If you try and add a web part zone in the panel, then to add web parts to the zone you have to add the Device Channel query string parameter to the page and then edit the page.

3. When the page renders, the panel does not respect the web part zones in the markup of the mobile panel and renders the web parts in other zones when the page is viewed in the channels that the panel does not target.
Solution:
To resolve the issues we need to implement a new custom mobile panel. The problem lies with the current implementation, it does not render anything if the current device channel does not match the configured device channel in the mobile panel. But that won’t work when web part zones are added and web parts are added to the zones. When this is the case, if the web part manager does not find the zone, then it places the web part in any of the available zones. (This behavior can also be observed when you switch page layouts which have zones whose ID’s don’t match.)
Solution Outline:
1. Check if the current device channel matches any of the device channels configured for the mobile panel. If the device channel matches, then you add the children to the control hierarchy else go to step 2.
2. While parsing the child controls, the code should check if the control is a Web Part Zone and if so, add it to the control hierarchy but set the visibility of the control to false.
3. If the page is edit mode then the set the panels grouping text, so that the user knows which device channels this panel targets.
When the new custom mobile panel is added to the page layout the authoring experience changes and you can see that web part zones now work in the panels.
Changed Experience:

In the screen shot above, both panels (targeting iPad and Default channels) are shown to the user when the page is in edit mode.
To even further improve the authoring experience, when you use jQuery UI tabs and custom mobile panels, it can dramatically change how to author content for different devices/channels.
Default Channel: Layout with three columns.

Published and viewed in the Default channel:

Tablet: Two columns for reduced device width.

Published and viewed using the Tablet channel:

Smart Phone: Zones one below the other.

Published and viewed in the Phone Channel:

Now the content author can work on the same page to add content to all the channels at the same time by just switching the tabs. Since you can add web part zones to the new custom mobile panel, you can have the flexibility in your page layouts and let the authors decide how the content is rendered.
I will blog about how to implement the custom panel in detail in my following posts.
 

SharePoint 2013 has a new component called the Mobile Panel. The purpose of this panel is to enable the content authors to target different content to different device channels or render same content differently based on how the site is accessed. My earlier post on Mobility shows how to setup a device channel and explains why it is used.

Let’s take an example to clarify the purpose of the mobility panel. Assume that you have a device channel setup for a Windows Phone. Your products reporting page displays current inventory of your products in the following format for a user navigating to the site using a browser.

Content Format 1:

This format would not be convenient for the user when he visits the site using a phone. You want the user to consume the information in a different way.

Content Format 2:

To accomplish this you would add two mobile panels to your page layout.

Mobile Panel 1: Target the default channel.

Mobile Panel 2: Target the Phone Channel.

Now, on your page which is created using the above layout, you would add the web part to render the content in the Display Format 1 to Panel 1 and add the web part to render the Display Format 2 to Panel 2.

Now when the user visits the page using a Phone (setup through Device Channels), the Mobile Panel 1 will NOT be displayed, only the Mobile Panel 2 will be displayed.

The syntax for the Mobile Panel:

Add the following statement to the layout where ever you want the targeted content to appear.

<Publishing:MobilePanel runat="server" IncludedChannels="WindowsPhone" >

<div> Some content targeted towards Windows Phone </div>

</Publishing:MobilePanel>

The attribute called “IncludeChannels” allows the user to specify which channels the panel will target. You can specify multiple channels (Alias) separated by comma.

To test how the page looks, you can navigate to the page by adding the query string parameter “?DeviceChannel=deviceChannelAlias”. E.g. http://domain.com/pages/default.aspx?DeviceChannel=WindowsPhone

Problem Areas:

• To add content you have to add the device channel query string parameter
• Big one : Web Part Zone & Web Parts
• Add the web part zone to the panel.
• Add some web parts to the zone.
• When you go to the page by specifying the DeviceChannel query string parameter then web part gets rendered in the right place.
• Here is the catch- When you go to the page without the device channel parameter (view the page through different channel) the web part still gets rendered! Also, it shows up in another zone when you edit the page from a channel other than the one the panel targets.
• This does not happen if you don’t have a web part zone in the panel, but add the markup directly in the panel. In this case, it works fine.

In my following posts, I will show you how you can fix this using a custom panel.

Mobility support has always been a sore point in the earlier versions of SharePoint. In the new version, mobility has a decent support OOTB. Now you can define channels for different user agents which can render a different page structure based on the user agent. Simply put, you can configure different Master Pages for different channels.
For e.g.: If you define a channel for a tablet, a Windows Phone, and an iPhone, you can create three separate master pages and assign them to the different channels. (Not mandatory, you can create a channel that targets more than one user agent string and assign a master page to that channel). So, different header, navigation, footer can be rendered depending on which channel is used to access the site. The channels though are not dependent on the device capabilities. They are dependent on the user agent string that the request contains. So now, you will have to add to the user agent settings for the channel whenever a new device/browser with a different agent string is identified.
To define your own device channel follow the steps outlined below:
1. Navigate to your publishing site.
2. Click on Site Actions (Icon)->Site Settings
3. Click on Device Channels.

4. Click on New Item.

This will create a device channel for you.

*Remember to click on the Active check box when you want to channel to be active and let SharePoint divert traffic to the configured channel.
SharePoint will go through the list of channels as per their order in the list. Hence the last channel should always be the Default channel. If the Default channel is the first one, no channel except the Default channel will be used.
Now that you have a channel, you can set a master page for that channel. This is how you would do it.
· Go to Site Settings
· Click on Master Page under Look and Feel

As you can see in the screen shot above, I have selected the “Phone” master page for the Windows Phone channel. Now when the user navigates to the site using a Windows Phone then the “Phone” master page will be used. This way you can control how the site renders when different devices access your site. (The Phone master page is a custom master page that I put together quickly just to demonstrate how the channels work.)
When I navigate to the site using my Windows Phone, I can see a different layout.

Tip: To test the look and feel of the site using different channels, navigate to the page you want to test by adding:
“?DeviceChannel=DeviceChannelAlias “to the URL. The screen shot to the right (above) demonstrates how that works.
E.g. http://domain.com/?DeviceChannel=WindowsPhone
This is definitely an improvement over the previous versions. But is this enough for a complete mobile experience? Not at all. A lot of thought needs to be put into the layout and how the content will react to the change in device sizes using CSS Media queries, etc.
Another feature in SharePoint 2013 is the Mobile Panels. The Mobile Panels when added to your page layouts can target different channels. This means that the content in that panel will only render when site is browsed through the channel for which the Mobile Panel is configured for. This is pretty interesting as you can use this to target different content to different channels or same content rendered differently based on the channel.
In my following posts, I will cover how the Mobile Panels are used and configured and also an interesting enhancement that will help in making the authoring experience a little simpler.

Rendering & Cache
Part 1 of this post describes where the definitions for the image renditions are stored and how versioning is handled. This post will describe how those renditions are applied to an image and how those images are stored. If you are the curious kind and always want to know what goes on behind the scenes, you will probably love this.
Note: There might some changes in the beta version, but the general working explained here should be the same. I will edit this post once I verify the working in the Beta.
Before I work through the details here are some pre-requisites:

• Blob cache should be enabled.
• Any image that you want to apply a rendition to should be published, otherwise the image will not be added to the cache. You will be able to see the rendition but it wont be delivered to you from the blob cache.

To apply a rendition to an image:
1. Add an image to a publishing page
2. Select the Design Tab
3. Click on Pick Rendition and select a rendition.

When you select a rendition, SharePoint will add a query string parameter called “RenditionID” to the Url of the image. This is the same ID you will find in the PublishingImageRenditions.xml.

The browser is requesting the image with a query string parameter. SharePoint handles the request in the following way.
When the HttpRuntime passes the request to the registered HttpModules:
1. The PublishingHttpModule picks up the request and creates a BlobCache object.
2. RewriteUrl method on the BlobCache object is invoked. (This handles how the specified resource is to be processed)
3. The RewriteUrl method does some processing and then calls the GetGeneratedRequestInfo method on the BlobGeneratedInfo class.
4. The GetGeneratedRequestInfo method in turn calls the GetImageRenditionInfo method on the ImageRenditionGeneratedInfo class. (This gathers information about the rendition for that image and returns it)
5. The GetImageRenditionInfo method checks if the file extension is a valid image extension and then calls GetRenditionForRequest method to get the rendition that has been requested using the query string parameter (RenditionID)
6. The GetRenditionForRequest calls the GetSiteRenditions method which returns the renditions defined in the PublishingImageRenditions.xml and in the form of an object of the type SiteImageRenditions. The SiteImageRenditions objects contains the collection of the renditions defined in the xml.
7. The GetRenditionForRequest method now has all the renditions defined and hence can filter out the rendition that was used for the requested image. (Defined by the query string parameter “RenditionID”).
8. The GetImageRenditionInfo method now returns a new object (type:ImageRenditionGeneratedInfo) with the just found rendition back to ReWriteURL method of the BlobCache object. (BlobGeneratedInfo is an abstract class, the ImageRenditionGeneratedInfo inherits and implements the BlobGeneratedInfo class)
9. The RewriteUrl method now invokes the GenerateLocalPath method on the ImageRenditionGeneratedInfo object. This method creates the path and name of the file that will be added the blob cache.

1. The format of the file: “Path””RenditionID”_”RenditionVersion”

10. The RewriteUrl method now does a couple of checks and then calls FetchItemFromWss method which is responsible for creating the file in the blob cache directory.
11. The FetchItemFromWss method checks if the file is published and then goes ahead and calls the CreateFile method.
12. The CreateFile method then calls the GenerateFile method on the ImageRenditionGeneratedInfo object.
13. The GenerateFile method in turn calls the GenerateRendition method on the ImageRendition class which actually resizes the image / crops it and then returns a stream of the new image.

1. So where does it get the cropping values from ?? These were not defined in the xml file.
2. When a rendition is getting generated using Edit Renditions screen, the cropping values are actually stored in the property bag of the image file itself.
3. The property name is of the following format : “PublishingImageRendition” + RenditionID. E.g. PublishingImageRendition1 , PublishingImageRendition2 ,etc.
4. The value of the property has a specific format: RenditionVersion;SourceImageWidth;SourceImageHeight;CropStartX;CropStartY;CropWidth;CropHeight;

14. The CreateFile method now flushes the stream to the file system. (Actually creates a temp file and then moves it to the actual location)
15. We finally have the file in cache.
There are a lot more checks / conditions that are taken care of and I have emitted those details in this description.
To generate a rendition which only displays a certain portion of the image, follow the steps below:
1. Add an image to the page
2. Select the image
3. Click on the Design Tab
4. Click on Pick Rendition
5. Click on Edit Renditions

6. Click on “Click to Change”


Now you can drag/drop/move the box to define the exact area that you want to use. Once you click on save, the rendition is saved along with its settings.
This can also be done directly from the library which contains those images.
That’s all to it.

My last post introduced Image Renditions and how to setup and use them. This post will dive a little deeper in the inner working of the feature.
Storage and Maintenance
Creating a image rendition definition:
Click on Site Settings->Image Renditions. You will see all the existing (if any) renditions that have been defined.

Initial impression after looking at the above screenshot is that this information must be stored in a hidden list in the site somewhere. But that is not the case here. The renditions are stored in a xml file in the master page gallery.
File Name: PublishingImageRenditions.xml
The structure of the xml file looks like this.

If you notice, it keeps the next available ID to use here. If you edit an existing rendition and save it, the version element of that rendition in the xml will have its value incremented and also a new version of the file itself will be created.

My next post will describe how this file is used and what goes on behind the scenes when you apply a rendition to an image.
Click here for Part 2.