EPiServer 10 – Restrict any Block Types on XHtmlString property using the Validation Attribute

I couldn’t find a similar solution online as I believe there is an emerging pattern where we are now instructing clients to drag EPiServer Blocks into Rich Text editors.

Requirement:

As an Editor I want to limit certain blocks types from being dragged into the rich text editor

Solution #1:

Apply this attribute to any of your xhtml properties to enable to validation functionality

[Display(Name = "Text", GroupName = SystemTabNames.Content)]
[XHtmlStringAllowedBlockTypes(new[] { typeof(TextBlock), typeof(ImageBlock) })]
public virtual XhtmlString RichText { get; set; }

 

Implement the following attribute where your other validation attributes reside.

 public class XHtmlStringAllowedBlockTypes : ValidationAttribute
{
private readonly Type[] allowedTypes;
public XHtmlStringAllowedBlockTypes(Type[] allowedTypes)
{
this.allowedTypes = allowedTypes;
}

protected override ValidationResult IsValid(object value, ValidationContext context)
{
var contentData = context.ObjectInstance as IContentData;

if (contentData != null && contentData.Property[context.MemberName].Value is XhtmlString)
{
var richTextProperty = (XhtmlString)contentData.Property[context.MemberName].Value;

foreach (ContentFragment fragment in richTextProperty.Fragments.Where(x => x is ContentFragment))
{
var content = ServiceLocator.Current.GetInstance<IContentRepository>().Get<IContentData>(fragment.ContentLink);

foreach (var allowedType in allowedTypes)
{
if (allowedType.IsInstanceOfType(content))
{
return new ValidationResult(string.Format("You cannot add {0} to {1}", content.GetType(), context.MemberName));
}
}
}
}

return ValidationResult.Success;
}
} 

 

References:

http://world.episerver.com/documentation/Items/Developers-Guide/Episerver-CMS/9/Content/Properties/Property-types/Writing-custom-attributes/

http://world.episerver.com/documentation/Items/Developers-Guide/Episerver-CMS/9/Content/Validation/

EPiServer 7.5 – Exception – More than one content model is assigned to the guid

When running an EPiServer site and you get the exception “More than one content model is assigned to the guid”. This is usually because you’ve changed a namespace.

There will be a reference to the old namespace cached somewhere so do the following:

1) Clear your bin folder

2) Clear the ASP.NET Temporary files folder under the framework version your project is using

Architect – Our Website Branching Strategy @ Marie Curie Cancer Care

What we use

We use a combination of Git, EPiServer and have a fairly small team which makes the challenge of using the standard pattern of Gitflow a little more difficult. So we use a part of it to help us get an excellent balance between being responsive to post production issues and minimal branch maintenance.

Challenges

Due to EPiServer controlling it’s Dynamic Data Store via code, we have to be a little more careful when switching branches on a given environment. This is because EPiServer will hide or show properties depending on what is reflected in the latest code. This could lead to impacting someone else’s work.

We do currently experience this in the Develop environment where one developer may have a code base with a deleted or renamed property. This will cause an issue with another developer who has the original property definition. So both sets of code bases will be fighting each other to set that property on the database which results in some exception behaviour when running the website.

An old colleague James Goldswain messaged me with this:

Check out the enableModelSyncCommit=”true” setting in the Episerver.config file, it enables you to disable the auto updating of properties etc, when developing in a team, found it out the hard way ūüôā

We have a limited number of environments due to resources and set up time. In an ideal world we would have a new environment spin up from either a feature or hot fix branch so QA can test in isolation from everything and everyone else.

We cannot deploy hot fix or feature branches to the QA environment because that will create blockers for other members of QA. Our QA environments require all testable features to be merged to the develop branch first before deployment.

Strategy

We adjust our branch strategy from Gitflow so we:

  • Do not block any member of the scrum team from working on any environment.
  • Make the effort to keep feature and hotfix branches as short as possible in order to avoid developer going dark
  • Sync both Master and Develop branches at the end of every sprint to ensure everything is up to date. If we are going Gitflow correctly then we shouldn’t need this. (There is an occasionally extra merge commit that moves from Master to Develop due to hotfixes)
  • Feature and hotfix branches get merged as soon as possible to minimise timeline regression.
  • QA and UAT never test¬†on¬†feature or hotfix branches, only Develop and Master.
  • Our team is small enough to warrant not using the release branch workflow as¬†we¬†rarely get any issues with unfinished work at the end of the sprint.

We have four types of branches we use. The Master and Develop branches are static. Hotfix and features branches can be created any number of times and typically have short life spans before being dumped or merged into one of the static branches.

Master branch

According to Gitflow this branch represents our production ready code. We should be able to push code from this branch into production at any time.

However due to our challenges, we also use this branch to deploy to both Staging and Production. This effectively makes it our UAT and Release environments. We push to Production at the end of every sprint and also when hot fixes are merged in.

Develop branch

This is the bucket branch for any development changes that are not post production issues and not significant enough to have their own feature branch.

The branch is also used for both the develop and QA environments. This allows for QA to test singular user stories and provide feedback during the sprint.

Hotfix/xxx branches

Bugs and issues discovered during post production are worked on hot fix branches created from Master. Completed hot fix branches are then moved into both Master and Develop. Once the work is approved we then delete the branch.

Feature/xxx branches

Significant features that can be worked on in isolation are done in their own branch. We create this off Develop. Good examples include a blog or a newsletter sign up. These branches are then worked on by the developers and then must be merged into Develop once they are ready for testing.

These branches¬†should only exist for the length of a sprint. If it needs to exist into the next sprint then ‘commits’ on the Develop branch is merged up into the Feature branch in order to keep it up to date.

Property Injection & Action Filters in EPiServer 7 CMS

I spent a bit of time putting in some custom implementation to support Property Injection on to my Action Filters before realizing that EPiServer 7 already provides this functionality for me. Doh.

In order to take advantage all you need to do is set¬†your DI controlled interface to the generic type property of¬†the Injected class. This will lazily set the¬†interface when the property is used…awesome.

public class CustomFilter : ActionFilterAttribute
{
public Injected<IService> Service { get; set; }
}

Manipulating an EPiServer Page Programmatically

Creating a Page

Here’s how you can create a page in code from a page type you’ve already defined.

First create a new instance of the page type under another page in the form of a link:

var newBlogPost = ContentRepository.GetDefault<BlogPostPage>(parentLink);

Then set whatever properties you wish to the newBlogPost object.

newBlogPost.Subject = "Creating an EPiServer Page Programmactically";
newBlogPost.Content = "Meta";

Finally call the Save method on EPiServer’s content repository.

ContentRepository.Save(newBlogPost, SaveAction.Publish)


Updating a page

The structure to updating a page is thankfully very similar to creating one.

Load the page you wish to update from the Content Repository. 5 is the id of the page.

var contentReference = new ContentReference(5)
ContentRepository.Get<BlogPostPage>(contentReference);

Create a writeable clone of the update. This allows you to update it’s properties:

var clone = (BlogPostPage)page.CreateWritableClone();

Update a properties of the cloned page

clone.Subject = "Creating an EPiServer Page Programmactically";

Call the Content Repository to Save the page and public it at the same time:

ContentRepository.Save(clone, SaveAction.Publish);


Troubleshooting

When creating a new page and / or block you may get the following exception:

The INSERT statement conflicted with the FOREIGN KEY constraint 'FK_tblContent_tblContentType'. The conflict occurred in database ' ', table 'dbo.tblContentType', column 'pkID'.

This commonly gets throw when there are two developers working against the same database but have different versions of the page / block you are trying to save.