Ben  McKernan
Feb 4, 2015
(9 votes)

The new and improved allowed types

The latest pre-release version of the EPiServer.CMS.UI package contains the new and improved allowed types attribute. If you are feeling adventurous then upgrade and try it out. The improvements are:

  • Clicking the "create a new block" link of a content area will now filter the block types that appear based on allowed types.
  • It is now possible to restrict a subset of the allowed types.
  • Interface types are now supported.
  • UI descriptors are now automatically generated for content types classes and their base classes.
  • Validation occurs for allowed types in the content area.


Most of you have probably read previous blog posts from myself and others on the allowed types attribute and its usages and its limitations. For those who don't know what it is, it is an attribute that can be applied to properties on your content type model in order to control what content types that property can accept. For example, only allowing images on a gallery property. The code looks like this:

[AllowedTypes(new []{ typeof(ImageData) })]
public virtual ContentArea Gallery { get; set; }

In the next major version of EPiServer (EPiServer.CMS.UI 8.0.0) we have made a lot of improvements to the allowed types in order to support requested features and fix problems in the current version. The next version is currently available in the nuget feed as a pre-release package if you are interested to give it a test run.

Creating Content from the Content Area

The biggest problem with the current implementation of the allowed types, and also the most up-voted bug on EPiServer World (110190), is the fact that allowed types doesn't filter the list of content types when creating a block from a content area; it only affected drag and drop. This has now been fixed meaning that it is no longer possible to add disallowed types to the content area either via drag and drop or the create link.

Validation of Allowed Types

The content area has also been modified in the core so that, when saving or publishing, it validates whether it contains any types that are not allowed. This ensures that changes to a content area via code also follow the allowed types restrictions.

Restricted Types

An additional feature we have added to the allowed types attribute is the ability to specify a subset of types that should not be allowed. For example, it is quite common to have a content area which should accept all blocks except for blocks which don't fit; i.e. the jumbotron block in the alloy templates is too big to be rendered in the sidebar. The restricted types are passed through as the second constructor argument on the allowed types attribute. The code looks like this:

[AllowedTypes(new[] { typeof(BlockData) }, new[] { typeof(JumbotronBlock) })]
public virtual ContentArea RelatedContentArea { get; set; }

Automatic Generation of UI Descriptors

Currently the system automatically creates UI descriptors for all the registered content types. This means that you can specify a particular content type as an allowed or restricted type without the need to create the UI descriptor yourself. However this was not the case for base classes and thus you needed to create a UI descriptor for any base classes you wanted to specify in the allowed types. In the next version we have refactored the automatic generation so that base classes are also generated, meaning that you can specify any class type without needing to create a UI descriptor yourself.

If you have a type that you want to create a UI descriptor for in order to, for example, have a custom icon. Then you can still create the UI descriptor and it will take precedence over the automatically generated one.

Interface Support

We have also made changes to support UI descriptors for interfaces, meaning that it is possible to specify an interface type as the allowed type. For example, if you had an interface for blocks that should appear in the sidebar then the code would look like this:

[AllowedTypes(new[] { typeof(ISidebarBlock) })]
public virtual ContentArea RelatedContentArea { get; set; }

However, unlike the content type classes and their base classes, UI descriptors are not automatically generated. So in order for the above to work you will need to create a UI descriptor. 

Feb 04, 2015


Tarjei Olsen
Tarjei Olsen Feb 4, 2015 10:59 AM

How about creating private blocks for/under a page; is the list of available block types filtered according to the AvailableContentTypesAttribute on the page type definition? That would be super sweet, now that we can let editors create private blocks for pages.

Ben  McKernan
Ben McKernan Feb 4, 2015 11:08 AM

Do you mean creating blocks directly under a page? We don't have support for that. Local blocks are still created under the local folder in the content assets tree. The list of available types is filtered based on the allowed types attribute only since available types only.

Feb 4, 2015 11:20 AM

EPiServer.CMS.UI 8.0.0-pre-000379, blocks are not filtered. I cleared the browser cache, and restarted the IIS.

Ben  McKernan
Ben McKernan Feb 4, 2015 01:03 PM

Sorry, seems I was a bit eager to get the blog post up. The latest pre-release package (EPiServer.CMS.UI 8.0.0-pre-000384) is now available on the nuget server.

Tarjei Olsen
Tarjei Olsen Feb 4, 2015 01:10 PM

@Ben, yes. When an editor wants to create a block that belongs to a page, every single block type is presented as an option, and that is not editor friendly at all in a solution with many block type definitions. It would be nice if the list of available blocks could be filtered, the same way available page types is when creating new pages. From code it would be natural to define this kind of filtering using the existing AvailableContentTypesAttribute.

As I understand it, private blocks are created under a page in a ContentAssetFolder. The ContentAssetFolder has a property called ContentOwnerId, which is a reference to the page. With that one could do filtering using an instance of the IAvailableContentTypes's ListAvailable method. This needs to happen in the RestStore named "contenttype", I imagine. I did some reflection on the rest store class ContentTypeStore, and this is where this needs to be implemented as far as I can tell.

Feb 4, 2015 01:29 PM

@Ben, pre-000384 throws the following exception: "AllowedTypesAttribute is only supported on ContentReference,ContentArea,LinkItemCollection". I need to use the AllowedTypes attribute on XhtmlString field as well.

Feb 4, 2015 02:50 PM

@Dejan: As the error message states, there is currently no support to handle this for an XHtmlString. Actually, the error message is even a bit faulty since the UI does not handle LinkCollections in a good way either. The problem with both Link Collections and XHtmlString is that they are a bit more advanced than just a contentreference (or list of content references as the content area can be treated as). Not saying that it's not possible to add support, but it's a bit more complex and I think that we need more feedback to be able to implement it in a good way.

Let's take some examples for an XHtmlString just to bring up questions that needs to be answered to be able to implement support for an XHtmlString in a good way. Let's say that you annotate an XHtmlString with AllowedTyped(new Type[]{typeof(SomePage), typeof(SomeBlock)}). This raises some questions:

1. Should it be allowed to create an external link in the editor?
2. Should it be able to create a link to content items that have a URL that are not type of (SomePage)?
3. Should you be able to add links/inline media (for instant images) that are not part of the AllowedTypes?

I'm assuming that the most commonly desired behavior is to still allow links and media to be added to the XhtmlString, and just preventing which content types can be added as inline content blocks but it would be nice to get this verified.

Feb 4, 2015 03:16 PM

@Linus, thanks for reply.

I was pleased with how AllowedTypes worked with XhtmlString in EPi 7.19.2, and EPiServer.CMS.UI 8.0.0-pre-000379.
If you could keep the existing functionality in EPi 8, and improve small drag&drop glitches in Chrome/Firefox, that would be perfect :)

Should it be allowed to create an external link in the editor? Yes
Should it be able to create a link to content items that have a URL that are not type of (SomePage)? Yes
Should you be able to add links/inline media (for instant images) that are not part of the AllowedTypes? I would say yes :)

"I'm assuming that the most commonly desired behavior is to still allow links and media to be added to the XhtmlString, and just preventing which content types can be added as inline content blocks but it would be nice to get this verified."
That would be great

Feb 4, 2015 07:07 PM

Maybe I'm a bit confused Dejan, but AllowedTypes has never worked with XhtmlString. How did you get that to work?

Feb 4, 2015 08:23 PM


I've created a new EPiServer MVC website using Visual Studio extension, upgraded EPi nuget packages to 7.19+, and simply used AllowedTypes on XhtmlString.
Here's how it works:

Tested on Windows and Mac.

Feb 4, 2015 11:19 PM

Ah nice. Never considered AllowedTypes for XhtmlString, but I guess that makes sense. We usually try to stay away from dropping content into XhtmlStrings.

On a related note. Would be nice if DefaultDragAndDropTarget worked for ContentAreas, now it only seems to work for ContentReference. This was reported as a bug (Incident DI-142361), but was dismissed since someone couldn't reproduce the problem, even though the support team was able to.

Jun 22, 2015 01:58 PM

I'm trying to work my way away from Dynamic Content plugins and rather use specific blocks in XhtmlString, but I'd rather not open up for all block types. So a way of restricting what blocks types should be allowed in a XhtmlString would be great.

Although... I'm sure the editors would be thrilled over being able to drag-n-drop all kind of stuff into whereever they'd like... :-) Feb 12, 2016 01:01 PM

How do you use the new EPiServer.Forms with AllowedTypes?


[AllowedTypes(new []{ typeof(<>< EPiServer.Forms ? >>) })]


Patrick Monslaup
Patrick Monslaup Feb 28, 2017 10:46 AM

@Patrick Nodrin, 


Please login to comment.
Latest blogs
Optimizely SendGrid SMTP host is deprecated

SendGrid is a services for sending email that is included in Optimizely DXP. Previously was the recommended SMTP server to use,...

Tomas Hensrud Gulla | Dec 4, 2022 | Syndicated blog

Hosting Optimizely CMS 12 on Docker Engine

Since Optimizely CMS can now be deployed as a Docker container, here is a demonstration of building, running and scaling an Optimizely CMS 12 site ...

Stefan Holm Olsen | Dec 4, 2022 | Syndicated blog

How to use CacheTagHelper with content areas in Optimizely CMS 12

I might be going out on a limb here - if you have a better solution, feel very free to share it!  Upgrading your Optimizely web application from .N...

Andreas J | Dec 2, 2022

The 1001st Piece in your 1000 Piece Puzzle: .NET Default Interface Functions

I was recently working with a client who wanted a reasonably large subsystem added to Optimizely that would add automated management to their...

Greg J | Nov 28, 2022 | Syndicated blog