Archive for November, 2015

The bLazy Plugin provides us with a great way to implement serving up resized images based on the current viewport, and additionally it also allows us to lazy load images on our site, drastically reducing the page size and download time.

We used bLazy for img tags – and also for other tags (where it simply loads up the image as a background image).

We created a few glass HTML helpers here to help us maintain consistency and increase maintainability by having this html present in only 1 place in the site.

Images can usually take up most of your page load time. In our project we were loading product images from the servers, and resizing them before serving them up on the site. To improve performance, we decided to try and do the resizing and image loading there after asynchoronously.
So we created an asynchronous http handler to perform this action.

We were resizing external images (not stored in sitecore), but we did want to load up a default image stored in sitecore if the image didn’t exist on the filesystem.
To achieve this, we passed in the url of the default image (language specific) as a querystring parameter to the http handler itself. In this case, it would check if the intended image existed on the filesystem, if not, it would return the resized default image in the response stream.

In the above code, IsValidProductFileSystemImage – basically executes a System.IO.File.Exists call to check whether the image in the ‘path’ parameter exists.
Additionally, the code for ResizeAndCropImage can be found at: Resize Images with Crop and Quality Control.

We also needed a way to achieve this for images inserted in the rich text field. Especially seeing as we had content authors adding images sized 3000×3000 in there, and page sizes soaring up to 80mb each at times!
We implemented a solution with the bLazy plugin.
The plugin documentation will tell you, that once we include the script and initialize it with the right parameters, all it takes is adding the right attributes and class into our html, to enable lazy load of images – resized if need be for each breakpoint as we determine.

Here’s what we implemented for this:

We added a patch to the renderField pipeline, which would transform all img tags as we needed – add the required class which is to be used as the selector for the blazy plugin, and also the breakpoint specific resized image url attributes. In addition, we also replaced the img tag source with a base64 encoded transparent gif so it wouldn’t do any extra requests.

We added a reference to the bLazy plugin, and initialized it with the parameters suitable to our requirements.

You just need to make sure that this page editor friendly image (with the special class we define) is on the top of all your content – layer wise (Settings z-index:-1;position:relative to the remaining content will ensure this).

Once this is done, here’s how your image will appear in page editor mode:

To come up with a flexible solution to using shared templates across sites with image fields as well – while the sites have separate media repositories, we came up with a solution where the common Site Node (a common parent to all sites) has a field “Media Repository” where we select the corresponding media repository for each site node.

Using this setup, we are able to link a site node to its corresponding media repository and hence, point the image source of an item to its respective repository folder.

The only restriction here, is that the folder structure would need to be the same in every site media repository. But note – this will also apply to any solution we use for datasources with Sitecore queries in other link / list Sitecore fields.

Also, if you have a scenario where you’d want a content author to be able to select multiple images on an item from a treelist, then you’d want to add this support on the treelist field as well. We chose to go with a new custom field though 🙂

Sitecore 8, I believe has inherent support for sitecore queries in the ‘Datasource Location’ field of renderings!
But for those of us waiting on client approvals to make the move from Sitecore 7.xx :(, here’s the way to add that support!
This will come in very handy especially while working with shared renderings to be used across multiple sites in your Sitecore instance.

However, this will not apply to rendering parameter templates. Since while selecting the rendering parameter values in the presentation of an item, the context item is the rendering itself and not the item on which the presentation is being set.
So if we were using a common rendering parameters template for items in multiple sites, we need to rig something up, so that the options appearing in the link / list type rendering parameters show options from the respective site node.

As an example, consider a rendering parameter template, with a background color field.

This rendering parameter is set to a shared rendering which is used on multiple sites. However, each site has its own unique list of background color options.
To solve this issue, we needed to add support for the token like $sitenode in the example above.

The handler code we write, replaces this token with the right path, after identifying which item the presentation is being set on, and then identifying its sitenode ancestor.

This extension is then added to the regular Droplink field. The logic outlined above will kick in only when the current item has the template: /sitecore/templates/System/Layout/Rendering Parameters/Standard Rendering Parameters as its base template. Which would ideally apply to all rendering parameter templates.

Now the ‘$sitenode’ token would get translated as per the logic added in the above code to the respective site node.

Sitecore uses the telerik rich text field for allowing rich text on the items. While this allows the content author to enter any styled html they please, we might also want to provide them with a finite list of pre-existing styles which adhere to the current site design.
These can be managed in a CSS file and the CSS file can be referenced by overriding the WebStyleSheet setting in sitecore configuration:

The styles will then appear in the rich text editor for any rich text field:

In this case, the css class names in the css file, are TEXT–STYLE-1, link–style-1 etc. If we want more user friendly names, say with spaces etc, we need to override them in the sitecore/shell/Controls/Rich Text Editor/ToolsFile.xml file that telerik uses:

Now, all this works perfectly well in a single site environment. If you want to have a different set of styles available to the content authors for each site in a multisite instance of sitecore, you’ll have to get a bit more creative 🙂

Here’s how we went about it.
We created a separate CSS file for each site.
Each site in our sitecore instance had a parent site node item. We added a field to enter the site specific css file path on the node.

On the site nodes, we would set paths relative to the website folder, eg: /_CSS/Site1/rtfstyles.css