Same sort order number multiple times in Umbraco 7
We noticed an issue regarding the sort order of nodes in Umbraco 7.0.3: We have several nodes with the same sort order number inside the same parent node.
The reason for that seems to be that the sort order is not being updated, when nodes are - deleted - copied inside the same parent.
A solution for that is resorting the nodes inside the parent node, so the sort order index can be fixed.
There is a similar post, but it was for Umbraco 6. So I thought, that there might be a new relevance for that.
we recently upgraded to v 7.1.1. This is what I discovered:
Copy element inside the same parent: This is now working. The new node gets the number of the existing children as the new index.
Deleting an element: This seems not working correctly. When I delete an element (that has following siblings), the index of the following siblings is not updated. This produces an index issue when we copy an item inside the same parent after deleting one. Here is an example:
1) Initial situation:
ParentNode
Node1 (Index 0)
Node2 (Index 1)
Node3 (Index 2)
Node4 (Index 3)
2) After deleting Node2: The following nodes are not updated.
ParentNode
Node1 (Index 0)
Node3 (Index 2)
Node4 (Index 3)
3) After deleting Node3: The following nodes are not updated.
ParentNode
Node1 (Index 0)
Node4 (Index 3)
4) After copying Node1 inside ParentNode. I would expect the new/copied node at the end.
ParentNode
Node1 (Index 0)
Node1 (1) (Index 2)
Node4 (Index 3)
5) After copying Node1 inside ParentNode again. I would expect the new/copied node at the end.
I just checked the behavior in Umbraco 7.4.1. A part of this bug seems to be fixed now. When I copy a node inside a parent node, it always gets the highest sort index, no matter if there are missing index numbers before. So the new copied element is always the last child, as expected.
But the first part of the sorting bug still exists: When deleting a node, the sort index of the following sibling nodes is still not updated.
Example: Nodes have the following sort order:
0
1
2
3
When deleting the node with index 1, the index of the following nodes are not recalculated, so that the nodes have the following sort order:
0
2
3
But it should be:
0
1
2
This bug has the effect, that the sort index cannot be used for a valid enumeration list.
Same sort order number multiple times in Umbraco 7
We noticed an issue regarding the sort order of nodes in Umbraco 7.0.3: We have several nodes with the same sort order number inside the same parent node.
The reason for that seems to be that the sort order is not being updated, when nodes are
- deleted
- copied inside the same parent.
A solution for that is resorting the nodes inside the parent node, so the sort order index can be fixed.
There is a similar post, but it was for Umbraco 6. So I thought, that there might be a new relevance for that.
Kind regards and best wishes,
Ben
Hi Ben
I think I have seen others have this issue in early releases of Umbraco 7 as well unfortunately...
Could you perhaps try to do an upgrade to v 7.1, which was released yesterday to see if that fixes the problem?
If you decide to do so by all means remember to make a backup of your files and database!
Looking forward to hearing from you.
/Jan
Hi Jan,
thanks a lot for the good news. We will have a look at this next week and I will give feedback.
Nice weekend,
Ben
Hi Jan,
we recently upgraded to v 7.1.1. This is what I discovered:
Copy element inside the same parent: This is now working. The new node gets the number of the existing children as the new index.
Deleting an element: This seems not working correctly. When I delete an element (that has following siblings), the index of the following siblings is not updated. This produces an index issue when we copy an item inside the same parent after deleting one. Here is an example:
1) Initial situation:
ParentNode
2) After deleting Node2: The following nodes are not updated.
ParentNode
3) After deleting Node3: The following nodes are not updated.
ParentNode
4) After copying Node1 inside ParentNode. I would expect the new/copied node at the end.
ParentNode
5) After copying Node1 inside ParentNode again. I would expect the new/copied node at the end.
ParentNode
Best wishes
Ben
Hi there,
any news on that?
Best regards,
Ben
Hi there,
I just checked the behavior in Umbraco 7.4.1. A part of this bug seems to be fixed now. When I copy a node inside a parent node, it always gets the highest sort index, no matter if there are missing index numbers before. So the new copied element is always the last child, as expected.
But the first part of the sorting bug still exists: When deleting a node, the sort index of the following sibling nodes is still not updated.
Example: Nodes have the following sort order:
When deleting the node with index 1, the index of the following nodes are not recalculated, so that the nodes have the following sort order:
But it should be:
This bug has the effect, that the sort index cannot be used for a valid enumeration list.
Anyone has the same behavior?
Best regards, Ben
We have the same problem. But guess the nodes with same sortorder is from a earlier version of v7.
But what do we do with all the nodes that has the same sortorder?
I think the best thing would be to make the sortorder the same as they are shown in the content-tree or the order [node].Children is ordered by.
It will be peace of cake to update sortorder in the umbracoNode table. But you have to know how umbraco core is sorting the nodes.
So does anybody know how the "order by" is when getting the children in the content tree and what it is when doing a node.children on a TypedContent?
/Mikkel
is working on a reply...