Fix for DOPE of LongString properties in CMS 6

As noted by Per Nergård in this blog post the LongString property has a bug in CMS 6 which prevents pages from saving changes when edited in Direct On-Page Editing (DOPE) mode.

Work around

This is a bug confirmed by EPiServer which will be fixed in an upcoming release. But we needed to fix it quick. By creating a subclass for the PropertyLongStringControl it’s possible to work around the bug. Then the PropertyControlClassFactory can be used to tell EPiServer to use this derived control instead of the original control for all LongString properties. You can either do this in web.config or in code. I chose the latter alternative, inspired by Ted Nyberg’s blog post.

Custom property control

This is the code for the custom property control:

namespace Acme.Web.SpecializedProperties
{
    /// <summary>
    /// Subclass for PropertyLongStringControl which has a work around
    /// for the DOPE bug in CMS 6 R1
    /// </summary>
    public class FixedPropertyLongStringControl : PropertyLongStringControl
    {
        private OnPageEditInputControl _onPageEditInputControl;
        public override void CreateOnPageEditControls()
        {
            if (base.PropertyData is PropertyXhtmlString)
            {
                // Use standard implementation for XHTML properties
                base.CreateOnPageEditControls();
            }
            else
            {
                // Long string, work around bug: use local edit control
                CreateStandardOnPageEditControls();
            }
        }
        /// <summary>
        /// Creates the input control used in DOPE mode for
        /// LongString Properties. This code is reflected from
        /// the standard PropertyDataControl, with the difference
        /// that IsHtmlContent is always set to false
        /// </summary>
        protected virtual void CreateStandardOnPageEditControls()
        {
            _onPageEditInputControl = new OnPageEditInputControl();
            CopyWebAttributes(_onPageEditInputControl);
            _onPageEditInputControl.ID = Name;
            _onPageEditInputControl.Text = ToWebString();
            // This code only runs for non-Xhtml properties - disable html
            _onPageEditInputControl.IsHtmlContent = false;
            Controls.Add(_onPageEditInputControl);
        }
        public override void ApplyOnPageEditChanges()
        {
            if (_onPageEditInputControl == null)
            {
                // The local edit control wasn't created,
                // which means we use the standard implementation
                base.ApplyOnPageEditChanges();
            }
            else
            {
                // Work around bug, use local edit control
                base.SetValue(this._onPageEditInputControl.Text);
            }
        }
    }
}

Override standard control

This is the code for a PluginAttribute subclass which is used to hook into the init process and register the new control:

namespace Acme.Web.PropertyControlSetup
{
    /// <summary>
    /// Maps EPiServer property types to our own property control types,
    /// uses PluginAttribute to bootstrap the init process
    /// </summary>
    public class PropertyControlSetup : EPiServer.PlugIn.PlugInAttribute
    {
        public static void Start()
        {
            PropertyControlClassFactory.Instance.RegisterClass(typeof(PropertyLongString), typeof(SpecializedProperties.FixedPropertyLongStringControl));
        }
    }
}

A final note

The code-based approach to use PropertyControlClassFactory won’t work in this case if you are using the legacy editor in CMS 6. The reason for this is that the web.config approach is used to replace the new editor with the old, which seems to take precedence over this code change so it is ignored.