AI OnAI Off
Dynamic properties not available in upgraded site
I have now copied web.config from the demo site and only modified the few things that differ. So assembly redirects and most other things should be identical. But still no dynamic properties.
Edit: It gets stranger. Using DynamicProperty.Load only works for authenticated users (only need to be authenticated, not have any special access rights or roles). Maybe it's supposed to? Or is that a clue to what's wrong?
Edit2: Scratch that edit, bad testing :)
Edited,
Jan 12, 2011 21:48
I added all the references to PTB, EPiAbstractions and EPiMVP to the Demo project and created a View there. The PTB behaviour is the same, the GetPropertyValue construct returns null. Using CurrentPage[""] works though, very strange...
Jan 13, 2011 9:39
Could it be that you need to access the dynamic property with CurrentPage.Property["xxx"] and not with CurrentPage[xxx]
aha, that was'nt the case....
Edited,
Jan 13, 2011 9:49
CurrentPage.Property["xxx"] is null too. But only in my project, not in the demo project.
I tried to create a traditional aspx inheriting from EPiServer.TemplatePage in my project too, and that has the same behaviour as the Views, i.e. CurrentPage["xxx"] returns null.
So it's somehow a difference in the project and not in the technique used? If nothing else works I'll simply have to move all my code into the demo project...
Jan 13, 2011 9:54
It has to be a problem with the page type builder pagedata object. I have experienced something simular, but CurrentPage.Property worked thou.. I always thought it was the intereceptor functions that messed that up :(
Jan 13, 2011 10:47
Yes, I it's possible (probable) that I'm dealing with two separate problems here.
Jan 13, 2011 10:49
This is driving me nuts. I took the working public templates and added all the PTB/EPiMVP/EPiAbstractions references. Then I continued to add more and more of the files of my solution. Every now and then I recompiled and loaded the public templates startpage where I had added a read of a dynamic property. It was good up until I had included all myfiles.
I then logged in to edit mode to create one of the pages of my solution, and I notice that the property is rendered as null in edit mode (when the page is displayed in the frame next to the page tree). I go back and forth between edit and view mode and it's null in one and has a value in the other. I think "well, that's better than the other way around". I then change the database to the my original database. So new semi-working code, old database. Not working. Change back to the new database. NOT WORKING! It's like a disease spreading from code to database to code...
I'll have to do it all over again tomorrow and include toggling in and out of edit mode to see when the shift happens.
Jan 13, 2011 21:35
OK, there is something strange going on with dynamic properties in the beta. Can anyone please try to reproduce these results:
1. Install CMS6 R2 beta including public templates with globalized content.
2. Edit default.aspx and place this code for example inside the <div id="MainBodyArea">: <%= (CurrentPage["MainMenuContainer"] ?? "null").ToString() %>
3. Load the start page of the new site. You will see the "3" resulting from the code (the main menu reference to the start page (3)).
4. Get into edit mode any way you like (I tried both by creating a user and logging in and simply by removing the required access for the UI location to rule out that the problems have anything to do with the logged in user).
5. Click the start page in the page tree to edit it in the edit pane. You'll now se "null" where you saw "3".
6. You can toggle back and forth between view/edit mode to see the 3/null.
Now, install CMS 6 R1 and see that the behaviour is different here, it will display the "3" in both cases as it should.
I don't know if and how this is connected to my PTB/EPiMVP problems in view mode, but it could be a symptom of the same bug?
Jan 14, 2011 11:44
I have experienced before that dynamic properties are not aviable on pages that are editable (CreateWritebkeClone())
could ut be that this is the case?
Jan 14, 2011 12:52
Could be, but the sites where i reproduce this are brand new sites with default database (and public templates), I did not include my code in these sites. So in that case there is a change (bug) in CMS? Fetching of dynamic properties was changed in R2 to increase performance, wasn't it?
Jan 14, 2011 13:20
I've just tried the steps Magnus outlined above, on a default EPi 6 R2 install, (no PageTypebuilder in sight).
I see the same behaviour he reported.
- When viewing a page using a friendly Url - I see the value "3"
- When viewing a page using a default url (for example /default.aspx?id=3_68) I see null
Jan 14, 2011 15:47
Nice catch about the URL difference, but it's even because of the workpage version. Removing the _68 (well _57 in my case) makes all the difference. So there's a problem with work pages and dynamic properties? Could this also affect PTB?
Jan 14, 2011 16:10
Oh, and thanks for taking the time to reproduce it, Mark!
There's a common denominator between PageTypeBuilder and the case Anders describes with CreateWritebleClone. Both those use the PageData's ShallowCopy() to get their values. I tried to find something indicating a common denominator between shallow copy and loading a specific version but I got lost in Reflector. But I'm sure someone at EPiServer knows without even looking at the code?
Jan 14, 2011 16:25
No worries. I had R2 set up, as like you I've been playing with some Visitor Criteria (Nice blog posts by the way).
To me there is a clear bug with R2 - and a pretty major one, in that Dynamic properties return null when a specific page version is requested. I wonder whether this could be related to the changes mentioned in the post below, as it seems like it is an issue quite low down the stack.
http://world.episerver.com/Blogs/Magnus-Strale/Dates/2010/10/Dynamic-property-performance-improvements/
I think the issues you're seeing with PTB are probably related to the core issue above.
Jan 14, 2011 16:35
This has been accepted as bug #61400: Dynamic properties not fetched correctly in CMS 6 R2 Beta.
Jan 18, 2011 12:52
I have now tested a build made after the bug was fixed and it seems to solve my original problem with reading Dynamic Properties in PageTypeBuilder as well as the more generic problems. So it should work in the next release.
Jan 31, 2011 12:55
This thread is locked and should be used for reference only. Please use the Episerver CMS 7 and earlier versions forum to open new discussions.
I have a current development project which I upgraded from CMS 6 to the CMS 6 R2 beta. It then lost the ability to read Dynamic properties. They are read in edit mode (displayed in the GUI), but when I read properties from code dynamic properties are not checked. I use PageTypeBuilder and at first I thought that was the problem. I use a construct like this
public virtual string MenuRoot
{
get
{
return this.GetPropertyValue(page => page.MenuRoot, true);
}
}
but even a more orthodox read against CurrentPage["MenuRoot"] returns null for pages where a value is set (and visible) in edit mode.
And if explicitly load the dynamic property I see that it is there, the following method returns the expected results for both defined and inherited pages:
var dynProp = EPiServer.DataAbstraction.DynamicProperty.Load(page.PageLink, propertyName);
if (dynProp.Status == EPiServer.DataAbstraction.DynamicPropertyStatus.Inherited)
{
dynProp = EPiServer.DataAbstraction.DynamicProperty.Load(dynProp.InheritedPageLink, propertyName);
}
return dynProp.PropertyValue.Value;
I have a demo site of the same verison, and the public templates use a dynamic property for the menu just like this and it obviously works. So I thought my database was scrambled and created a brand new empty database from deployment center. I loaded the site to let PTB rebuild the pagetypes, published some pages and set up dynamic properties just to find that it still misbehaves in the same way.
So if it's not the database, could it be the code? I diff:ed the bin folders of the demo site and my site and all episerver dlls are identical. I also checked the assembly redirects of my upgraded site and at least all episerver assemblies are 6.1 or 6.2 in there (versions vary a bit between assemblies).
My site is using PTB, EPiMVP, EPiAbstractions as well as some other 3rd party assemblies. Could that somehow be the cause? Any other ideas?