Updating Project Versions in Azure DevOps

We have a couple projects in DevOps that specify an incrementing build version as part of the release pipeline. The approach we have is working well and is deploying our projects with the proper version to our hosted environments. This approach, however, was causing some issues for local development and we needed a way to keep our local versions in sync with the releases. After looking into the behaviour I discovered we weren't the only ones. A quick search revealed many discussions trying to deal with this situation, and after some trial and error I was able to come up with a solution.

Validation Summary for Optimizely Forms in Non JS Mode

I recently wrote an article on how to create a Validation Summary for Optimizely Forms. The approach described in that article uses Form Client Events and Javascript to add a validation summary to the top of the form. That method is dependent on Javascript, and Forms must operate in JS mode for it to work. This article provides a different solution for use with Optimizely Forms with workInJonJSMode enabled.

Optimizely Form Container Block with Razor View

With CMS 11, Optimizely Forms display using a traditional Webform User Control (ASCX) out of the box. With all the work I have been doing with forms lately I wanted to change this behaviour to use a Razor View instead. Now that I have it working, I wanted to share it. 

Take note: as mentioned this only applies to CMS 11. With the release of CMS 12, Optimizely has rewritten Forms views to now utilize Razor, and all this work is not necessary.

Custom Optimizely Form Containers - Put the View Where You Want

Most instructions for creating a custom form block in Optimizely follow the same approach. My problem with the typical approach is that it requires a folder structure that doesn't match my solution. I use a slightly different method to allow me to move my Form Container Block rendering to my choice of folders.

The Problem with Nested Blocks and AdditionalViewData

It's not uncommon to nest blocks in Optimizely to create more controlled and complex layouts on pages. It's also sometimes necessary to provide additional data to the blocks you render. When using the PropertyFor helper this is done by specifying an additionalViewData object. However ViewData persists to nested views and this can mess up your layout. This is how to identify when this happens, and how to work around it.

Moving the DisplayTemplates Folder

Optimizely uses DisplayTemplates to provide a way to render different partials for data types. DisplayTemplates are native to ASP.Net MVC, though, and Optimizely builds upon them, for instance, by specifying a Tag. An example of this is the rendering of ContentReference properties in my articles here and here. The MVC engine defaults the location for them to "Views/Shared/DisplayTemplates". Sometimes, though, it's convenient to reference different locations, and this is how you can do that. 

Rendering ContentReference With Shared Views Using a TemplateTag

ContentReference properties provide a way to select a single item in Optimizely CMS when you don't need the featureset a ContentArea provides. However, rendering an item with a ContentReference is a bit different. I explored this a bit in my article Rendering ContentReference Properties. This post expands on this with a single DisplayTemplate that works for most content types. It builds on a similar technique using a ContentReferencePartial, and adds additional functionality using a TemplateTag.

Rendering ContentReference Properties

A ContentReference property allows you to select a single ContentData object for reference. By default, when you render these property types with the PropertyFor helper, it renders as a link for a page, or displays the name of a block. This is because the value stored is a ContentReference object, not the ContentData of the item referenced. This is one approach to render that content with a partial view.

How to Exclude or Modify Episerver Forms Samples Javascript and CSS

Optimizely Forms contains jQuery and CSS packages that are included for the Form rendering out-of-box. This isn't always desired because it can affect page performance, other styling, or it could have other side effects depending on your setup. Optimizely provides for the disabling of these files through the Forms.config file in the Forms module folder, which allows you to independently control the insertion of jQuery and CSS. However, this method is easy to break with an update. It also isn't very flexible since it's an all-or-nothing approach.

Creating Gated Content with Optimizely Forms

I recently worked on an Optimizely project where the customer wanted to serve gated content to visitors. If you're not familiar with gated content, it's where content is only available to a user that fills out a form - the form being the "gate". Gated content can be a powerful marketing tool to help capture valuable information for lead generation, or for tracking visitor statistics. 

In our case, the customer wanted to provide whitepaper downloads to visitors that provided a defined set of information. Our goal was to create this interaction using Optimizely Forms.

Hide Optimizely Form Info when Redirecting

With Optimizely Forms you have the option to redirect to a page after a complete submission. By default, Optimizely appends some form information to the URL it redirects to. This allows you to process the form submission data in any way you need to on the page it directs to, or perform an action based on what form was submitted. However, if you don't want that information in the URL you can change the behaviour.

Popup TextArea Property Editor

Inline editing in Optimizely delivers a great editor experience due to the WYSIWYG approach for content authors. Sometimes, though, the inline editing can get cumbersome. When making a bunch of edits, or editing a complex component, it can be easier to edit out of line. When working with string properties in these scenarios, I like to use a popup editing box, and this is how I do it.

Hide FormContainerBlock in Optimizely

It's easy to customize a FormContainerBlock by creating a new one inheriting from the out-of-box FormContainerBlock model. When doing this you gain the option of using the OOB container, or your new custom one. However, I have encountered numerous times when the OOB form container was no longer necessary for the project. Furthermore, attempting to use the OOB FormContainerBlock in certain areas created issues I had to account for. In several instances for me, the easiest approach was to hide the Optimizely FormContainerBlock from editors, and this is how I did it.

Optimizely Form Events using an Interface Pattern

Much like standard content items in Optimizely CMS, Forms trigger events that can be subscribed to for further customization. You typically subscribe to these events by employing an Initialization Module and attaching an event handler to process the logic you need for each event. This works well for the out-of-the-box Forms, but I have done enough customization of forms that I started employing an Interface pattern to clean it up. I use this same pattern for content events, so I thought I would share my forms approach. 

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.

Replacing HTML strings with Dojo TemplatedMixin

I've been playing around with Dojo a bit recently, modifying some Episerver widgets, and extending functionality, and I ran into a scenario I wasn't really satisfied with. In one situation I encountered, I needed to supply an HTML string for a widget to utilize when rendering data for an object, but the HTML markup had some conditions to it based on the object I was on at the time. Another situation involved looping through items and adding them to a list for display in a widget, again needing to include data from the object in the markup.

I searched online for how to parse HTML strings to include object data or conditions in it, but I didn't find the kind of answer I wanted. Many of the examples online show HTML strings in the Dojo script using concatenation for adding the variables, and others involved multiple lines of node creation and dom manipulation using "dojo.place" and "domConstruct". If you want easily adjustable markup using a template approach, avoiding modifying your dojo JS, these techniques are not the most user friendly. However, I did discover a solution.

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.

Rendering Options for DateTime (and other) Properties in Episerver

The question has been brought up to me more than a couple times in the past few weeks about how to properly format a DateTime property in a View and still allow In-Page Editing to work. Since I have answered it with mostly the same information each time it has come up, I figured it was time to put something out in cyberspace that I can point people to, or even help them find when the situation arises.

I am a huge fan of In-Page Editing in Episerver, and part of my goal when teaching people techniques working with Epi is to keep that In-Page Editing experience in place for users and editors so they can get the most enjoyable experience out of their site and CMS.

The nice thing about the approaches in this article is that while the article is centered around the DateTime property, most of these techniques apply to any property where you need to display something different than the actual property value.

Ultimately, then, this article is about the various techniques to render a property in a view while keeping the In-Page Editor working. I'm just using a DateTime property as an example.

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.