EPiServer null property values for saved but unpublished pages
Recently I have been working on an EPiServer 6 build. One of the requirements for this build to manage time table data.
I am not going to go into the full requirements but we are using PageTypeBuilder for our entity objects and using the EPiServer page tree as a content modelling repository for our entities. Please see Mark Rodseth’s blog post detailing this approach here.
One of the reasons for the approach is to cut development time as all of the entities can be managed through EPiServer using PageTypeBuilder and the edit mode editing interface.
The content repository we are developing is in a complex structure and will more than likely confuse the editors.
To solve this issue I have been developing an edit mode plugin that will provide a user friendly interface to populate all of the relevant relational page tree entities.
Does this make sense so far? Excellent
The plugin I have created allows the user to create pages in a saved state and then publish them in batches when they are happy.
The plugin also contains many drop downs lists and list views which are populated from various areas of the content repository.
Are you still with me? Now I will try and get to the point
I am using DataFactory.Instance.FindPagesWithCriteria calls to get entities of different page types and criterias.
The issue I have is that I have pages in the page tree that are in a saved state and have also never been published.
The FindPagesWithCriteria call returns the saved pages in a PageDataCollection object which is exactly what I want to happen, Yay.
The issue is that all non meta data properties have null values even though the page has these properties set .
After some digging around I figured out the problem is caused because the PageLink (PageReference) property of the PageData object has no WorkID specified (remember the page is in a saved state and has never been published).
I haven’t bothered to reflect this in great detail but I would assume that as no WorkID is specified the code is following a different logical route.
I am sure an EPiServer employee could provide detailed information on the reasoning for this , but to be honest I can’t be bothered to look into the inner workings.
I am sure this issue has been found and solved many times before but I thought I would blog about it just in case any developers were not aware of this GOTCHA.
To resolve the issue I have created some extension methods for the DataFactory class which will force a PageData object to be inline with the latest version.
Extension methods are below and are referencing PageTypeBuilder types. If you are not using PageTypeBuilder ask yourself WHY as you should be
The project I am working on has some helper classes to perform various different criteria based searching, some using FindPagesWithCriteria solely and others using a mix of FindPagesWithCriteria and LINQ.
These classes are being used in the live view of the site and in edit mode. In the live view of the site everything works as expected as the user will only be able to view Published pages.
Within my plugin I am having to determine whether the user is in edit mode and if so call the extension methods to make sure the PageData objects are populated correctly.
An example of calling one of the extension methods is below:
Initially I wasn’t sure whether the access rights rules that are applied in all of the various PageData retrieval methods were causing the issues but that doesn’t seem to be the case.
I then started to think this may be a bug, but I am starting to think this is possibly by design and it is just the case that we are using EPiServer in a way that it have not been designed for.
Are we the only agency to suffer this problem or have any other agencies used a content repository entity approach with custom administration interfaces? And if so have you suffered the same problems and created alternative solutions?
Thanks for reading this far, my blog style is not the greatest but I hope I have explained myself well enough and you have understood the point of my post.
There was some serious hand banging the other day troubleshooting the issue.
All code is provided as is and I accept no responsibility if it doesn’t work as you would expect. You should always test your implementations yourself