This is the fifth post in my series about Episerver CMS display options. In today's guide, I'm going to talk about disabling different display options for different views. At first, you may think this topic is pretty easy, unfortunately, it's a little bit more complex than first appearances. When we work with display options content editors can set the width of a block themselves. In some instances, a block may look broken in certain views. Some blocks should only ever render full-width. If you only need to display your block one way, like full-screen then life is pretty easy. Life becomes a lot trickier when you only want to display two or more of the available display options. In this guide you will learn how to do that, so read on!
As mentioned in, How To Set A Default Display Option View For An Episerver 10 Block you have a few options to prevent this from happening. The easy option is to give the editor a CMS guide and trust your content editors. You could also simply not write code to use the display option tag within the blocks HTML. This option obviously does not work if you only want to implement some of the display options. So what do we do?
Can't I Just Filter My Display Options Based On Content-Type?
There are two main ways of preventing content editors from adding display option sizes blocks. The best option in terms of usability is to only show the correct display options to the user in the display menu in the editor:
If you strip out the invalid options first then they'll never be able to set it to set the display incorrectly. The Episerver UI is powered by DojoJS. To do this type of filtering requires knowing Dojo. There is also no Episerver UI to hook into, if you try and go down the route of filtering out the context menu, you will likely have upgrade issues later on. For this reason, I tend to avoid this path. To create this filter, you need to copy the core Episerver displayoption.js file, clone it and then write some Javascript to call a web API to get the list of available display options for a block.
My issue with this approach is that whenever I've modified core files I've paid a price later down the road. If Episerver change that displaysoptionmenu.js file and you upgrade the CMS, your editor may suddenly break, which is not ideal! For this reason, whenever I've implemented display option validation for clients I've always worked with the system and the API. This means we have to take another path, create a custom validation attribute that prevents the user from saving the page if it contains a block set with an unsupported display option.
Should I Disable or Enable Display Options?
There are two types of validation approaches, block everything and only allow certain things, or, we can allow everything and then disable certain things. From my experience, most clients only ever need to lock down a handful of blocks and most people are happy to trust content editors. For this reason, I tend to allow all display options and then prevent specific ones. This is the approach that I will take in the code below. To get started we will need an interface. When we work with Episerver I always recommend using composition over inheritance:
As I've mentioned in the previous posts, when I work with display options I like to use enums to represent the different views:
To set which display options we want to disable on a block, we can then use this code:
Next up, is the attribute code:
The code is pretty simple, we get passed in the content area items, loop through each item, check if the block implements the IDisallowDisplayOption interface. If it does, a request is made to get the requested display options the content editor is trying to set. If the current display option is matched within a list called DisabledDisplayOptions then it is not allowed and return false. It's now impossible for content editors to save blocks that have been set with invalid display options! To use the new attribute, we simply set it like this:
Now when you try and save your page or block with an invalid display option, you'll see this error:
Obviously, the main pain point of this approach, is that you have to remember to add the attribute whenever you need it... asides from that enjoy! Happy Coding 🤘
