Issues with sort order on content added via ContentService
Hello,
I'm experiencing some odd behaviour in Umbraco 7.2.5 when publishing content. It seems that every time a user saves or saves and publishes an existing entry the node is reordered to be the last of the parent's children (i.e. sort order is not preserved)
What's strange is that this only happens on nodes that have been created using the content service API. A node created within Umbraco directly does not exhibit this behaviour. Content has been added via the API in the following manner, which is creating published records as expected:
IContent newContent = new Content(entry.PageTitle, parent, contentType);
// Setting property values here
contentService.SaveAndPublishWithStatus(newContent);
The other thing that is strange is that behaviour persists even after sorting the nodes within Umbraco. It's almost as if nodes imported via the content service are holding onto some property data that interferes with sort ordering.
I've tried to determine whether there are any obvious differences in the data of a node added via the content service and one created within Umbraco, but I can't identify anything.
Anyone else experienced this behaviour and have an idea of how I can correct it?
So it turns out this is a cautionary tale about naming your properties.
I was using the content service to import data from an external data source and had a property on my document type that was tracking the imported record's parent ID. My error was giving this property an alias of parentId, which matches an internal Umbraco property.
It appears that this duplicate property alias was interfering with the internal save logic as I setup some event handlers to monitor the SortOrder property on ContentService.Saving and ContentService.Saved and this showed that the sort order was changing between these two events. It did not affect records created manually as this property was never assigned a value.
I have updated the property alias to historicParentId, and this appears to have fixed the issue I was experiencing.
Going to be more careful with property aliases in the future...
Issues with sort order on content added via ContentService
Hello,
I'm experiencing some odd behaviour in Umbraco 7.2.5 when publishing content. It seems that every time a user saves or saves and publishes an existing entry the node is reordered to be the last of the parent's children (i.e. sort order is not preserved)
What's strange is that this only happens on nodes that have been created using the content service API. A node created within Umbraco directly does not exhibit this behaviour. Content has been added via the API in the following manner, which is creating published records as expected:
The other thing that is strange is that behaviour persists even after sorting the nodes within Umbraco. It's almost as if nodes imported via the content service are holding onto some property data that interferes with sort ordering.
I've tried to determine whether there are any obvious differences in the data of a node added via the content service and one created within Umbraco, but I can't identify anything.
Anyone else experienced this behaviour and have an idea of how I can correct it?
So it turns out this is a cautionary tale about naming your properties.
I was using the content service to import data from an external data source and had a property on my document type that was tracking the imported record's parent ID. My error was giving this property an alias of parentId, which matches an internal Umbraco property.
It appears that this duplicate property alias was interfering with the internal save logic as I setup some event handlers to monitor the SortOrder property on ContentService.Saving and ContentService.Saved and this showed that the sort order was changing between these two events. It did not affect records created manually as this property was never assigned a value.
I have updated the property alias to historicParentId, and this appears to have fixed the issue I was experiencing.
Going to be more careful with property aliases in the future...
is working on a reply...