In this tutorial, you will learn about three different approaches to build the Episerver block. Each approach will give a content editor various degrees of flexibility on the end HTML that gets produced. In a traditional CMS website, web pages were made up of very static templates. Content editors added text into pre-determined properties, however, in general, they had very little flexibility when it came to moving graphical elements of the page around. When Episerver introduced the block model in version 7 onwards, this allowed developers and designers to give a lot more power to the content editors in terms of defining a page layout. Gone are the days where a code change was required to change how a page was structured. Content editors could drag blocks into content areas and re-size and re-order the components as they wanted.
This flexibility created an interesting challenge for designers, especially those new to Episerver. How do you build a system when you have little control of the final HTML that Episerver will output? If you are reading this, then I'm assuming you are using a responsive grid framework, like Bootstrap. The Bootstrap grid is made up of rows, and items in the rows can have columns. Each row should add up to 12 columns. An example of s basic bootstrap grid in HTML can be seen below:
If you create an Episerver template that doesn't use blocks then you can always guarantee that your HTML will be rendered as expected. Episerver will simply parse and render the HTML within the page corresponding view file, however, if you create a template that contains a content area things change. When you allow content editors to drag blocks into a content area, you will not know the exact HTML the page will end up rendering. This can cause problems. For example, a content editor could add hundreds of blocks into a content area and the pages end HTML could end up breaking the Bootstrap 12-column row rule, like so:
When you work with Episerver and you allow content editors more flexibility with blocks, you will not know what the rendered page HTML will be. Before you panic, you do have several ways within Episerver to limit this issue, which I'll explain:
1. The HTML in a block can be structured with a pre-set class.
Building a component like this will give you a lot of control over the end mark-up. The trade-off with this HTML is that the content editors have reduced flexibility within the Episerver editor. In this example, anytime a content editor wants to add a feature block, it will render with one row, which always has to contain three components that render with a 33% view width.
Some clients will want to lock the website down to prevent content editors from breaking the site's HTML. This option will suit clients with a similar need. If you can follow a whole row approach, as a frontend developer, your life becomes a little easier. Unfortunately, in most companies, this approach is usually deemed too restrictive, as blocks are one of Episerver's main selling points!
2. The backend developer creates a specific row block. In this approach, we have lots of control over the end HTML. The trade-off is a slightly worse content editing experience. The content editors have extra work to do within the Episerver editor. When creating a system using this approach, anytime a content editor wants to add a block into a content area, they first need to add a row block. Only after they add a row block can they then add any individual blocks. The code to achieve this look like this:
Following this approach, you can still enforce the end HTML that gets rendered. A backend developer can add validation to the content area that will limit the content areas to only accept a row block. The purpose of the row block is to solely render the Bootstrap row. At a basic level, it provides no other benefits. After a row block has been dropped into a content area, content editors can then drop other blocks within the row block.
If you really want to guarantee your mark-up, you can also get a developer to create a custom content area validator to prevent content editors from adding more than 12 columns within a row block. The downside of this approach is that it also makes the backend slight more clunky for content editors as they have to perform more clicks when creating content. If you want some more information about splitting up your pages into blocks, then I would recommend reading, Respect The Block! How To Decide What Should Be A Block When You Start A New Episerver Project.
3. A flexible block architecture. This is the scenario that I listed at the start of this tutorial. In this option, content editors have a lot more control. They can use Episerver display options to set the size of the block and they have the power to order blocks however they want. This approach is good for clients that want total flexibility and who trust their content editors. The downside of this approach is that you may end up with a mark-up like an example below:
As you can see the number of columns exceeds the limit the row should have, however, if you write your HTML to always float left then in most circumstances the page should still look beautiful 🥰.
4. Custom Content Areas. Episerver is very flexible and easy to change. If you have some really specific HTML needs then you can get a developer to create a custom content area that matches your requirements exactly. One example where I have personally used this approach is to automatically render the 'row' class. Using a custom content area meant that no matter what a content editor does the Bootstrap grid works magically in the background. This approach has flaws, if you need to apply a gutter class you would not be able to do so 😢
Episerver HTML Considerations Overview
The aim of this tutorial was to explain the flexibility tradeoff. The more power we give content editors, the less control we have over the frontend HTML that is generated. If you want to create a fully responsive website (and in this day and age, that's the most logical option) as long as the business agrees that content editors will take some responsibility that the pages they create look OK, option 3 is the option I would recommend. Option 3 will give editors the most flexibility possible. If for whatever reason, you're considering an adaptive design (not really recommended anymore), it is a better idea to make your Episerver block architecture less flexible, as you'll need more guarantees about the end HTML mark-up.
Which option you use is really dependant on your business requirements. Some companies don't want to trust content editors and want everything locked down, while other companies fully trust the content team and want to give them as much flexibility as possible. Personally, I've used all three approaches at different times and on different projects. As long as you build something the client is happy with that's the main thing. Happy Coding 🤘
