It might sound obvious, but content management is about more than just content creation and editing. It is also knowing when your content has reached the end of its useful lifespan. It means knowing when it’s time to ‘Move to Trash’, and when it’s time to ‘Move to Trash’ permanently!
I’ve seen as many content management systems ultimately fail due to poor on-going content control by editorial teams as I have through poor initial implementations by developers. There are many reasons that your content can grow out of control. When it does, your CMS becomes nothing more than a publishing platform and a quite inefficient one.
“I’m sure I’ve written an item like that before…”
“Yeah, it’s in here somewhere, I just can’t find it…”
“I don’t think that content is used but I’m not sure, so I didn’t archive or delete it, just in case…”
Tidying up after yourself whatever your discpline, is just good practise. Whether its content, a codebase or your email inbox. Being scared to delete is a sign that you aren’t in control.
One of the editors I work with on an EPiServer site wasn’t scared to delete content, but he was overawed by the effort needed to discover unneeded content.
This got me thinking. There must be a better and easier way than trawling through a hierarchical tree…
Content reporting using a slice
EPiServer recently reintroduced PowerSlice as a ‘supported’ add-on. PowerSlice uses EPiServer Find to give editors a view of content which goes beyond the traditional hierarchical structure. It allows developers to very easily ‘slice up’ content in any number of ways.
Whilst thinking about the best way to implement a feature for editors to report on unused content, it dawned on me that creating a slice for ‘unused content’ would be incredibly easy
- PowerSlice already has a well-thought out user interface
- PowerSlice allows editors to very quickly jump to managing content using the standard EPiServer interface / good for if you want to find and then delete content
I’ve put together two slices, to help editors find unreferenced blocks and media, using standard methods from the EPiServer IContentRepository interface.
Unused Blocks Slice
Unused Media Slice
These slices and PowerSlice were such a good solution that I’d argue that PowerSlice should be bundled out of the box with a Find install. It could perhaps form the basis of a new and more flexible content reporting function? Reporting is something that is in need of a little love in EPiServer 7/8.
One of the nice features that came along with the new CMS editing interface from EPiServer 7 is the ability to define icons for Pages and Blocks. These icons are used within the new editing interface and give editors a more visual way of deciding which is the right content element to use and create in their site.
The Alloy Templates starter pack contains a selection of purpose designed images, and demonstrates how useful this can be.
The horrible reality that I’ve found is that often designing these icons becomes a low priority task for designers and that the below is an example end result! Which lets be honest, doesn’t really help editors too much.
As part of the project we’re working on at the minute at Marie Curie, we’ve designed a suite of 55 icons for our own implementation. However, being the nice kind-hearted souls that we are (it comes from working in a charity), we’re sharing our work in the hope that fellow CMS implementors will them useful.
* The icons are a derivative of an icon set by Michael Reimer from http://www.bestpsdfreebies.com. If you’re in need of any other icons, you should check out his site.
Recently we installed the New EPiServer Find so our editors could benefit from the sleek new interface from which they could view and optimise our user’s search journeys.
Installation on our DEV machines was simple and performed through Nuget. However, after deployment we noticed that our upstream environments were broken (obviously we didn’t deploy as far as production!)
The environments were throwing the following exception on Initialisation.
The system cannot find the file specified.
at EPiServer.Find.UI.FindInitializationModule.Initialize(InitializationEngine context)
The EPiServer Find.UI is dependent on the following libraries
These libraries are a part of MVC4 / WebAPI. I’m guessing that the Find UI uses WebAPI for delivering some of its goodness.
A solution is detailed here, but in summary you have two choices:
- The wrong way- Install MVC4 on your build server / target environments. The MVC4 installer will add these libraries to the GAC, so your application will be able to resolve them.
- The right way – Include these dependencies as part of your application using Nuget. Install the
The right way means that your application is portable and is not dependent on system components being deployed on each server environment. Additionally the
EPiServer.Find.Nuget package should explicitly list
Microsoft.AspNet.WebApi.WebHost as a dependency. Put it on the backlog please Find team