We had converted a property on a document type (umbNaviHide) into a composition document type which was then added back to the document type that had originally had it.
Since it is a umbraco reserved property name we could not alter the property name on the composition (which is normally how we would handle this). On our dev environment this worked flawlessly because the sequence of actions was very clear:
remove property from doctype A
create new doc type B
add property to doc type B
add doc type B as a composition to doc type A
However, when these changes were synced to the next environment we encountered a runtime error about duplicate property names (umbNaviHide) on doctype A. This runtime error prevented access to {siteurl}/umbraco and as such was not resolvable via the GUI.
We fixed the issue by removing the old property from cmsPropertyData and then removing the property from cmsPropertyType.
However, we were concerned about future changes that involve property names and usync and are not that comfortable with such a specific recovery plan as we may not be the developers who maintain the system.
Is there any current plan to help mitigate issues like this?
yeah, i am really sorry this has YSODed the site, that's the number on thing i am trying not to do :(
usync uses the Umbraco APIs at all times (although maybe not always correctly) and most of the time this stops this type of thing from being possible - but it does look like in this specific situation it can be done.
I will have a look and see if there is anything I can find to preempt this - the issues is usync might not know that the property being added at one level exists somewhere else in the doctype tree and will need to be removed first - and removal and recreation can causes a lot of content to go (when you delete a property umbraco will wipe the values from the content nodes as part of the delete).
but i will look at this and see what can be done because leaving your site in the position where you need to edit db tables isn't right.
for info - We have a "fix" for this in the latest release.
In the situation where a property has been removed from one doctype, and added to another that is then part of the composition of the first. uSync will throw a warning during import (you will see this in the dashboard).
A second import usually then fixes the issue (because the property will have been deleted from the original property in the first one).
So hopefully the imports will now work - and usync won't cause the YSOD in these situations.
Order of sync operations results in YSOD
We had converted a property on a document type (umbNaviHide) into a composition document type which was then added back to the document type that had originally had it.
Since it is a umbraco reserved property name we could not alter the property name on the composition (which is normally how we would handle this). On our dev environment this worked flawlessly because the sequence of actions was very clear:
However, when these changes were synced to the next environment we encountered a runtime error about duplicate property names (umbNaviHide) on doctype A. This runtime error prevented access to {siteurl}/umbraco and as such was not resolvable via the GUI.
We fixed the issue by removing the old property from cmsPropertyData and then removing the property from cmsPropertyType.
However, we were concerned about future changes that involve property names and usync and are not that comfortable with such a specific recovery plan as we may not be the developers who maintain the system.
Is there any current plan to help mitigate issues like this?
Hi
yeah, i am really sorry this has YSODed the site, that's the number on thing i am trying not to do :(
usync uses the Umbraco APIs at all times (although maybe not always correctly) and most of the time this stops this type of thing from being possible - but it does look like in this specific situation it can be done.
I will have a look and see if there is anything I can find to preempt this - the issues is usync might not know that the property being added at one level exists somewhere else in the doctype tree and will need to be removed first - and removal and recreation can causes a lot of content to go (when you delete a property umbraco will wipe the values from the content nodes as part of the delete).
but i will look at this and see what can be done because leaving your site in the position where you need to edit db tables isn't right.
Kevin
Hi
for info - We have a "fix" for this in the latest release.
In the situation where a property has been removed from one doctype, and added to another that is then part of the composition of the first. uSync will throw a warning during import (you will see this in the dashboard).
A second import usually then fixes the issue (because the property will have been deleted from the original property in the first one).
So hopefully the imports will now work - and usync won't cause the YSOD in these situations.
Kevin
is working on a reply...