In today's post, I'm going to explain the main options available to you when you need to change an existing property on an Episerver page or block. One often overlooked aspect of maintaining an Episerver website, is making amends to existing code as time changes. As new campaigns, products, content, news, updates come out, it's very common that layouts or pages will need amending. When the requirement involves making a change to an existing property, things can get tricky. Back in my early days of development, I was assigned a support ticket that requested a type changed on an existing property type. The property in question was located on the homepage. That one simple amend took the whole production site down for 20 minutes. Granted it was out-of-hours, however, anyone new to Episerver should understand this risk before they start making amends to existing content types.
How Do You Deal With Property Types Changes?
Get it right the first time: So the first option is probably a cop-out for anyone reading this and needing to change a type. When you are initially designing pages/blocks it's good to keep in mind that things change. As time progresses, the site will change. The easiest way to cater to these future changes is to design your pages and blocks to be flexible.
On a recent project, the requirement was to build a hero banner in the header of the start page. One way to build this feature would be to add three properties to the homepage page-type, a picture, an image and a title. In the future, it was very likely that the client would want to swap the herp banner for a carousel. In this example, the flexible approach would be to create a hero block and add a content area on the homepage. The content area should have validation added so the editor can only add certain blocks inside of it. To add a carousel to the homepage, would be simple. A developer would need to create a new carousel block and then enable that type to be used within a content area on the homepage. Developing for maximum flexibility makes maintenance a lot easier.
I also want to point out, that I'm definitely not advising to create everything as blocks. When designing an Episerver website, I still think the fewer blocks you create within an Episerver website, the easier it is to maintain. On certain key pages (like a homepage) the chances are extremely high that the content will change. If you have pages on your site that have a high chance of change, implement a content area. Deciding what to keep in a template and what to put in a content area is a bit of an art. This sort of decision is where experience with the platform comes into play. A good guideline is to make the homepage and landing pages flexible as possible., Try to stick with a template first approach for everything with a low chance of change.
Create a new content area: If you need to change an existing page/block, then a good option to consider is to create something new and use that rather than try to change an existing component on the website. This is a safe approach. When you release your code you won't break anything. The downside of this approach is that you might create some duplication in your codebase that you will need to remember to refactor later on. It's definitely better to have duplication than to take the website down for a few hours. In this phase, you can create a content area and a new block. YOu can potentially create a settings block specific to that page. This approach is usually undertaken in a two-phased release. In the first phase, you add the new property and hide the HTML to render the older property. Next, you release the site. In the final phase, you delete the old property.
NOTE One thing that might be useful to know is that if you delete a property in code, that won't automatically delete the data from the DB.
If you delete the property and then try and view it in the Episerver Admin:
sections ➡ content type ➡ page type
If you inspect the page properties, you will still see the property defined with the word missing next to it. Only when you delete that property via the admin in the CMS will all the data be fully deleted.
Create a new property-type: This advice is the same as above, except for one thing. Instead of creating a content area, you create a specific property type instead. All the advice above hold true. This is a safe approach, however, it is less flexible.3.
Refactor the existing property: If you have to change the type of an existing property. TEST, TEST, TEST! Back up your DB, cross your fingers and hope it goes ok. In some instances it will, others it won't... don't say you haven't been warned!
These are the three refactoring options you have. I suggest you avoid the third one if possible. Remember it is better to create a new property or a content area than to refactor an existing property! Happy Coding 🤘
