Growing Episerver DXC instance? You might want a tool like this…

I’ve recently just started working with a new client who has an existing Episerver DXC implementation with about 16 sites (12 live, 4 underway). I was quite overwhelmed with the number of content types in their solution: 65 page types and about 130 block types. Below is an architecture diagram of just page types.

Page Types using Class Designer
64 Page Types in the CMS
When you have that many page types, it becomes overwhelming, not just for developers, but for testers and content-authors who use and maintain the site. Unless properly architected, this can cause huge headaches such as unexpectedly breaking other parts of the system or authors having to scratch their heads when choosing a page/block type in the CMS.
Tip: The less page types, the better. Take advantage of Episerver’s reusable blocks.
As part of the discovery phase on working on this project, I thought of developing a tool to provide visualisation on how the page/block types are used across multiple sites and give answers to the following questions:
  • Are the sites sharing page types and block types?
  • Are there relevant content type restrictions in place?
  • Which parts of the system are going to be impacted when updating a content type?
  • Are there content types not in use?
 

What you can do with the tool

Access it straight from the Episerver top menu

Extend Episerver User Interface Menu

Find out which page types each site is using

Episerver Site usages of page types

Find out usages of page types across multiple sites

Episerver audit of page types across sites

Find out usages of block types across multiple sites

Episerver block types usages across sites
 

The implementation

I am planning to make this publicly available as a NuGet package for everyone to use. If you can’t wait for the NuGet package, feel free to go thru how I’ve implemented the tool, high-level. This blog post does not currently contain all the code. Until I publish this as a NuGet package, feel free to contact me if you need the entire source code.

CMS Audit implementation

  1. Web.config – tell your website of the new protected module show code
  2. CmsAuditController – extend the Episerver interface show code
  3. ICmsAuditor show code
  4. CmsAuditor – the brains of the audit which uses Episerver API’s show incomplete code
  5. DependencyResolverInitialisation – resolve ICmsAuditor to CmsAuditor show code

Room for improvement

While this tool has provided for my current needs (show me the data!), there’s definitely room for improvement for the current implementation. Some ideas I have:
  • Scheduled job – It currently audits and generates the usages on the fly. I’d like to offload the generation of data to a scheduled job
  • Export functionality – formats such as CSV, PDF, etc
  • NuGet package and make available for everyone 🙂
 

Conclusion

When you have a growing Episerver DXC instance, it becomes imperative to have some sort of visualisation of how your content is currently structured.
This tool should benefit the following roles:
  • Developers – this tool is a good reference for when making content type changes in the codebase. You can confidently make changes knowing which sites are impacted. You can also apply better content type restrictions to make the lives of content authors easier.
  • Testers – this tool will help form a basis for testing and maintaining a regression suite
  • Content authors – knowing the usages of page types and block types across multi-sites can help you validate content architecture/structure decisions you have in place. For example, when you have a specific block type you have instantiated multiple times across different sites and find they all have the same content, you can then start making decisions as to whether they all just re-use instead of maintaining multiple blocks of the same content.

Discover more from Nicola Ayan

Subscribe now to keep reading and get access to the full archive.

Continue reading