Using Episerver CMS as a makeshift API – Part 3, Quick Update and Exit
This is a quick update to conclude my multi-part series about Episerver.
In my previous post I alluded to my uncertain future working with the Episerver CMS.
I spent a little over two-years at my company and had decided to move on. Now I’m happy to confirm that my time working in the Episerver ecosystem has come to an end. I’m going to miss the talented people but it became increasingly difficult to ignore that I wasn’t happy in my role.
This whole project came about because I needed an outlet for the kind of skill set I was previously known for. I might write a post about that later.
Regardless, I wanted to write a final part about this makeshift API (I know it’s a terrible name). I did do more work on it since the last post, spurred on by requirements at work. The changes are in the repository but I tidied the UI and I was changing the approach to parsing JSON objects rather than deserialising/mapping to a predefined class. This was so you could run it on any black-box Epi-instance and be able to generate classes from the properties if you needed to.
Ultimately this project was going to provide a solution for these commonly asked questions.
- Where are all the places this block (type) is used? How many? What are the page URL’s?
- I want to change this property for all blocks of this type. That should be quick and easy right?
- I want to change this piece of text across the whole site. That should be quick and easy right?
- I created multiple pages rather than one page with multiple languages. You can “merge” them together, right?
- I want all the pages in a Word doc for my copywriters/legal/bored-intern to review. That should be easy, right?
The mechanism for making changes and publishing content is reasonably straight-forward. I’m leaving the repository open, in case it’s useful to someone.
Well, that’s it from me about epi.
I hope someone finds this interesting or useful.