Mark Everard

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

Archive for the ‘ASP.NET’ Category

Publish all the things!

with 5 comments

If you’ve seen some of my recent posts you’ll know I’ve been playing around with WebHooks. These are simple HTTP requests to endpoints allowing services to exchange data and events.

Integration Platforms as a Service

Those of you cool kids will have known about IFTTT (If This Then That) for some time. It’s a online tool that acts as a way to glue a huuuge number of online services together into simple workflow pairs called ‘recipes’. Each service can provide a number of triggers to the platform, which are then linked to actions provided by other services.

I’ve got a number of personal recipes set up, some useful some not. but all of them are good fun!

  • If somebody tags me in a picture on Facebook, then upload the picture to my OneDrive account
  • If one of my team creates a new GitHub repository then email me
  • If I arrive or leave my office then log the time in a Google Doc.
  • If an astronaut is launched into space then send me a notification

Whilst IFTTT targets individual users, other iPaaS platforms focus more towards business and enterprise. These will become increasingly useful and popular as a cheap means of system integration and data exchange. For example – if somebody submits a payment via the organisation’s payment gateway, log the entry directly into the cloud-based finance system. You won’t need development teams to set these up, just someone to configure the data exchange / webhook endpoints.

Publish your home!

I’ve been playing around with smart home devices (tado smart heating and WeMo lights and switches). I wanted to experiment a little with the API’s they offered.

One of the channels IFTTT offer is called the Maker channel. This is a user specific channel that will accept http triggers to an endpoint and can also make requests to a specified endpoint. It allows you pass up to 4 data points from a trigger or to an action.


Publish…… and there was light, and slippers.

As I’ve demonstrated before, adding webhooks to an existing ASP.NET app is straightforward. I decided I’d hook an Episerver solution up to an IFTTT maker channel, meaning when I clicked the publish button I could make all manner of amazing things happen, like turning my lights on :)

The code to do this is straightforward (see below). I’m using an Episerver initialisation module to hook a handler for the Content Published event. I’ve also built a simple helper method to call the Maker channel API. To use this you’d just have to add in your own API key that you get when you configure the Maker channel on IFTTT.

Written by mark

March 7th, 2016 at 11:00 am

Posted in ASP.NET,C#,Code,EPiServer

RSS feeds for Episerver

without comments

I’ve released a few further tweaks to my RSS / ATOM add-on for EpiserverCHIEF2MORO.SyndicationFeeds.

Whats new in version 3.0?

On request filtering

I’ve taken another look at filtering, which is a feature included from version 2. I’ve modified the inbuilt IFeedContentFilterer to allow Feed pages to filter items by category via querystring parameters. This has caused a breaking change (and helped me understand how abstractions can help stable API design).

The feature allows editors to set up single feeds and for those feeds to provide subsets of data by responding to Category names that are passed via a comma separated querystring value. e.g.,Blog,Technology.

The default FeedFilterer has also been modified so that a content item has to be a member of all categories (both querystring and editor set) to appear. Previously it had to be a member of just one category filter.

Editor set cache

Each feed page now includes a new property allowing an editor to cache the feed output for a given number of seconds. This is to help performance for those feed pages on sites with a large amount of content.


I made some minor amends to help the feeds to validate, and made sure I correctly understood the RSS / ATOM specification in respect of LastUpdated and Publish dates

It’s on Nuget

The source code is available at

A package (currently v3.0.0.0) is available in the Episerver Nuget Feed – – search for CHIEF2MORO.SyndicationFeeds

Written by mark

February 3rd, 2016 at 10:00 am

Posted in ASP.NET,C#,EPiServer

Using WebHooks in an EPiServer solution

without comments

WebHooks are a way of connecting internet / cloud services together. They allow websites to communicate with each other via HTTP callbacks. Services can subscribe (via HTTP) to receive notifications from publishers about a specific event. Publishers, manage these subscriptions and then on each event push notifcations via an HTTP Post to each receiver, at an endpoint defined during subscription.


ASP.NET WebHooks

Microsoft have recently released a WebHook framework for ASP.NET that gives you a pattern for:

  • Handling subscriptions from interested subscribers
  • Sending subscriptions to publishers
  • Sending published messages to subscribers
  • Handling publisher messages from subscribed services (via Receivers)

Along with the basic framework, they have also provided implementations for some very common services like Dropbox, GitHub, Instagram, PayPal, Pusher, Salesforce, Slack, Stripe, Trello, and WordPress

Webhooks in EPiServer

What would an EPiServer implementation / usage of WebHooks look like?

  • Publish content events to subscribers (system to system integration)
  • Publish Form data inputs to external systems
  • Publish / Subscribe to Catalog events and changes from integrated commerce systems (Stock control and pricing)
  • Subscribe to events from external systems (Payments)
  • Subscribe to external content events – Instagram / social

Ascend London

I was invited to talk (along with fellow EMVP Khurram Khan) at the technical track at EPiServer Ascend London 2015. You can download the slides from Slideshare.

As part of a presentation I put together a simple solution demonstrating an EPiServer site with an Instagram receiver that provided a solution to the below user story.

“As a content editor, I want images that are uploaded on a social channel (Instagram) and tagged with ‘ascend15’ to be available in my content management system so I can use them on my awesome website”

The solution contained the following elements:

  • A receiver accepting notifications from Instagram when a image with a tag of ‘ascend15’ was added (using the ASP.NET WebHook framework)
  • A Dynamic Data Store implementation to store the number of notifications received
  • A scheduled job: to request, download and import images into EPiServer as MediaData / IContent items

The solution and even the scenario was a little contrived, so I’m not going to show the code (though it you really want it just drop me a line). It did however work on the day, which when you’re trying a tech demo that relies on the cloud and external services and also your own code; is always nice :)

Written by mark

November 11th, 2015 at 10:49 am

Posted in ASP.NET,C#,EPiServer

Chief2moro.ImageDataExtensions now available for EPiServer 9

without comments

Another short, sharp blog post to note that a version of the CHIEF2MORO.ImageDataExtensions package which is compatible with EPiServer 9 is now available in the EPiServer Nuget Feed. Fellow EMVP Marija Jemuovic did all the hard work, and I got the easy part in blogging about it.

There not much more to say, so here is a space filler…..




Written by mark

October 27th, 2015 at 9:00 am

Posted in ASP.NET,C#,EPiServer

Enhanced RSS / ATOM Feeds for EPiServer

without comments

I’ve released a new version of CHIEF2MORO.SyndicationFeeds. Along with upgrading to EPiServer 9, I’ve also taken the opportunity to add a few additional features based on some feedback and my own real usage.

Advanced Filtering

The library now contains the IFeedContentFilterer interface which provides an extension for any custom filtering you may want to achieve (for example – removing items with empty description’s). The default implementation filters via the EPiServer FilterForVisitor filters (Published status, Access rights, Has a template), though ignores the HasTemplate rule for blocks, so they can still be exposed. It also filters on EPiServer categories and ContentType, both of which are selectable by an editor on an instance of the Feed PageType.

Changing each Item’s summary in the feed.

You can now provide your own implementation of IFeedDescriptionProvider which is an interface that describes how a content item’s feed summary / description is derived. This allows you to provide your own implementation of where the items summary is stored. This may for example be from a common page property across all content types, or may be specific to each content type. By default, each item has a summary like ‘An src link to content with id = {content.ContentLink.ID} and name = {content.Name}’. The IFeedDescriptionProvider extension replaces the previous SetItemDescription delegate way of overriding the summary / description. The delegate is still available to maintain backwards compatibility but is marked as obsolete.

It’s on Nuget

The source code is available at I am happy to receive feedback and pull requests though I need to make a formal and public apology to Thomas Svensen who did indeed send me a pull request, which I ignored like an extremely bad open source steward….. Sorry :(

A package (currently v2.0.0.0) is available in the EPiServer Nuget Feed – – search for CHIEF2MORO.SyndicationFeeds



Written by mark

October 26th, 2015 at 9:00 am

Posted in ASP.NET,C#,EPiServer

Find(ing) missing dependencies when installing New EPiServer Find

without comments

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

Configurable Content Feeds for EPiServer 7.5

with 2 comments

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.



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


  • 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 – 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 – – search for CHIEF2MORO.SyndicationFeeds

Happy Feeding!

Written by mark

May 30th, 2014 at 1:30 pm

Posted in ASP.NET,C#,EPiServer

Image resizing in EPiServer 7.5 CMS

with 13 comments

Dynamic image scaling is an often sought after feature for interface designers and content editors. Whilst not natively supporting this feature; EPiServer 7.5 CMS contains a neat hidden feature (Thanks @athraen for the heads up) that allows a limited but useful ability to automatically scale your images.

True dynamic scaling, and by that I mean that your http request for an image also contains your requested height, width and cropping options, is a complex operation to perform successfully, just check out the interesting blog posts at Note there is a community integration of ImageResizer.Net with EPiServer 7.5.

The new media editing interface allows in-line preview of uploaded images via a scaled thumbnail representation of the image. These are created automatically by EPiServer for any ImageData content types that are created.  This is achieved via a ImageDescriptor attribute which can be placed on any ‘routed’ blob property (i.e those on ImageData content types).

Thumbnails in the media edit interface

The ImageDescriptor is pretty cool, but not so helpful when you start working with real images with differing aspect ratios.

A simple use case could be that for every uploaded image you want to create a version that has a maximum width of 300 px, which could be used in a site sidebar. The ImageDescriptor as-is forces you to define a height and width at compile time meaning that all uploaded images will be resized to the same width and height specified in the attribute. Any additional height or width will be filled with white-space.

The CHIEF2MORO.ImageDataExtensions nuget package I blogged about previously also contains a couple of additional attributes to help overcome this limitation. Extend your ImageData content object (ImageFile in Alloy) with a few Blob properties for the different sizes and mark up with the attributes. The blob routing feature in EPiServer means that these scaled images are available publically (<imagename>.jpg/image250 and <imagename>.jpg/half). Behind the scenes both of these descriptors use the underlying ThumbnailManager class contained in the EPiServer API.

   [ImageWidthDescriptor(Width = 250)]
   public virtual Blob image250 { get; set; }

   [ImageScaleDescriptor(Percent = 50)]
   public virtual Blob half { get; set; }

The ImageWidthDescriptor only requires you to specify the scaled width and will calculate the height at content publish time from the originally uploaded image dimensions to ensure that the aspect ratio is maintained (so you get no padding / whitespace)

The ImageScaleDescriptor allows you to specify a scale and will calculate the desired height and width from the original image.

Written by mark

February 13th, 2014 at 10:00 am

Posted in ASP.NET,C#,EPiServer

Validating image dimensions in EPiServer 7.5 CMS

with 3 comments

EPiServer 7.5 delivers a completely new digital media management system offering a host of editor enhancements, including integration into the new editing interface, multiple file drag and drop file upload, inline media preview, and drag and drop placement of media into ContentAreas and the Rich-Text-Editor.

From a developer perspective, much has changed too. Media files are not stored through a Virtual Path Provider but as a Blob (Binary Large OBject). This allows media assets to be stored and used in true elastic cloud scenarios, though the default blob provider still saves media files to disk (just as the old VPP system did).

Also new, is that media assets are now treated as first class content items. That is; they inherit from the IContent interface and have code definable properties allowing better definition of media meta data. This is now defined in a strongly typed manner just as you do for other IContent items such as pages, blocks and catalogue nodes and items in Commerce.

Image size validation

A media item has a one-to-many mapping to a file extension, so EPiServer will only associate one IContent class with a particular file extension or collections of extensions. A basic content handling of media data is included in the Alloy Templates demo site, and includes three new IContent classes, inheriting from the core VideoData, ImageData and MediaData objects.

This one-to-many mapping means you have to take a slightly different approach to content modelling media items than you do for page or block types. For example, you may want to have banner images that must have a particular size, or a photo image that requires additional meta data than a standard image. For now you can’t do this. All files of a particular extension have to contain the same metadata.

This means that you cannot validate images for size when you upload them (as you’d restrict every single image with that extension to be that size). Although this feels restricting, it is perhaps the correct decision as media size only matters when you display your content (and although it hasn’t has much love recently, EPiServer does offer an online image editor). It is only when you use your image within a particular presentation layer (page /block) that you really need to constrain it to a definite size.

Validating an image used in context

You can apply validation to any property used within a page or block type via a validation attribute. Media assets are stored as content references in a page or block; with a specific UIHint attribute to allow the editing system to know that you require an IContent inheriting from ImageData.

I’ve put togther a validation attribute that you can add to a ContentReference property which will validate the size of any ImageData content referenced in that property.

   [Display(GroupName = SystemTabNames.Content,Order = 3)]
     [RequiredImageSize(Width = 300, Height = 100)]
     public virtual ContentReference Image { get; set; }

You can specify a height and or a width in pixels. Currently you can only apply this to ContentReference properties but I can see it would also be useful to apply it to ContentAreas – I’ve just not got round to that yet 🙂


The source code is available at

A package containing this validation attribute, along with some other image related goodies that I’ll blog about soon, is available in the EPiServer Nuget Feed – – search for CHIEF2MORO.ImageDataExtensions

Written by mark

February 3rd, 2014 at 11:00 am

Posted in ASP.NET,C#,EPiServer

POSSIBLE.RobotsTxtHandler for EPiServer 7.5

with 3 comments

A few months back I put together a robots.txt handler for EPiServer CMS 7. Technology moves quickly and since then EPiServer have released CMS version 7.5

My generous ex-colleague Marcin ( has forked and updated the package to work with version 7.5. This involved a few minor changes to handle the changes in how sites and site settings are defined.

Its on the Nuget feed already – – search for POSSIBLE.RobotsTxtHandler version 2.0.1

The source code is available at

Written by mark

January 30th, 2014 at 9:17 pm

Posted in ASP.NET,EPiServer