How to use PropertyXhtmlString in a Dynamic Content in CMS 6 R2
I got a problem when I was trying to use the WYSIWYG editor inside the Dynamic Content editor. The problem it seems is that the SavePageHandler in the PageBase on the edit page is not set.
This result in that the check IsNewPage will fail when the editor tries to find the EditorCssPaths.
The quick fix to this is to make your own variant of the PropertyXhtmlString like this
Code Snippet
- public class PropertyXhtmlStringV2 : PropertyXhtmlString
- {
- public override IPropertyControl CreatePropertyControl()
- {
- return new PropertyXhtmlStringV2Control();
- }
- }
- public class PropertyXhtmlStringV2Control : PropertyXhtmlStringControl
- {
- public override void CreateEditControls()
- {
- (this.Page as PageBase).SavePageHandler = new SaveCurrentPage(this.Page as PageBase);
- base.CreateEditControls();
- }
- }
Apr 27, 2011
There is a hotfix available from EPiServer as well.
Bug #64001: Dynamic Content with public property of type XHTML.
Just for searchability :)
I was having this exact problem this morning.. great!
Is there a list aviable of all the hot fix'es. Are having problem with Property to select a file from a none version filesystem.
We have a list of hotfixes that's not up to date :(
http://world.episerver.com/Download/Categories/Download-Type/Hotfixes/
I would suggest to open a ticket with developer support and see if they have one for your issue.
Anders - I reported something similar to the non-versioned filesystem bug you mention,
http://world.episerver.com/Support/Bug-List/#bug,EPiServer%20CMS,64398,4b6d%2f5rOFe3dV6T%2boAg7%2bpGT9mk%3d
Its marked as fixed, but I haven't got a hotfix as yet.
Mark: I take it you've requested a hotfix from Support?
/Paul
Side note: Hotfixes do not undergo the same QA process as official releases, consequently there would be a risk involved having them generally distributed. The normal process for us managing a limitation would be to define the problem and root cause and then work around it if possible. The last option would then be to create a fix for the issue (if possible). Directing partners to dev. support also opens up for further traceability which naturally also helps us define and / or out rule certain aspects in future cases.
We just found out, that in our CMS 6 R2, we had to add a constructor with only a call to base() in order for the snippet above to not throw an exception.