We have moved to GitHub Issues
Created by Stephen Roberts 14 Mar 2013, 11:07:00 Updated by Sebastiaan Janssen 17 Apr 2013, 09:26:04
This is an issue we are having with uSiteBuilder. When we nest DocTypes the sort order of the fields is not being honoured. It would be really sweet if it did and we think we've found a easy way to do it without impacting on anything.
If you have master doctype with nested doctypes as following:
Basepage has these properties Title (SortOrder of 1)
Homepage has these properties Bodytext (sort order of 2)
You would expect the fields to be rendered out with Title first and Bodytext second. But Umbraco backend actually render them in the reverse order, Bodytext and then Title, as it loops through each doctype, sorts the fields for that doctype only and then appends all the fields together. So the sort order ends up inversed.
This modification would be helpful for both general usage (albeit a modification to the core UI interface to allow the sorting of properties on between tabs, currently you can only sort on a tab per doctype, there is no way to set the sort order manually to anything higher (ie I might want to set "Show in nav" to always be the last field in a tab by setting its sort order to 999 or similar) with parent document types.
The attached patch sorts the properties on SortOrder AFTER the tabs have been appended together resulting in correctly sorted options. As there is currently no UI to amend sort order as there is in uSiteBuilder this has no effect to existing builds that we can see.
We are already running a build with this patch in it, would be sweet to have it in future versions for upgrading :)
Please add the 'affected version' for this issue
Thanks! Patch applied in changeset 974d5bbe6fec
Sorting in 4.11.6 is still having different behavior then the versions before.
I have a clean install of 4.11.6
Creating 2 doctypes 1 page (properties field1 / field2) 1.1 contentpage (based on page) (properties field3 / field4)
Sorting works fine at first field1 / field2 / field3 / field4
After sorting the properties and putting them back in the origional order thesorting is field1 / field3 / field2 / field4
See screencast for additional information: http://www.screenr.com/WDP7
Hi Henk, excellent screencast, what a great way of showing the issue. Had a think about this one and think I know what it is (thanks to talking it through with Stephen Roberts here in the office).
We think the sort order is not set (or its set to the same value, 0 for instance) when you first create the fields, only when you actually sort them do they get a sort order applied (we only think that as its the only way we can think to recreate this behaviour).
SO - fieldname 0 - field1 on doctype 1 0 - field2 on doctype 1 0 - field3 on doctype 2 0 - field4 on doctype 2
Once sorted (step two of your screencast) the sort order is updated but each doctype has a separate sort order index and it always starts from 0 and increments up. So when you reordered all your fields in the order you did you actually end up with two arrays of fields:
SO - fieldname 0 - field1 1 - field2 0 - field3 1 - field4
and so on.
When the fields are rendered out (and a sort order is applied) you end up with something like:
SO - fieldname 0 - field2 from doctype1 0 - field4 from doctype2 1 - field1 from doctype1 1 - field3 from doctype2
So its a tricky one to fix. One why you could do it is on save the sort order could be "fudged" depending on the depth of the content in the doctype tree, so add 1000 to the sort order for each addition depth of inheritence. This would make something like this:
SO - fieldname 0 - field2 from doctype1 1000 - field4 from doctype2 1 - field1 from doctype1 1001 - field3 from doctype2
Which would render as 0 - field2 from doctype1 1 - field1 from doctype1 1000 - field4 from doctype2 1001 - field3 from doctype2
Which is more like what you want. Only thing I can see nasty with this one is if you try to move a doctype, then things could get a bit screwy but luckily thats not really supported right now...
Okay, I've reverted this change for now to get the previous behavior back. @Pete this is exactly what happens yes and we currently don't have the time to fix this better then reverting. What you're proposing would work but it's a total hack. :-) Should probably look at all of the properties on the tab and then sort per tab instead of sorting all the properties in bulk. But as I said, no time to get into it properly.
Reverted in changeset 431e428dda53.
Difficulty: Very Easy
Backwards Compatible: True
Fix Submitted: Patch
Affected versions: 4.11.5, 6.0.2
Due in version: 4.11.6, 6.0.3