I'm a passionate web developer and systems architect. I work as an independent consultant specializing in EPiServer and search.
About web development with ASP.NET and EPiServer, fatherhood and other adventures in my digital jungle
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.
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.
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 
PS. For updates about new posts, sites I find useful and the occasional rant you can follow me on Twitter. You are also most welcome to subscribe to the RSS-feed.
This blog is built with EPiServer Community, EPiServer CMS, ASP.NET MVC and a bunch of other great products. The source code is available for download at the projects page, where you also can read more about this site and my other projects.
read more
Comments
Paul Smith 1 years ago
The fact the DataFactory.GetPages doesn't use the PageData (or derived) object returned from the PageLoaded event handler has been reported as a bug against EPiServer CMS 6 R2.
Joel Abrahamsson 1 years ago
Service pack! Service pack! Service pack! The crowd is chanting :)
Erik Nilsson 1 years ago
Also, your smileys aren't transparent...
Nicklas Israelsson 1 years ago
Thanks for this Joel. It drastically reduced the startup time for our R2 site.
Lars Kolsaker 1 years ago
Great work Joel.
Have you used PagetypeBuilder with Composer ?
There are still some issues with PTB 1.3.1 and Composer 4.1 (see discussion on Mari J blogpost http://world.episerver.com/Blogs/Mari-Jorgensen/Dates/2010/8/Composer-and-PageTypeBuilder---continued/
Any comments on plans to make this two components work together ?
Joel Abrahamsson 1 years ago
Lars, sorry for the late reply.
As I normally don't use Composer myself it isn't a priority for me, but any fixes submitted I will definitely consider including.
Martin Emanuelsson 1 years ago
When will we see this new version of PageTypeBuilder as a Nuget package? Is this up to you to upgrade or is this something that EPiServer is in charge of?
Joel Abrahamsson 1 years ago
Currently the process is to e-mail it to EPiServer which I haven't gotten around to yet. They added it themselves the first time, so either they do it again, or I do it as soon as I can find some spare time :)
Jarle Friestad 1 years ago
I have a small change request :-) I would like to mark old page types (templates that are going to be replaced) with the obsolete attribute. Page types with the obsolete attribute is not going to be added if it is missing (the web editors have replaced pages with the old page type with the new page type and deleted the old page type via episerver admin). But if still exists, the properties are updated so that the template still works.
Emil 11 months ago
Hi Joel and thanks for an interesting session @NDC2011.
After upgrading to PTB 1.3.1 and CMS 6 R2, the long string settings don't seem to work as before. We are still using the old CMS 5 editor and the below code to customize the toolbar. But the editors are rendered with full toolbars. Also, can you specify in code that you want to use custom settings and not global settings?
public class PageTypePropertyLongStringAttribute : PageTypePropertyAttribute { public PageTypePropertyLongStringAttribute() { this.LongStringSettings = ( EditorToolOption.All ^ EditorToolOption.Font ^ EditorToolOption.Left ^ EditorToolOption.Right ^ EditorToolOption.Center ^ EditorToolOption.InsertUrl ^ EditorToolOption.InsertDoc ^ EditorToolOption.InsertImage ); } }Joel Abrahamsson 11 months ago
Hi Emil!
Unfurtunately you won't be able to specify the settings in the constructor in 1.3.1 as the constructor of the attribute also sets it.
But you could instead override the LongStringSettings property and in the getter return the settings that you currently set in the ctor.
As for property settings PTB 1.3.1 doesn't do anything with regards to them so there the answer is no. PTB 2 will support property settings, but there the old CMS 5 editor won't be supported out-of-the-box :( However, given that I have the time to introduce the flexibility that I'd like you should be able to work around that so you can still use the old editor.
Emil 11 months ago
Thanks for the swift response. I actually tried to do it as simple as I could think of, like:
[PageTypeProperty(LongStringSettings = (EditorToolOption.DynamicContent | EditorToolOption.ToggleHtml))] public virtual string TestBody { get; set; }But the editor still showed up with a full toolbar. I guess it has to do with the new property settings in CMS 6 where you have to choose between using global settings or custom settings per editor. The default seems to be global settings, thus my settings are being ignored.
Denis 7 months ago
Hi Joel,
is type of Object, and not one of the PBT types as it is expected.I made Scheduled PlugIn which is working as it should in CMS 6. After upgrading to PTB 1.3.1 and CMS 6 R2 I got problem when getting pages, because PTB types are ignored.
For example
It's getting more interesting because same implementation
works outside my Scheduled PlugIn.
Do you have any idea what could go wrong?
Joel Abrahamsson 7 months ago
Hi Denis!
Are you using FindPagesWithCriteria or GetPages? If so you have run in to the bug described above and the only solution is to call the AsTyped() extension method on the result.
If you're not using those methods (only GetPage and/or GetChildren) I'm not sure what could be wrong and would need to look more closely at your code.
Denis 7 months ago
Joel you are king of the jungle. Extension method solved my problem. Thanks a lot.
Jonas Boman 6 months ago
I've just upgraded to R2 and am using a EPiServer:PageList to list pages of a custom page type which i've used PageTypeBuilder to create.
What is the best practice to iterate the list and output values of fields which only exists in this custom page type ; with episerver properties or inline code?
In this stage I'm getting this error:
[InvalidCastException: Unable to cast object of type 'EPiServer.Core.PageData' to type 'Site.Web.Templates.Public.PageTypes.Article'.]
(Article)PageTypeBuilder.PageTypeResolver.Instance.ConvertToTyped(Container.DataItem).StartPublish.ToShortDateString()
Using the ConvertToTyped resolved the problem at some point but is making the aspx page unreadable.
Joel Abrahamsson 6 months ago
That's caused by a bug in the DataFactory.GetPages method. If retrieve a PageDataCollection using FPWC or GetPages you can call the AsTyped extension method from PageTypeBuilder on it to retrieve the pages as objects of the correct type.
Jonas Boman 6 months ago
ooooooh. Joel. I'm almost willing to marry you for this.