I have a set of doctypes that sync up fine with 6.0.1. But i pushed them onto a production server to sunc up that was 6.0.2 and child nodes are pushing properies onto the parent (or parent grabbing form child).
I have also tried with the latest 6.0.3 nightly and similar issues.
Another thing to look out for is uSitebuilder can never sync up properly and even after a syns shows the doctypes as changed.
This has completely trashed a site i had and i've had to restore back to before the doctype import and then rollback to 6.0.1.
I've raised an issue on issues. http://issues.umbraco.org/issue/U4-1966 but maybe there is something out of sync with this package and the new umbraco code base?
And one final thing - i am using Lee's fork as this got around the bug with the property saving -
I'm not sure what changed between 6.0.1 and 6.0.2, but the problem seems to stem from the fact that uSiteBuilder uses the old Tab API and this has been superceded by PropertyGroups.
The properties are being associated with the tab on the parent content type (which is what used to happen with tabs) but then on the next sync, when the parent doc type is saved, the property is picked up and moved to the parent (the one that owns the tab).
I'm thinking the only way to fix it is to rewrite that bit of uSiteBuilder to use the PropertyGroups instead of the Tab calls.
Sounds about right that! Ive not gon into the inner working of that part of umbraco but find it odd how properties get allocated to tabs. A while back I changed the tab name on some of my properties in uSB and i ended up with a very broke set of content nodes. Scary!
What i might have to do then is keep using 6.0.1 until there is a fix - but i seem to remember a fix actually gong into umbraco to fix this exact issue - but it was happening using the umbraco backend and not with uSB, Maybe they have fixed umbraco and broke uSB!
Another way would be to get everything sorted using 6.0.1 and then upgrade the site before release and abondon uSitebuilder until that was fixed up. I cant risk a site getting its doc types messed up otherwise the whole thing is trashed,
I thought i had tracked this down to an issue with umbraco but it looks like uSitebuilder is not settng something in relation to the tabs like you say.
If i go to 6.0.1 and import document types uSB sees everything fine BUT - if i go to a doctype with an inherited tab with properties and press save i get a run time error saying:
[NullReferenceException: Object reference not set to an instance of an object.] umbraco.controls.ContentTypeControlNew.UpdatePropertyTypes(IContentTypeComposition contentTypeItem) +399 umbraco.controls.ContentTypeControlNew.save_click(Object sender, ImageClickEventArgs e) +1134 System.Web.UI.WebControls.ImageButton.OnClick(ImageClickEventArgs e) +186 System.Web.UI.WebControls.ImageButton.RaisePostBackEvent(String eventArgument) +164 System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)
If i then upgrade to 6.0.3 the save works but all the properties that are on the inherited tab get copied to the parent.
I tried to reacreate all these steps by manually creating the doc types. The save error was not there and neither was the bug so it looks like uSitebuilder is not setting something when it saves a doctype in relation to tabs.
It uses the new PropertyTypeGroup property instead of SetTabOnPropertyType and something somewhere in Umbraco is picking this up ok and creating the inherited tab.
1. I was using Lee's branch that was integrated/changed for uSitebuilder Admin so the sync didnt happen on startup - but through the backend. This one started to sync on startup.
2. I got a few errors with collection modified when it started up until i kep pressing F5. Thinnk this was to do with syncing up the templates.
3. When i went into the backend once it worked it had generated the docTypes and the child doctype properties on inherited tabs had moved onto the parent node still & when i ran the uSiteBuilderAdmin too after the syn it still reported differences.
Ah Ok, there's a flag that you can set in the app settings that will suppress the start up synchronization "siteBuilderSuppressSynchronization" if you want to keep control through the admin interface.
I take i the sync from a clean doc type set up?
The guys at Offroad Code also ran into an issue so it might be related to this, I'm hoping theyve got a fix if mine doesn't work.
No it wasnt a clean slate- i have started manually building the doctypes as I needed to get moving as im behind on the build now - so backed up and tried on that.
Can keep trying any fixes for you but easiest way to test is to create a basic doc type structure 3 deep in uSB (L1>L2>L3) and put a tab on L2 and a propety on that tab on L3 docType. When it sycs, the property on L3 ends up on L2 docType tab.
Yeah I was doing that with quite a complex structure (that I'd reprodcued the bug with), but thought I'd managed to fix it. Tried again and after another sync the problem came back.
Have had a look into how the PropertyTypeGroups work and added a fix that explicitly creates a new inheirted tab where the tab is inherited (which wasn't necessary before).
I've synced quite a few times now and everything seems to be stable (although I said that last time). Checking the database seems to look right too - the properties are associated with the new inherited tabs.
I think I also fixed that issue where the doc types were reporting to be different when they weren't (again due to some tab issues).
Ok i've just finished inputting all my doc types manually now which may be safest for now but i'll backup and set the sync property in the config and give it a whirl to see what it makes of my docType structure. No harm in runnin git also as i can rollback the db if necessary.
Just a question - the things you have changed are calling umbraco methods right? If so i think they should stop this from happening. Its like they have left a ticking time bomb behind after moving on with a new feature.
Went to admin and it shows changes but it would because there were things that were slightly different.
Ran the sync and got this:
Collection was modified; enumeration operation may not execute.
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.
Exception Details: System.InvalidOperationException: Collection was modified; enumeration operation may not execute.
Source Error:
An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.
OK that error just looks like a bug with umbraco - when changing a parent doc type (which you can't do through the front-end but the method is there) it calls
foreach (var mct in MasterContentTypes)
{
RemoveParentContentType(mct);
}
where RemoveParentContentType calls
MasterContentTypes.Remove(parentContentTypeId);
so the collection is modified.
Just tried it myself by changing the base class for a doc type and got the same error.
Just found this while trying to see if the above bug has been logged - looks pretty similar, the problem is I think if people are still using the old tab api calls, the properties get the wrong propertygroupid and get moved to the parent doc type.
Right - i had forgot to deploy a new dll and had changed the parent doc type (when i had done it manually) like you mentioned above.
Ran again and didnt get that error this time as it matched.
Seems to have all the properties right but its still showing that things are different even if i try run again and again - still the main bug seems to be fixed.
Now... do i use this or keep pluggin away with the manual one!!! lol decisions decisions. :o/ I am worried there may be something else lurking around with the compare not showing the right info.
And on the subject of changing doc typre inheritance (which is what happened above) - i really think that you should not be allowed to sync if this has happened! It should tell you that this has changed and it is not supported within umbraco. Ive done it 3 times now because i keep forgetting you cant do it! Its far too easy when you are just changing the classes.
If you do it whilst there are content nodes it completely trashes your database and is a nitemare to back out of.
Not sure what the comparison error is, it's not hugely reliable in some cases - if you've got the code you could attach and stick some breakpoints in DocumentTypeComparer on all the lines that say "return false;" and see which one is hit. Not the greatest method, but it should work.
I'm avoiding v6 for any client sites at the moment, just too many things like this that are still being picked up.
This incompatibility really needs to be pointed out on the main package forum.
Having spent the day troubleshooting the mad creation of doc types in Umbraco 6.0.5 I only came here because I thought I'd try the admin package to see if I could sort out my headaches.
Don't install on umbraco > 6.0.1 until this is fixed
I have a set of doctypes that sync up fine with 6.0.1. But i pushed them onto a production server to sunc up that was 6.0.2 and child nodes are pushing properies onto the parent (or parent grabbing form child).
I have also tried with the latest 6.0.3 nightly and similar issues.
Another thing to look out for is uSitebuilder can never sync up properly and even after a syns shows the doctypes as changed.
This has completely trashed a site i had and i've had to restore back to before the doctype import and then rollback to 6.0.1.
I've raised an issue on issues. http://issues.umbraco.org/issue/U4-1966 but maybe there is something out of sync with this package and the new umbraco code base?
And one final thing - i am using Lee's fork as this got around the bug with the property saving -
http://our.umbraco.org/projects/developer-tools/usitebuilder/usitebuilder-support/38513-AllowedChildNodeTypes-not-setting-#
I'm not sure what changed between 6.0.1 and 6.0.2, but the problem seems to stem from the fact that uSiteBuilder uses the old Tab API and this has been superceded by PropertyGroups.
The properties are being associated with the tab on the parent content type (which is what used to happen with tabs) but then on the next sync, when the parent doc type is saved, the property is picked up and moved to the parent (the one that owns the tab).
I'm thinking the only way to fix it is to rewrite that bit of uSiteBuilder to use the PropertyGroups instead of the Tab calls.
Sounds about right that! Ive not gon into the inner working of that part of umbraco but find it odd how properties get allocated to tabs. A while back I changed the tab name on some of my properties in uSB and i ended up with a very broke set of content nodes. Scary!
What i might have to do then is keep using 6.0.1 until there is a fix - but i seem to remember a fix actually gong into umbraco to fix this exact issue - but it was happening using the umbraco backend and not with uSB, Maybe they have fixed umbraco and broke uSB!
Another way would be to get everything sorted using 6.0.1 and then upgrade the site before release and abondon uSitebuilder until that was fixed up. I cant risk a site getting its doc types messed up otherwise the whole thing is trashed,
I thought i had tracked this down to an issue with umbraco but it looks like uSitebuilder is not settng something in relation to the tabs like you say.
If i go to 6.0.1 and import document types uSB sees everything fine BUT - if i go to a doctype with an inherited tab with properties and press save i get a run time error saying:
[NullReferenceException: Object reference not set to an instance of an object.]
umbraco.controls.ContentTypeControlNew.UpdatePropertyTypes(IContentTypeComposition contentTypeItem) +399
umbraco.controls.ContentTypeControlNew.save_click(Object sender, ImageClickEventArgs e) +1134
System.Web.UI.WebControls.ImageButton.OnClick(ImageClickEventArgs e) +186
System.Web.UI.WebControls.ImageButton.RaisePostBackEvent(String eventArgument) +164
System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)
If i then upgrade to 6.0.3 the save works but all the properties that are on the inherited tab get copied to the parent.
I tried to reacreate all these steps by manually creating the doc types. The save error was not there and neither was the bug so it looks like uSitebuilder is not setting something when it saves a doctype in relation to tabs.
Yeah I've made a change in a v6 only branch here - http://usitebuilder.codeplex.com/SourceControl/network/forks/StephenWRogers/uSiteBuilder?branch=tab-fix - that would be awesome if you could try out. I had a go with the solution I've got here and all seemed to be OK with it.
It uses the new PropertyTypeGroup property instead of SetTabOnPropertyType and something somewhere in Umbraco is picking this up ok and creating the inherited tab.
Nope - couple of issues unfortunately.
1. I was using Lee's branch that was integrated/changed for uSitebuilder Admin so the sync didnt happen on startup - but through the backend. This one started to sync on startup.
2. I got a few errors with collection modified when it started up until i kep pressing F5. Thinnk this was to do with syncing up the templates.
3. When i went into the backend once it worked it had generated the docTypes and the child doctype properties on inherited tabs had moved onto the parent node still & when i ran the uSiteBuilderAdmin too after the syn it still reported differences.
Thanks for looking at it Stephen!
Ah Ok, there's a flag that you can set in the app settings that will suppress the start up synchronization "siteBuilderSuppressSynchronization" if you want to keep control through the admin interface.
I take i the sync from a clean doc type set up?
The guys at Offroad Code also ran into an issue so it might be related to this, I'm hoping theyve got a fix if mine doesn't work.
See https://groups.google.com/forum/#!topic/usitebuilder-developers/zivKDtCkMgg
Stephen
No it wasnt a clean slate- i have started manually building the doctypes as I needed to get moving as im behind on the build now - so backed up and tried on that.
Can keep trying any fixes for you but easiest way to test is to create a basic doc type structure 3 deep in uSB (L1>L2>L3) and put a tab on L2 and a propety on that tab on L3 docType. When it sycs, the property on L3 ends up on L2 docType tab.
Yeah I was doing that with quite a complex structure (that I'd reprodcued the bug with), but thought I'd managed to fix it. Tried again and after another sync the problem came back.
Have had a look into how the PropertyTypeGroups work and added a fix that explicitly creates a new inheirted tab where the tab is inherited (which wasn't necessary before).
I've synced quite a few times now and everything seems to be stable (although I said that last time). Checking the database seems to look right too - the properties are associated with the new inherited tabs.
I think I also fixed that issue where the doc types were reporting to be different when they weren't (again due to some tab issues).
Changes are on that same branch of my fork. http://usitebuilder.codeplex.com/SourceControl/network/forks/StephenWRogers/uSiteBuilder?branch=tab-fix
Stephen
Ok i've just finished inputting all my doc types manually now which may be safest for now but i'll backup and set the sync property in the config and give it a whirl to see what it makes of my docType structure. No harm in runnin git also as i can rollback the db if necessary.
Will let you know how i get on.
Cheers!
Damian
Just a question - the things you have changed are calling umbraco methods right? If so i think they should stop this from happening. Its like they have left a ticking time bomb behind after moving on with a new feature.
Gave it a whirl....
Disabled auto sync.
Went to admin and it shows changes but it would because there were things that were slightly different.
Ran the sync and got this:
Collection was modified; enumeration operation may not execute.
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.
Exception Details: System.InvalidOperationException: Collection was modified; enumeration operation may not execute.
Source Error:
An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.Stack Trace:
OK that error just looks like a bug with umbraco - when changing a parent doc type (which you can't do through the front-end but the method is there) it calls
foreach (var mct in MasterContentTypes) { RemoveParentContentType(mct); }where RemoveParentContentType calls
so the collection is modified.
Just tried it myself by changing the base class for a doc type and got the same error.
Just found this while trying to see if the above bug has been logged - looks pretty similar, the problem is I think if people are still using the old tab api calls, the properties get the wrong propertygroupid and get moved to the parent doc type.
http://issues.umbraco.org/issue/U4-1847
Created a bug for the changing parent doc type error - http://issues.umbraco.org/issue/U4-1974
Right - i had forgot to deploy a new dll and had changed the parent doc type (when i had done it manually) like you mentioned above.
Ran again and didnt get that error this time as it matched.
Seems to have all the properties right but its still showing that things are different even if i try run again and again - still the main bug seems to be fixed.
Now... do i use this or keep pluggin away with the manual one!!! lol decisions decisions. :o/ I am worried there may be something else lurking around with the compare not showing the right info.
What do you think?
And on the subject of changing doc typre inheritance (which is what happened above) - i really think that you should not be allowed to sync if this has happened! It should tell you that this has changed and it is not supported within umbraco. Ive done it 3 times now because i keep forgetting you cant do it! Its far too easy when you are just changing the classes.
If you do it whilst there are content nodes it completely trashes your database and is a nitemare to back out of.
Not sure what the comparison error is, it's not hugely reliable in some cases - if you've got the code you could attach and stick some breakpoints in DocumentTypeComparer on all the lines that say "return false;" and see which one is hit. Not the greatest method, but it should work.
I'm avoiding v6 for any client sites at the moment, just too many things like this that are still being picked up.
Let me know if you can see the comparison bug.
This incompatibility really needs to be pointed out on the main package forum.
Having spent the day troubleshooting the mad creation of doc types in Umbraco 6.0.5 I only came here because I thought I'd try the admin package to see if I could sort out my headaches.
is working on a reply...