Problem: Reserved property names in episerver 7.1 edit mode?

Erik Täck

Vote:

So this is an interesting issue..

I tried this on a clean episerver 7 (webforms) alloy site installed from the deployment center.

Note: I did this on another site using programmatic vaules first and got the same problem, like so: public virtual string Preamble { get; set; }

Go into admin and create a long string (> 255) property named "Preamble" on for example the "Article Page" type.
Create a page, edit all fields and publish, works fine.
Update to 7.1 (or 7.1 edit mode, or 2.0 edit mode or what we are supposed to call it) through the addons pane, like described here: http://world.episerver.com/en/Articles/Items/EPiServer-71-CMS-available-in-Add-on-Store/
Create a new page again using the page type you added the property on. Add some text to the preamble field (through the forms editing area) and publish.
Now the dope controls will not load for this page anymore, you can also not open "forms edit", the only way to edit this page is through the classic edit mode.
If you rename the property something else (like Preamble2, or PrettyHorse), remove the contents if the field (throug classic edit) then the edit mode starts working again.
New pages still works, but as soon as you have any content in the Preamble field, they stop being editable.
There are no javascript errors, 404 or other errors when loading the edit mode, everything works except for this (so far).

Can anyone verify or debunk this please, in case there are some really strange issues with my computer?

My final thoughts on this is: WAT?

#69763

Apr 05, 2013 9:21

Per Nergård

Vote:

Wierd, but why are you adding properties through admin mode?

#69769

Apr 05, 2013 11:29

pezi

Vote:

Unfortunately it's a reintroduced bug. I'll reopen it. Dojo fails miserably here, as preamble is part of the class instance creation. For now you have to stay away from using it as a property name.

#69786

Apr 05, 2013 15:41

Erik Täck

Vote:

Per Nergård: To verify a bug, as I wrote in the post.

Per Zimmerman: Right, I suspected as much after a "find in files" in the modules directory, I saw some json objects with a property named preamble. I'll have to use the vastly inferior "MainIntro" then for now :)

#69795

Apr 05, 2013 18:02

Tomas Marcusson

Vote:

Ok, i can confirm this bug as well.

Upgraded to 7.1 and we use Preamble as a property and as Erik says the dope controls will not load.

The problem we have is that we use Preamble on practically all the pages which have content so for us its not really possible to remove the property and rename it.

And further more since on page editing doesn't work it's not possible to work with blocks.

I must call this an epic failure and when can we expect a fix for this?

I have already spent half this day upgrading to 7.1 with all the problems regarding the upgrade process and now this on top, i'm not impressed.

#69920

Apr 09, 2013 18:24

Erik Täck

Vote:

Tomas, for the edit update that was just released: All you need is the vpp folders "modules", and "modulesrepository", as well as the folder "modulesbin" in the webroot of your web project. Make one upgrade on a dev site and then save a zip file of the updated package for further upgrades. A lot easier and more secure to deploy to production systems that way too as I am not quite sure what will happen if the update should fail halfway through for example.

#69923

Apr 09, 2013 18:46

Tomas Marcusson

Vote:

Erik, yes that is exactly what I have done.

This is however not a live site but a site under development in the later stages of the project, the problem is that all developers use the same database and also the same share for VPP files.

The upgrade was made locally and then "transferred" to the staging environment, but the upgrade failed half way locally and that caused the test environment to fail as well. I guess that something was updated in the database?

Is there any way of rolling back to the previous version?

#69925

Apr 09, 2013 18:57

pezi

Vote:

Yes, you can expect a fix for this soon.

We fixed this bug ages ago. Unfortunately, the unit tests we had for this didn't catch a refactoring and the bug was reintroduced. The preamble bug is only a client side bug, it's not server related. It occurs because data is passed as first parameter in a class constructor.

You can try the behavior yourself with this snippet:

require(["dojo/_base/declare"], function(declare) { 

    var C = declare(null, {
        constructor: function() {
            console.log("Constructor", arguments);
        }
    }); 

    new C(1); 
    new C({ preamble: "x" });
});

Run that in a web inspector and you'll get a error when the second class instance is created. Dojo's declare has a special thing for preamble.

#69958

Apr 10, 2013 10:32

Tomas Marcusson

Vote:

Per, thanks for the information.

We decided to rollback to the previous version since we felt that this release was too buggy.

#69961

Apr 10, 2013 10:39

Magnus Wallin

Vote:

I can also add that i sat almost a full day with this exact bug, we have several properties names Preamble around our project. In the end we choose to do a rollback and don't install 7.1, and will also not recommend customer to install until 7.2 or whatever comes next

#69965

Apr 10, 2013 10:53