EPiServer did some seemingly minor changes in the latest version of EPiServer CMS, 6 R2. While small, these changes have some unfortunate effects on Page Type Builder. Therefor I have today released a new version of Page Type Builder with version number 1.3.1. This doesn’t fix everything, and the release isn’t as well tested as I would like. On the other hand the changes are minor.
What has changed in R2?
First of all EPiServer added a new value to the EditorToolOption enum. This value is EditorToolOption.Undefined which maps to the integer value –1. This in it self isn’t a problem but what is is this:
var pageDefintion = new PageDefinition(); pageDefintion.LongStringSettings == EditorToolOption.All; //True pageDefintion.Save(); pageDefinition = PageDefinition.Load(idOfJustSaved); pageDefintion.LongStringSettings == EditorToolOption.All; //False pageDefintion.LongStringSettings == EditorToolOption.Undefined; //True
As you can see, when instantiating the PageDefinition class the created object will have its LongStringSettings property set to EditorToolOption.All which is also what default(EditorToolOption) returns. However, after saving it and retrieving it from the database the returned object will instead have its LongStringSettings property set to EditorToolOption.Undefined.
Upon initialization Page Type Builder checks if a page type property (PageDefinition) should be updated by comparing the corresponding attribute with the PageDefinition stored in the database. As the PageTypeAttribute’s LongStringSettings property maps to default(EditorToolOption) if it hasn’t been explicitly specified Page Type Builder will now think that the PageDefinition should be updated. This in turn leads to a much longer start up time than previously as PTB will have to save every single PageDefinition (not just XHTML properties) for which LongStringSettings haven’t been explicitly specified.
To address this I’ve changed the PageTypeProperty attribute so that it’s LongStringSettings property will instead default to EditorToolOption.Undefined. This means that if you actually want it to be EditorToolOption.All you will now have to explicitly specify it.
The other change is that EPiServer added a new method to DataFactory called GetPages. This loads a batch of pages based on a list of PageReferences. While this method fires the LoadedPage event, to which Page Type Builder listens and replaces the loaded page with a typed version, it doesn’t respect if the page has been changed in an event handler. This means that Page Type Builder wont be able to make the GetPages method return PageData objects with the correct underlying type.
This in it self doesn’t break any existing functionality, although it’s of course really sad that PTB can’t intercept calls to GetPages, but it also seems that the FindPagesWithCriteria method have been changed to use GetPages to load pages matching the criteria it’s called with. Therefore PTB will no longer be able to intercept calls to FPWC and replace the returned pages with typed versions
There’s really nothing I can do about this. But to make it easier to tackle this I’ve added an extension method to the PageDataCollection class named AsTyped which will return a new PageDataCollection with pages that are actually of the correct type.
Some logging to debug slow start up
As I started getting reports of slow start up with R2 I noticed that some of the reporters suspected that PageDefinition.FieldOrder (which maps to PageTypeAttribute.SortOrder) was always updated. This isn’t the case but if two properties have the same SortOrder specified in the attribute EPiServer will increment the value of one of them and therefor triggering that PTB will resave the PageDefinition next time the site is started. I’ll look into addressing this further in the future, but for now I’ve added logging with Log4Net when a PageDefinition is saved. This way if you are experiencing slow start up using Page Type Builder you can easily check if it’s due to PageDefinitions being saved and why so that you can fix it.
As I mentioned at the beginning of this post this release is fairly untested. I have of course run existing tests and done some profiling but I haven’t tested it in production. The changes are however minor so I don’t suspect any issues. Please let me know a.s.a.p. if you try it and find anything
- Define tabs in code with Page Type Builder 0.8.5
- Page Type Builder 2 Preview 2
- Page Type Builder 2 Preview 1 released!
- Ideas for a new major version of Page Type Builder
- A common problem with Page Type Builder and UniqueValuePerLanguage set to false
- Ideas for new features in Page Type Builder 2.0
- Page Type Builder planned development timeline
- Developing with Page Type Builder – Getting Started