Try our conversational search powered by Generative AI!

Problems with the IValidate<T> interface after upgrade


I am having some problems with the IValidate interface after upgrading to EPiServer 7.5. When we were running EPiServer 7, we created some validators for content types preventing them from beeing published if some properties are empty. These validators are only fired when saving the page. After upgrading to EPiServer 7.5, these validators are fired when creating the page, so it stops the creation for the page. What is changed here between EPiServer 7 and EPiServer 7.5? I guess I can check for ContentLink being null or empty, but it would be nice to know if this is a bug or by design before I implement this change.

Aug 18, 2014 9:17

For people having the same problem, this har been registered as a bug:

It works fine in EPiServer 7.5, but with the latest update it does not work 

Aug 20, 2014 12:20

I am having the same problem as this when trying to validate a block type.  I have tried testing for the item ID being greater than zero.  At creation its ID will be zero. So my Validate() method looks like this:

IEnumerable<ValidationError> IValidate<SoundCloudBlock>.Validate(SoundCloudBlock instance)
    var contentItem = instance as IContent;
     if (contentItem.ContentLink.ID > 0)// Test if it has been created yet
        /* ..... */

Does this work here?

Nov 06, 2014 15:49

Unfortunately, this doesn't work across the board.  When creating a new block in a content area by clicking on "create a new block" at the bottom of the content area in on-page edit mode, the block gets created and published in one go, so if you test for the ContentLink.ID being greater than zero before validating, you will miss this scenario and an editor can create a new block, avoiding your custom IValidate validator and publish the block without realising it.

Nov 06, 2014 16:44

I can not fully understand why the behavior needs to be different when creating/adding Block from ContentArea or if not. I have reported this as a bug to EpiServer (it was a while ago and nothing has happened yet). I guess the reason for this is that, with the current solution, has the block to be created/published first to be able to connect/add it to the content area. There must be solution available to add uncommited/unsaved blocks to ContentAreas.

In my case is the problem that I have designed nice BlockEditor views. They are not used when adding Block from ContentArea (works fine when creating block from block gadget, +-sign or "New block").

I hope this gets fixed soon since many user prefer to create the block using "Create new block" in the ContentArea. (And I don´t want to disable it yet since this is the most logical workflow)

Edited, Nov 06, 2014 17:03

I agree.  I can't see the reason for changing the creation interface depending on where you start the creation journey.  Also, publishing a block on creation without viewing it first by using the ContentArea method seems risky and illogical to me.

Nov 06, 2014 17:08

Yes, It's a risky solution and my guess is that this also might be the reason that we sometimes get blocks thats has "no parents". Might be due to something went wrong after creating the block and before adding it to the ContentArea in the "Create block in ContentArea"-workflow. These "parentless" blocks show them selves when when creating a new page or block. Disappears when other blocks is added to the page. (By the same. It´s the same risk/problem for images since they auto publish by default)

Well... offl topic now. Sorry about that. Just want to confirm that you a solutions you come up with will probably not work when it comes to the "Create block in ContentArea"-workflow.... and as I already said I hope this will be fixed soon.

Edited, Nov 06, 2014 17:18
This topic was created over six months ago and has been resolved. If you have a similar question, please create a new topic and refer to this one.
* You are NOT allowed to include any hyperlinks in the post because your account hasn't associated to your company. User profile should be updated.