We have moved to GitHub Issues
Created by James South 22 Jun 2015, 11:00:19 Updated by Sebastiaan Janssen 19 Dec 2017, 20:27:00Tags: PR
Is duplicated by: U4-8434
Relates to: U4-9298
Relates to: U4-9823
At present it is not possible (not that I can find) to view and sort the inherited composite properties in the child document type. This leads to no control over the order in which properties are displayed to the editor which can cause confusion.
Adding this functionality would allow a much greater level of control for the developer and a better editing experience for the editor.
This has been missing for years and years, would be absolutely awesome if this was to be implemented.
Would be very nice, yes. Great advantage of using the "DocType Mixins" package was exactly this - you could move and reorder (even rename and remove) properties after the fact...
This is exactly a problem I've had as for some reason the order properties appear is inconsistent. What's more annoying is that the properties in the database have sort values against them. It's as if the thought has been considered but the implementation never finished.
Raised again recently in Marc Goodsons rant/post here (https://our.umbraco.org/forum/core/general/73809-no-more-master-doctypes-in-74-beta-is-this-really-an-improvement#comment-236623). Something I've been after for ages. I wonder if it should be visible in developer mode at least. We used to mess around with tab sort orders in similar ways giving ones we always wanted to be out the way on the right hand side super high numbers?
@peteduncanson not a rant by any means, :-) but would be ace to have, when we design a site for editors to use, the order of the properties in the CMS form a mental map between back office and the content displayed on the site; it's difficult to articulate but it feels 'wrong' to an editor when you type Title, BodyText, Summary, ArticleDate or have to switch tabs; when you want Title, ArticleDate, Summary, BodyText. Teaching content editors you notice when things make sense, without explanation as to why they are, leads to happier editors...
With all the love given to the document type ui in 7.4 this is an absolute must to get fixed. It was the first thing i tried to do and was blown aways it isnt possible. We can't have editors getting lost in randomly placed tabs.
I agree. It is a huge missed opportunity with all the work done around doctypes in 7.4 that this has not been fixed. All the other improvements in 7.4 are nice, but they concern things that weren't really broken, whereas this is very broken and has been for years. Even if it means delaying 7.4 - this HAS to be fixed. Now is the chance to get it right.
The big problem in this regard is that master document types are gone, so in 7.4 compositions is the ONLY option, making it even more important. Before 7.4 you could just use master document types.
Digging a bit deeper it seems its actually possible to sort both tabs and properties. But its very confusing as i already mentioned in August. https://umbraco.com/follow-us/blog-archive/2015/8/18/better-ui-for-building-better-websites/
To sort composited tabs you give them a numeric sort value on the child itself. Example: If you want your SEO tab to be last before generic properties, you could give it 800. This works, but its not very elegant, and will get messy fast.
It would be good if you had ultimate overall control of the properties and allow the current document type's properties to be sorted in which ever order you want specifically to that document type.
This is still an issue, with parent doctype properties, you cannot move your properties in front of them, or inbetween them, which might make more sense for the editor.
While it seems like a simple task, it would require a complete change into how doctypes are related which makes this much more complicated than it might seem. Instead of relating a doctype to a doctype, we'd need additional information about how each tab and each property is related and sorted on each specific composition. A change like this turns into a can of worms as we'd need to re-write logic, create a new db structure, update package import/export, courier, make sure that it'll update existing implementations when you upgrade, etc.
I like @marcemarc's feedback here because it helps us to understand why this is important. We always do our best to balance priorities when improving the core and if you poke around the issue tracker, there's hundreds of things that are of HUGE importance to different people.
If its not possible to manually control the order that tabs and properties from compositions are displayed, could their ordering at least be made consistent? I have doctypes that inherit the exact same properties and they'll display tabs and properties in different orders. It makes it hard to find stuff when you're trying to use these doctypes.
In v7.5+, I can set a specific sort order number for tabs but I can't for properties. For properties, I can just drag them around. Would it be possible to add a sort order field for properties? This would give more control when merging things from different compositions. This would be a global setting for the underlying composition, so I don't think it would have the baggage of being able to sort properties every place it is composed.
@bitmapped all the properties have a sort id number stored in the DB within the context of their composition, so you can work around the ordering limitation, by adding Fake Label properties above the items you want to move downwards on a composition - when the properties are merged with other compositions on the same tab, then delete the fake Label properties, (the genuine properties beneath will keep their increased sort order number! and stay where you pushed them down to) or you can use SQL to achieve the same, eg write out the combined properties on a bit of paper how from the different compositions, and update their sortOrder number to reflect this order...
Update cmsPropertyType Set sortOrder = 5 where Alias = 'propertyAlias'
@marcemarc Thanks for the suggestions. I've been using sortOrder and that works, but this is not at all user friendly. Neither is the hack of adding and deleting properties. We need a solution similar to Tabs where users can directly specify the sort order in the GUI.
@bitmapped completely agree, it will be hard as @hartvig says above to do this perfectly, but a step in the right direction to make it less of a techy hack, would be in reordering mode on a doc type / composition, to display the sort order for the property that is already stored in the database, and enable the dev/implementor to override these numbers - just as they can for tabs - and then they will be able to fudge the order of properties when they are combined from different compositions on the same tab, without having to resort to technical trickery, I've added a screenshot
@marcemarc Adding a text field like you've shown is basically what I'm looking for. That would allow users to customize things as needed without having to hack the DB or use cumbersome workarounds.
@bitmapped @hartvig I've had a bit of a naive experimentation, and have gotten something sort of working here: https://github.com/umbraco/Umbraco-CMS/pull/1817 see screenshots, but it would need a bit of discussion about whether this is a good interim compromise, or just more noise to people sorting their properties - I suspect if you've come to this issue, it will feel like a good thing to do, but might confuse people new to Umbraco, but anyway the idea of trying it out a bit in this pull request, might make it easier to visualise / discuss and enable someone to tidy it further, or move the conversation on a bit...
@marcemarc yes, that will defo need a "tidy" :)
My naive expectation when composing a doc type from two compositions with tabs of the same name -- sorting would follow the same rules as sorting of tabs:
This seems like a reasonable expectation to me, given the existing tab-sorting behavior. It also may be less a "can of worms" than allowing for the specification of sort order on a property-by-property basis within the composed document type. Again, it's likely a naive perspective.
@jsubat yes it is the unexpectedness of the current outcome that throws people, if it worked as you suggest then it would make more sense to people as to what was going on, the above is more of a sticking plaster on the current setup
This issue is really starting to make me uncomfortable. I'm repeating the same pattern of properties in multiple doc types because there are small additions I need to make, but I don't want to spread my properties over 2, 3 or 4 tabs. Between this issue and the missing functionality cited in U4-6738, I'm finding compositions only help me trivially. If the sorting issue were addressed, compositions would be a lot more usable. If we could nest compositions, they'd be truly powerful and, quite possibly, a key differentiation for Umbraco.
I'd be willing to contribute to a solution for the sorting problem, but am not qualified to lead the charge. Anyone else interested in working on this?
@jsubat What do you think of the existing pull request on sorting? https://github.com/umbraco/Umbraco-CMS/pull/1817 for me I'm finding it makes some of the pain go away, I guess the problem with switching to the sort by composition first and then by properties within that composition is it would break a lot of existing sites if it were introduced, so it might be a change being held back or I guess it could be another setting 'LogicallySortPropertiesInCompositions=true' so the 'sticky plaster' might be the quickest thing we can get accepted into the core that does make things a little better, whilst rethinking this 'properly' may be more involved for the core team.
Thanks, @marcemarc. Have a project with a past-due deadline, and it'll be a few weeks before I can come up for air.
I'm not sure about nesting compositions, that could lead to a complete mess faaaaaar too often for my liking and one that would be very tricky to get out of. Don't underestimate the cost of the "handover tax", someone else one day will have to take the site on and might get in a whole mess real quick with nested comps.
I've seen a quick demo of this PR with @marcemarc and think it actually does what we all want quickly and easily within the existing code base (ie no major rewrite needed of compositions etc. that @hartvig talks about). Trouble is the screen shots don't do it justice. @marcemarc is there any chance you can post one of your little videos about this one?
It would need a little design love from HQ but as a "get us out of the hole for now" fix I think it does the job wonderfully. A fuller more "sexy" solution can come later once we've had time to play with this on in the wild I think. Ultimately we shouldn't have to fudge this functionality by adding and removing properties to set the sort order one time only (great tip by the way and I've used it a number of times) and certainly we shouldn't have to pop open the DB and go editing tables to get this. Both of which get seem to get over-ridden when you resave anyway.
If we had a video and folks saw this in action and it got a little polish then I think this should be considered as a quick win for now. Thoughts?
I couldn't agree more, Pete. And a demo video from @marcemarc would be very welcomed :)
@sniffdk @peteduncanson @hartvig I'm not so sure we should yearn for one of my 'little videos' as you put it, as each attempt I make at them seems like an ironic parody of my general lack of video putting together skills... but in part 1 - I sort of describe the problem (including the low tech fake label adding solution) and then the video recording thing runs out of its free 10 mins, and so in Part 2, it actually shows off the pull request... so if you sort of understand the problem you can go straight to part 2, although it starts with the end of the label demo, and won't set you up for the unicorn killing pay off... Part 1: https://www.youtube.com/watch?v=2PRkYXTIp-Y and Part 2: https://www.youtube.com/watch?v=FfEReh7yleI
I think something simple like this would be a great stop-gap measure for this issue. There is already precedent with the Tab Ordering and its intuitive.
@marcemarc rough video editing skills indeed :P but the PR looks perfect for (my) current needs, good job!
Thanks @marcemarc for the PR & videos This has been merged in - however the additional click to toggle this seemed unnecessary, so I updated your PR & merged it in.
Thanks again for this & this now is a lot better than what we had yesterday motto.
oh man, that's awesome, Warren, thanks ! :D
Thanks @warren.buckley and @marcemarc for this, it is exactly the fix I was after. Unfortunately when you drag any field on the page now, every single property on the page gets renumbered 1,2,3,4,etc. The only alternative to moving a property now is to manually renumber all of the fields by typing new numbers, then use 10-spacing so you can rearrange later....then pray another user doesn't drag and drop to undo all your hard work. Is there a way to change the behaviour of the drag and drop?
@kurokaze204 I just ran into this same issue, and it is super frustrating. I previously had our compositions set with certain numbers so they would show up generally where we wanted them when used with doc types that had their own tabs and used some kind of spacing of the order numbers to have room for adding other tabs in the future. Now, I just added a new tab to a composition, did the drag/drop to reorder and ALL of my numbers change. It sounds like the same thing you described happening to you.
In addition, I then go into one of my doc types that use the composition and try the reordering but there seems to be no way to edit the order...@warren.buckley am I missing something about what this feature was supposed to do besides break what we have built up over the years? I'd prefer this thing to be dumb and not reorder the numbers for me, or have a setting to enable/disable this auto-reorder. (and sorry if my tone sounds negative, but that's how I feel when I am trying to do work and a feature unexpectedly just breaks my stuff)
I know you're frustrated, but can you please spend a few minutes try to understand how it works at the moment?
So, in the beginning, before 7.6.7, there was absolutely 0 you could do about ordering tabs in compositions except for a dive into the database.
Now it is (in the words of Marc who graciously donated his time on this for everybody) "slightly less bonkers": https://youtu.be/FfEReh7yleI?t=1m7s
Is it perfect? No. Our current way of building doctypes does not allow it to be perfect without a huge amount of work to decouple sort orders into composition-specific sort orders. In other words, we could definitely let you drag-and-drop-sort everything right now, but as soon as we allow that, you will change the order and WHOOPS you've just changed the order for ALL the other document types that are also involved in this composition.
So. Right now: you can give each tab on each individual document type a manual sort order (a number you like). That's it. That means: yes, you need to be very careful when you update them, we don't consider the compositions (see above for complexity reasons).
This is no different from what used to happen before this change, if you had manipulated the sort orders manually in the database, then did a sort in the UI, all of the orders would reset as well. The only thing this provides is a way to not have to jump into the database to update the sort orders.
But.. it's "slightly less bonkers" and you don't have to jump into the database to do this any more. That's it, that's all you can expect in the foreseeable future.
Type: Feature (request)
Backwards Compatible: True
Fix Submitted: Pull request
Affected versions: 7.2.6, 7.5.0, 7.5.6
Due in version: 7.6.7