U4-192 - Feature request: Add more meta data to Content and Media pickers

Created by Sebastiaan Janssen 16 Aug 2012, 06:43:53 Updated by Murray Roke 10 Sep 2017, 21:10:12

Is duplicated by: U4-1103

Relates to: U4-2747

Ok, I know it shows the title of what was picked, but that is not sufficient, especially where you have many nodes with the same name. It should show the full path AND provide a link to edit the content that was picked.

I don't think this should be in a 3rd party package. (also when used on macros you only get the default data-types)

''Originally created on CodePlex by [Myster|http://www.codeplex.com/site/users/view/Myster]'' on 11/16/2011 10:56:04 PM [Codeplex ID: 30595 - Codeplex Votes: 15]

Imported comments

''Comment by [shearer3000|http://www.codeplex.com/site/users/view/shearer3000] on 11/17/2011 2:45:31 AM:'' same goes for media picker. v5 pickers have this same issue BTW

''Comment by [jbreuer|http://www.codeplex.com/site/users/view/jbreuer] on 11/21/2011 9:43:42 AM:'' If I want to choose another value in the tree popup it should also open the tree with the currenlty selected node opened.

''Comment by [jbreuer|http://www.codeplex.com/site/users/view/jbreuer] on 11/21/2011 9:44:23 AM:'' For v4 this is a nice start: http://our.umbraco.org/projects/backoffice-extensions/extended-content-picker

''Comment by [jbreuer|http://www.codeplex.com/site/users/view/jbreuer] on 11/21/2011 9:46:36 AM:'' And the same goes for the media picker, but if it would be fixed for the content picker it will probably also work for the media picker since they use the same code I think.

''Comment by [hartvig|http://www.codeplex.com/site/users/view/hartvig] on 11/21/2011 10:06:53 AM:'' I've changed the title of the item and made it a feature request

''Comment by [tomnf|http://www.codeplex.com/site/users/view/tomnf] on 11/21/2011 2:18:13 PM:'' +1 Also agree that clicking Choose should bring you to the currently selected node in the tree

11 Attachments

Download 2536.patch

Download 2695.patch


Lee Kelleher 20 Aug 2012, 20:18:03

We've had several complaints on uComponents about this very issue. Refs: http://ucomponents.codeplex.com/workitem/14703 and http://ucomponents.codeplex.com/workitem/12817

Richard N Barg 20 Aug 2012, 23:38:24

As the catalyst for WI 14703, I am pleased to see movement here and receptiveness for addressing the issue of supporting full paths for links and for nodes in the media library. Thanks. Looking forward to implementation. Richard Barg (UCSF)

Douglas Robar 31 Aug 2012, 10:40:21

In a conversation with Niels earlier he suggested that he'd have a think about how to best do something about this as a new general convention without giving too much visual clutter - it's definitely achievable and should be easy to do elegantly as well.

Sebastiaan Janssen 31 Aug 2012, 11:36:57

I've put it on my list of high priority items, should fit in the next sprint so we'll have a look when planning that one.

Funka! 31 Aug 2012, 16:40:59

Throwing out some suggestions here, (1) you could keep the main look of the picker mostly the same, revealing the full path to the node (and maybe node ID) in a tooltip when you hover over it. It would also be nice (2) when you already have a node picked, and you click Choose again, that the picker expand itself to reveal/highlight the currently-picked node (instead of always starting with collapsed tree and no indication of what was previously selected). In fact even if you just did this 2nd suggestion, people could verify which node was picked by just opening this again.

Richard N Barg 31 Aug 2012, 19:26:45


It is music to my ears that you have agreed to put this on the list of high priority items. It's really become a vexing issue on both the content side and media library side.

Just yesterday we had an issue with a company that had licensed us an image. The vendor was very insistent that we update it with a newer version. I tried to placate this vendor/licensor while I was on the phone by making the substitution, but then I couldn't find the existing out-of-date image because one of our users had inadvertently placed it in the wrong folder, which turned out to be a place you would never have expected it to be. It took me 30 minutes to find the item as I had to wade through folder and folder of media images. (see attached images). And the licensor was quite annoyed. This was really torture. All of this could have been avoided if there was a clear, visible path to that item in the content area where the image was inserted. Finding this file was like looking for "a needle in a haystack".

I'm glad that Umbraco is listening to its users and I look forward to seeing this implemented in the very near future.

Richard N Barg 31 Aug 2012, 19:41:32

I'd also like to respond to Funka!'s suggestion. I am not entirely sure what he is getting at and would invite him to post some images that reflect his thinking. I did want to respectfully disagree that the path should be reflected in a tooltip. When a user selects an item in a chooser, the entire path to the item should be completely visible. Attached is a screenshot of a legacy MNTP that we adapted to show full paths. The image displays locations on for sites where the biography of our Department Chair is listed on. The full paths provide invaluable and essential information to our users who don't want to inadvertently locate the bio on the wrong site. So having it fully visible vs. a tooltip is highly useful. Not having this feature in the current uComponents and/or core has created an extra headache for us when upgrading.

Richard N Barg 31 Aug 2012, 19:50:53

Attached are screenshots of a concept for a content picker control that could update the UComponent file picker to provide valuable information confirming the user's intention. (note the top node "bios" has since been renamed "biographies")

Funka! 31 Aug 2012, 22:41:35

Hi Richard, ... Your "Tree Information.jpg" picture you just posted a few hours ago is pretty much what I had in mind for my suggestion #2, so when Doctor Michael is already picked, and you click CHOOSE again, the picker opens up with this node already expanded and highlighted.... (Just the picked node would be highlighted, while the folders with the other yellow marks on them would be simply expanded.) So when I said that even if the full path isn't shown up front, you could at least click CHOOSE again and see where the item is located. (This would have avoided your haystack nightmare.) So that is what I meant in agreement with you.

The other image "content-picker-idea.jpg" is very familiar since it's the one I posted over on the uComponents tracker many months ago! I only today also added suggestion #1 which is if Niels was worried about the "visual clutter" of always showing the full path, that hiding it behind a tooltip might alleviate that design concern, but you are right that that wouldn't always be as helpful in certain cases. Maybe a checkbox on the picker datatype so the developer could choose.

Richard N Barg 31 Aug 2012, 23:50:45

Right, Funka! for some reason I thought the content-picker-idea image was from our developer. Now I realize it was your idea. Your formulation of text to display is a big improvement over the user feedback our path gives, which the user has to mentally parse. I juxtaposed both of them in the attached image. Your concept is more user friendly and readable. Of course now that we have gone to the new UComponent, we have nothing to go on. We're SOL for standard URL pickers and limping along w/our obsolete but working MNTP.

Funka! 06 Sep 2012, 06:02:05

Hey, look at this cool package/extension I just discovered? http://our.umbraco.org/projects/backoffice-extensions/extended-content-picker ...Has been around for about a year and a half it seems and understands how to draw breadcrumbs in a way we have been describing/wishing.

I haven't actually installed/tried this package yet, so not sure if it can also do Media Tree? (Would be too bad if can only do Content Tree.) Also on an unrelated note, is disappointing personally that I did not know about or discover this package many months ago when it really could have been useful! :-( Will keep in mind for the future, unless hopefully Core decides to take this on. (Hint, hint, wink, wink!!)

Sebastiaan Janssen 14 Sep 2012, 21:01:11

Just to update this, we have heard you loud and clear. The 4.10.0 sprint is much more extensive than I'd anticipated at the time and we've had to push back a workitems to 4.11.0 and 6.0.0 to be able to accommodate the work ahead of us. Luckily, there's the picker that Funka! has posted and I imagine it wouldn't be too hard to customize this to support the media section as well.

We want to do UX updates in the next few months and would love to include this feature request in it, but it's going to take a while before we get to it.

My apologies for the overly optimistic estimation I've head of including this in the core soon, I didn't intend to raise expectations too high.

Adam Nelson 02 Oct 2012, 01:54:41

FYI - I've tried the Extended Content Picker (http://our.umbraco.org/projects/backoffice-extensions/extended-content-picker). The breadcrumbs are nice but do not update correctly when you choose a new content item - the breadcrumbs still point to the old article for the most part - the last part of the breadcrumb has a correct title only (but incorrect link).

Funka! 05 Oct 2012, 18:43:30

I present my very first official patch and would appreciate any review on whether this might be accepted? It basically adds the full "breadcrumbs" trail as a Title attribute on the picked value (so that you can see it as a tooltip), both when the page loads as well as when you pick something. I figured this way would be the least likely to break anything that expects the name to be just the name so I did not want to change that behavior. It works on both content and media pickers (and probably anything else based on the BaseTreePicker). Very simple solution but incredibly useful result to alleviate confusion I hope.

Although the changes I made are very minimal, let me know if you prefer the full fork for submitting these. Thank you!

Sebastiaan Janssen 06 Oct 2012, 13:54:29

Thank you Funka! I took it a bit further and made the title attribute into a simple tooltip when hovered over, this should help discoverability. I was also trying to open the tree in the selected location but I haven't yet been able to figure out how that works. This is included in 4.10.0 (see screenshot)

Funka! 10 Oct 2012, 18:30:29

The tooltip code that makes this pop instantly instead of after the normal one or two second delay is indeed nicer!

I noticed however, when you have both a Content Picker ''and'' a Media Picker on the same document, the {{BaseTreePicker.js}} script is getting included twice---likely once by the SimpleContentPicker and again by the SimpleMediaPicker?---and the tooltip focus code is binding itself and firing twice. This has the effect of creating an extra, empty "treePickerTooltip" paragraph at the end of the body, which explains the tiny 6-pixel box in the top left of the main tooltip under these cases. (See screenshot.)

Sebastiaan, I thought I would try and help out by modifying the jQuery tooltip code to detect if it has already initialized and then not repeat itself if it has... but perhaps the better solution is to find out why this resource is being included twice---since there are ''other'' things (such as Umbraco.Controls.TreePicker initializing) that probably should only be running once as well? I'm not familiar enough with how the resx files and ClientDependency attributes play together to even know if this is possible, but I hope it should be.


Richard N Barg 11 Oct 2012, 19:04:36

Look forward to all of this sorting out into a fully optimized extended-content-picker. As shown in the screenshot below, our programmer was successful in creating a workaround for the(pre 4.8) Ucomponent tree picker (that presumably has been migrated to the core) to support a display of the full file path. We will, of course, be sharing this wordaround code w/the community shortly.

I do want to clear a few things up and perhaps get some clarification from you.

The UComponent version of the tree picker itself appears to be versatile than the standard legacy picker.

Lee Kelleher 12 Oct 2012, 09:19:59

@Richard, the component in your screenshot is UrlPicker, which is still part of uComponents, (it may be migrated to Umbraco core in future - but nothing confirmed yet). We'd welcome your contribution into uComponents. Thanks.

Funka! 16 Oct 2012, 21:38:49

@Richard (and Lee, please feel free to confirm or deny!), it looks like the uComponents UrlPicker inherits from the umbraco core's SimpleContentPicker/BaseTreePicker, so should benefit from the same changes mentioned above that are coming in 4.10.0 with no changes needed from the uComponents team.

Personally, I too usually prefer the uComponents UrlPicker but sometimes the simplicity of just picking a single NodeID is also warranted. Not sure what exactly you were hoping for clarification on...? Please take a look at and vote for U4-844 if you'd like to see this wonderful datatype in the core.

Lee Kelleher 16 Oct 2012, 21:42:58

@Funka! Yes, the UrlPicker does re-use the core's SimpleContentPicker control. So yes it should pick up the enhancements (I haven't tested that yet).

Funka! 16 Oct 2012, 22:50:35

I found out why the {{BaseTreePicker.js}} script is getting included twice when you have both a media picker and a content picker on the same document and am including a patch to resolve this. This fixes the "tooltip in a tooltip" I pictured above, as well as prevents unnecessary/redundant re-initialization of the TreePicker functionality. (Cleaning up the campground a bit!) Normalizing the script registration key to a constant easily fixes this, whereas before we found that the different sub-classes were each generating their own different keys {{umbraco.editorControls.pagePicker}} and {{umbraco.editorControls.mediaChooser}}, thus leading to the double-inclusion.

Sebastiaan Janssen 17 Oct 2012, 07:05:20

Hey Funka, thank you so much! Was going to look at this today, you just made my job easier: patch applied, pushed. #h5yr!

andrew shearer 12 Nov 2012, 02:17:01

the breadcrumb/tooltip that has been added in 4.9.1 is only slightly useful to content editors. Can i ask why you didn't use the same functionality as the uComponents MNTP (which is now in the core anyway) i.e. a popup that lets the content editor navigate to the actual content item!

Sebastiaan Janssen 19 Nov 2012, 10:49:58

@Andrew MNTP is a whole different beast. Current fix is a stopgap until we can find some time to implement the picker opening up on the picked item (as I said in http://issues.umbraco.org/issue/U4-192#comment=67-2956). We have limited resources and can't do everything that everybody asks for immediately, would love it if you could help us make it better, Funka has been a great help here for example.

Giles 22 Nov 2012, 18:12:12

I'm new to this but.. It looks like this update has introduced an assumption into BaseTreePicker that an umbraco node will be picked. This causes problems for Universal Tree Picker, which is derived from BaseTreePicker, but tries to pick from an external API (e.g picking a video from YouTube's Google data API).

I've been trying to find out if Universal Media Picker is still active or if it's been superceded by something new. If Universal Media Picker has been superceded obviously I'm barking up the wrong tree but if not does anyone have any thoughts on fixing the problem?

My initial suggestion would be to break BaseTreePicker into two: BaseGenericTreePicker <- BaseUmbracoTreePicker ..where BaseGenericTreePicker provides the functionality for picking from any tree of data and BaseUmbracoTreePicker generalises BaseGenericTreePicker, providing stuff that's specific to picking Umbraco nodes (i.e. item title, item breadcrumb)

I'd be really happy to have a look at this myself, but I'm not experienced with Umbraco so I'd like the thoughts of the person who added the breadcrumb code to BaseTreePicker first. Is that you Sebastiaan Janssen?

I think the functionality provided by Universal Tree Picker is really useful. And it's fantastically easy to add a new API to it. Maybe one for uComponents?

Sebastiaan Janssen 23 Nov 2012, 08:16:19

@Giles this has been addressed in U4-1241

Murray Roke 11 Mar 2015, 02:38:07

This has become a problem again in 7.x we've lost all the goodness we gained in 4.11

andrew shearer 11 Mar 2015, 19:40:00

a prime example would be the Umbraco.MultiNodeTreePicker datatype which no longer links to the underlying picked node like it did in 4/6. Quite an important thing for content managers.

Jeroen Breuer 12 Mar 2015, 08:26:53

In Umbraco 7.2.2 there is an experimental option which enables an edit button on MNTP. You can enable it on the datatype.

Murray Roke 22 Oct 2015, 00:30:15

The edit button is not the ideal solution in many cases. I don't want to edit the item picked, I just want to know which item was picked. This was a given a high priority in 4.x so it should still have a high priority.

chunsheng 22 Oct 2015, 00:33:24

+1 @Murray.Roke

Patrick Scott 22 Oct 2015, 07:59:53

@Murray.Roke @cairabbit Take a look at issue http://issues.umbraco.org/issue/U4-5764 This is essentially a duplicate issue. I created a patch which shows the full path to the node selected. Note, it will be best to do a diff merge of these files with the umbraco version you are using as lots of other things may have changed.

Shannon Deminick 26 Jun 2017, 07:15:15

Closing issue due to inactivity - see blog post for details https://umbraco.com/blog/issue-tracker-cleanup/

Murray Roke 10 Sep 2017, 21:10:12

This has been fixed now, hooray, I checked in 7.6.3 and you can see the full path of picked items, so this can stay closed. :-) (there is no edit link, but that is a secondary concern I believe)

Priority: Normal

Type: Feature (request)

State: Closed


Difficulty: Normal


Backwards Compatible: True

Fix Submitted: Patch

Affected versions: 7.0.0, 7.1.0, 7.0.1, 7.0.2, 7.0.3, 7.0.4, 7.1.1, 7.2.0, 7.1.2, 7.1.3, 7.1.4, 7.1.5, 7.3.0, 7.1.6, 7.1.7, 7.1.8, 7.1.9, 7.2.1, 7.2.2, 7.2.3, 7.2.4, 7.2.5, 7.2.6, 7.2.7, 7.2.8

Due in version:


Story Points: