Working with SyntaxHighlighter in Blogger Simplified - Updated

I’ve been attempting to clean up my blog and make it a little more user friendly for myself and visitors, and given that it’s a blog by a developer there is bound to be a code sample or two posted on it. When I see a code sample on a site I like to be able to scroll the code block to see the full thing, or highlight sections to copy if I like. Needless to say, it’s important to display code samples properly on a blog for coding.

When I was first throwing this blog together I searched for the best approach to displaying code samples. Some people were using SyntaxHighlighter with some tweaks and troubles here and there; others said the simplest approach was to just create a GitHub Gist and copy the Gist embed URL into your post. The Gist approach seemed the simplest so I decided to go with that to start. Well, now that I tackled that with all the effort it took (none, seriously) I decided to try my hand at SyntaxHighlighter.

ContentArea with Groups of Personalized Content

Personalization is a powerful component in Episerver that can provide a cool, fresh, and tailored experience for users that visit your site. Leveraging different criteria and conditions in Epi, Visitor Groups provide a grouping mechanism for users to be served different content based on pages they've viewed, forms they've submitted, or campaigns they have arrived from, among various other criteria. It's a pretty nice piece of functionality that, if you haven't learned about yet, you should check out more about, here.

That said, Personalized Groups in Episerver serve content on a prioritized, top-down, first-match basis. That means a visitor is served the first matching content item that is tagged with a visitor group they're in. That also means you are limited to one piece of changing content per Personalized Group for a user. But I needed more, and here are the solutions I explored.

Multiple Image Support in PropertyList

While working on a past project with heavy use of IList<T> properties I ran into several usability situations. One of those situations involved read-only values that were being imported from an external system. They needed to appear in the CollectionEditor, but did not need to be editable (read about that here). Another scenario I encountered involved images in the CollectionEditor. It started off with a simple implementation of the solution provided by Grzegorz Wiecheć, but evolved into something more.

One of the challenges we faced was the customer's need for multiple images in the list, and those images not always sharing the same property name. As with the issue around default values, some of the data for this was being synchronized with an external system, so we needed to be flexible with the property names and the number of image properties that might be present in the list.

DefaultValue in PropertyList

When Episerver brought out PropertyList support in 9.0 and showed the world how to utilize it (read the article here) it rocked the Episerver developer community and changed the way we utilize the CMS to this day! Okay, that's obviously an exaggeration, but it did introduce a different property type to the community, and brought about a different way of supporting lists or collections of data, that didn't require a bunch of blocks added to a ContentArea.

As interesting as it is, however, there are some shortcomings to this functionality. After all, it's mentioned in the linked article that it is a "pre-release API that is UNSTABLE." It's expected to have some quirks and shortcomings. Thankfully, as has already been demonstrated by Grzegorz, in his PropertyList with Images article, the PropertyList, or more importantly the CollectionEditor, can be extended to modify the functionality to fit different needs.

In this article I am taking a similar approach to Grzegorz to extend the functionality, but instead of supporting images in the list, I needed to support a default value specified through code.

A CSS-only Approach to Tooltip Icons for Help Text in Episerver

I was working through cleaning up the interface for my latest Episerver project the other day - clearly defining names, adding icon attributes to pages, adding helpful descriptions - and I saw a Tweet buzz across the wire for an article on adding icons to properties with Help Text (Description). The article is actually really good, and it got picked up by a couple colleagues of mine who implemented the solution in it. It's by Ted Nyberg and you should check it out here: https://tedgustaf.com/blog/2016/icon-for-property-help-texts-in-episerver/.

It sparked a memory for me, though, of another article I had bookmarked a short while back by Alf Nilsson, on how to expose the Help Text (Description) alongside the property name in the UI, eliminating the need to hover. Again, it's another good article and you should read it as well: https://talk.alfnilsson.se/2014/12/18/display-help-text-in-on-page-editing/.

Both of these articles touch on a pain point of mine, and various other Episerver developers, around how the Help Text (Description) is displayed for properties in the UI, and it got me thinking of another approach to address this issue, essentially combining these two ideas.

Properly adding Javascript in Blogger templates

Back in March, I wrote a post about a simplified method to use Syntax Highlighter in Blogger posts. The method utilizes a script I wrote so that I don't have to directly modify the html in a post (Working with Syntax Highlighter in Blogger Simplified). One of the issues I have run into with various scripts that have been posted, mine included, is the handling of special characters in the script. In certain conditions you need to look for an angle bracket or an ampersand using your script, and those special characters will break the Blogger parser when you attempt to add them directly in your script. In those examples, again, mine included, the special characters in the script have been replaced with their entity codes (see references below). For example, you can't simply add "<br>'.replace('<br/><br/>');" in a Blogger script.

After I posted that, I had a realization that you can simplify that condition, and future situations surrounding the use of Javascript in Blogger. Well, I finally got around to doing a quick test, and it seems to work without issue.

Sitecore List Fields - Item Not Found in Selection

I recently wrote an extension library for Sitecore to simplify setting values for fields.

Because of the way the specific field classes are created in Sitecore, setting values specific to the type of field can be tricky. For text-based fields, like Single-Line Text, Multi-Line Text, Rich Text, and a few others, you can actually set the value directly on a generic Field object with relative ease. For more complex types like lists, links, and images, though you can set the value directly on a generic Field object, setting the more specific options for the value needs more care.

So, I wrote an extension library to look at the Field type and set the value using the best method for that type. It worked great as far as I could tell, until I looked a little deeper during my "QA phase". And wouldn't you know it, it turns out there is a funky behavior with the list fields.