Duplicate Content/Media Application TreeDefinitions with Umbraco 6 and uComponents 5.3
I've come across a bug with Umbraco 6 and uComponents 5.3 where I end up with two sets of entries in the TreeDefinitionCollection for FilteredMediaTree and FilteredContentTree. This was confirmed by debugging a site I'm working on and inspecting the collection at runtime.Looking at the uComponents source code for MNTP_DataEditor.css in te static ctor, I see a check for an existing tree with a TreeType equivalent typeof(FilteredContentTree) - this doesn't really do anything to mitigate the issue as it's only going to find tree definitions in the collection that use the uComponents legacy version.I came across this problem because Umbraco 6 insists on creating a Media type filtered tree even though I have Content selected as the type, and it's breaking because the selected start node is a content node not a media node. The stack trace is what alerted me to this problem - it points at uComponents.DataTypes.MultiNodeTreePicker.FilteredMediaTree instead of the expected Umbraco core version.A suggestion to fix this may be to rename the aliases FilteredContentTree and FilteredMediaTree but prepending something like Legacy to the aliases in the TreeDefinitionCollection if they need to co-exist alongside the Core versions.
@Shannon - I had to debug core code to try figure it out. Think it's more that uComponents MNTP was setting the custom trees with the same key/name (as the core's MNTP). Not sure why no one hit this issue before (since v4.8+), unless there has been changes to how custom trees are loaded in v6?
I've fixed this for uComponents in v5.3.1 (our next patch release) ... so it shouldn't need any mods to the core.
Duplicate Content/Media Application TreeDefinitions with Umbraco 6 and uComponents 5.3
I've come across a bug with Umbraco 6 and uComponents 5.3 where I end up with two sets of entries in the TreeDefinitionCollection for FilteredMediaTree and FilteredContentTree. This was confirmed by debugging a site I'm working on and inspecting the collection at runtime.Looking at the uComponents source code for MNTP_DataEditor.css in te static ctor, I see a check for an existing tree with a TreeType equivalent typeof(FilteredContentTree) - this doesn't really do anything to mitigate the issue as it's only going to find tree definitions in the collection that use the uComponents legacy version.I came across this problem because Umbraco 6 insists on creating a Media type filtered tree even though I have Content selected as the type, and it's breaking because the selected start node is a content node not a media node. The stack trace is what alerted me to this problem - it points at uComponents.DataTypes.MultiNodeTreePicker.FilteredMediaTree instead of the expected Umbraco core version.A suggestion to fix this may be to rename the aliases FilteredContentTree and FilteredMediaTree but prepending something like Legacy to the aliases in the TreeDefinitionCollection if they need to co-exist alongside the Core versions.
argh. IE ate my formatting - editing not working :/
Hi Robert,
Thanks for reporting this, (we may need to flag this over on our issue tracker too).
I'll take a look, see what we can do to resolve this.
Cheers, Lee.
Hi Robert,
Thanks for reporting it on our issue tracker - very much appreciated! http://ucomponents.codeplex.com/workitem/14791
Good news is that I can reproduce the issue.. and have amended the uComponents legacy code, so that it doesn't duplicate the custom filtered trees.
I'm surprised that no one else has hit this issue before - maybe there's an underlying change in v6.0 trees API? (I couldn't see where).
We'll put out a patch release this week, v5.3.1.
Thanks again!
Cheers, Lee.
Let us know if this is a ucomponents issue or an Umbraco core issue. Obviously if it is a core issue please log on the tracker :)
@Shannon - I had to debug core code to try figure it out. Think it's more that uComponents MNTP was setting the custom trees with the same key/name (as the core's MNTP). Not sure why no one hit this issue before (since v4.8+), unless there has been changes to how custom trees are loaded in v6?
I've fixed this for uComponents in v5.3.1 (our next patch release) ... so it shouldn't need any mods to the core.
Thanks, Lee.
is working on a reply...