Mark Everard

Hello, I'm Mark – a PhD physicist turned developer / architect.

Find(ing) missing dependencies when installing New EPiServer Find

with one comment

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 cause

The EPiServer Find.UI is dependent on the following libraries

  • Newtonsoft.Json.dll
  • System.Net.Http.dll
  • System.Net.Http.Formatting.dll
  • System.Net.Http.WebRequest.dll
  • System.Web.Http.dll
  • System.Web.Http.WebHost.dll

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:

  1. 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.
  2. The right wayInclude these dependencies as part of your application using Nuget. Install the Microsoft.AspNet.WebApi.WebHost package.

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 :)

Happy Finding!

Written by Mark

June 26th, 2014 at 9:54 am

Posted in ASP.NET,EPiServer

PageStructureBuilder for EPiServer 7.5

without comments

If there was an award for the best EPiServer extension produced by a member of the World community; that didn’t gain the recognition it deserved. Of course, my own Personalisation Engine would win hands down ;)

Coming in a very close second would be one of Joel Abrahamsson’s masterpieces. This one lesser known than PageTypeBuilder, Truffler or PowerSlice, but one that solves a common CMS challenge equally as elegantly.

PageStructureBuilder was a solution Joel put together to automatically organise EPiServer pages, meaning you could define areas of your site that would ensure its content was arranged into a predefined structure. The obviously use-case here being ‘news’ type pages that would be stored in a date hierarchy (Year > Month > Day > News Article).

The solution was originally built against CMS6 and PageTypeBuilder, so I’ve forked Joel’s original solution and upgraded it to work against EPiServer 7.5 and the native strongly typed page implementation.

Available on EPiServer Nuget now.

 

Written by Mark

June 10th, 2014 at 10:00 am

Posted in Community,EPiServer

Configurable Content Feeds for EPiServer 7.5

with one comment

AKA – another (and better!) RSS/ATOM feed for EPiServer. Developing an RSS feed for an EPiServer CMS system is actually quite a simple task and there is already a good amount of information and community options that you can download and use.

However, the particular problem I was presented with required something a little more than what was already out there, so I took the opportunity to build a fuller solution based on CMS 7.5. This may be the last RSS feed module for EPiServer that you’ll ever need!

This effort started out with a requirement to integrate content from EPiServer CMS to an IBM WebSphere Commerce system (WCS). WCS contains out-of-the-box functionality to consume external content from a publishing feed presented in an ATOM format so this seemed like a suitable integration method.

The design of the pages and content area to be shared required that we shared only specifc HTML snippets from the CMS to the WCS system. This fitted in perfectly with the new Content Blocks in EPiServer 7; meaning we needed a content feed that could share not only pages but also content blocks. This additionally  meant that content blocks needed to be routed so the individual output could be consumed by the external WCS solution.

Also the new Media system in EPiServer 7.5 allows the content feeds to handle and output media items in a simpler way. Its all IContent man!

Editor functionality

  • Editors can create multiple feeds (a feed is a Page Type)
  • Feeds contain a date ordered (most recently published first) list of content items
  • Editors can specify whether a feed is delivered in RSS or ATOM format
  • Editors can specify how many items appear in the feed.
  • Editors have granular control over what content items are shared. They can include any of the following in a single feed.
    1. Descendents of a specified page in the page tree
    2. Child blocks contained within a specified content folder
    3. Child media items within a specified media folder
    4. Any number of individually selected pages, blocks or media items, via a ContentArea property
  • Blocks included in a feed are externally routed so their HTML output can be consumed by external systems.
  • Feed pages have a partial renderer meaning they can be dragged into Content Areas to display an RSS feed logo and link.

 

event-feed

Extending and modifying

There isn’t much to do as a developer beyond installing the package. Note. I’ve only tested this against an MVC Alloy solution. It should play nicely with WebForms but I’ve not tested!

  • You may want to change the partial renderer view for a Feed Page. This can be found in /modules/Chief2moro.SyndicationFeeds/Views/Partial.cshtml

event-feed-partial

  • You can override the description that is shown along with each item in the feed by providing a method for the SetItemDescription delegate. By default this is of the form ‘An src link to content with id = {content.ContentLink.ID} and name = {content.Name}’

Other integration considerations

There is one item not included in the solution which you may need to consider . Whilst the feed presents absolute urls from the feed to pages, blocks and media.  Any content within a page or block that contains editor set hyperlinks, such as an XHtml property will most likely contain relative urls. If these are consumed and presented on an external website you’ll get a serious case of the 404′s.

You can get around this by rewriting any outbound urls in the content to be absolute. The solution I used was to set up a rule in my favourite tool IIS UrlRewrite. This intecepted all outbound html from a particular path and rewrites all links to be absolute. This isn’t the most flexible solution as it relies on outbound scanning on specific paths. It may be better to add something into this solution, but this isn’t something I’ve looked at yet.

It’s on Nuget

The source code is available at https://github.com/markeverard/Chief2moro.SyndicationFeeds – I’m happy to accept Pull requests

A package (currently v1.0.0.1)  is (soon to be – when its approved) available in the EPiServer Nuget Feed - http://nuget.episerver.com/ - search for CHIEF2MORO.SyndicationFeeds

Happy Feeding!

Written by Mark

May 30th, 2014 at 1:30 pm

Posted in ASP.NET,C#,EPiServer