Hierarchical Select for Node Reference fields

What kind of hierarchy do you propose then? Based on node type? On first letter of title? Or perhaps you just want to use HS's dropbox (i.e. the thing where you can add multiple items)?

Unless you come up with a patch, this won't be for soon. Too much going on already and I have to start finalizing version 3.

Seconding that this would be a very useful addition. There seems to be no proper dependent dropdown solution for nodes in Drupal, and HS for nodes would fill that (fairly large) gap very nicely. It would be especially good for location selection: First you would simply make node types for country & city, then put a node reference in each city to its country. That would give the nodes a hierarchical structure. HS could call all nodes of type "city" with the right country node reference to populate the dropdowns.

dydecker that's exactly what i would like do...

so.. tracking

For right now perhaps we can do something similar with a book...

I second this feature.

A hackish way to make this work would be to provide a taxonomy tree backend mirroring nodereferrences and then HS should just "work"...correct me if I'm mistaken.

For right now perhaps we can do something similar with a book...

It's possible, but there are two main issues in terms of using books for heirarchy: 1) you cannot specify the level a book page slots into, and 2) you cannot specify the depth the select list drills down to (by default it expands to 9 levels). So with a country/city/store heirarchy described above, you could put the city into the country section, for example, or you could add a store to a store to a store.

A hackish way to make this work would be to provide a taxonomy tree backend mirroring nodereferrences and then HS should just "work".

I think this is a better option. The issue then would be creating links to nodes & not taxonomy pages, which is possible using Taxonomy Redirect. The alternative is programmatically inserting values from taxonomy into nodereference fields, which seems way too roundabout for something so simple.

In the meantime, I am attempting to write a (hackish) dependent dropdown for noderef in Drupal 6. If I succeed, I'll post it here

For right now perhaps we can do something similar with a book...

It's possible, but there are two main issues in terms of using books for heirarchy: 1) you cannot specify the level a book page slots into, and 2) you cannot specify the depth the select list drills down to (by default it expands to 9 levels). So with a country/city/store heirarchy described above, you could put the city into the country section, for example, or you could add a store to a store to a store.

I have no idea what this means.

A hackish way to make this work would be to provide a taxonomy tree backend mirroring nodereferrences and then HS should just "work".

I think this is a better option. The issue then would be creating links to nodes & not taxonomy pages, which is possible using Taxonomy Redirect. The alternative is programmatically inserting values from taxonomy into nodereference fields, which seems way too roundabout for something so simple.

It's 3000% wrong. Don't do this.

In the meantime, I am attempting to write a (hackish) dependent dropdown for noderef in Drupal 6. If I succeed, I'll post it here

Don't.

What I need to know from you guys, is how you would like to see this hierarchy work. I think there are multiple approaches possible here. Let's try to find a consensus. I want mockups from you, either drawn in a computer application or on plain paper.

Okay, here is an initial idea about how HS could integrate with Nodereference. HS would provide the dependent dropdown capability, and nodereference & CCK weight would provide the structure behind it. The purpose would be to solve the longstanding issue of country/region/city selection in Drupal, although it would also have other many other uses as it would give CCK fields dependency.

First, you’d need a structure. The basic idea would be that each content type represented a different level of the hierarchy, as suggest in #4. For locations, for example, you’d create country/region/city content types. Then you create a nodereference field in each node referencing its parent, eg the California node has a noderef link to the United States node, and so on up the chain, to create the hierarchy. All of these node references should reference parents, not children.

Then in the content type you’d like HS to appear, you create new nodereference fields which link to one level each, eg country, region, city. HS gets selected as the widget type for these node refs. Then you arrange the weight of these in CCK so that HS can recognize the order of the fields. Perhaps these should be put in a group so you can have more than one HS per form.

What HS then does is populates the second field (eg state) by querying the State content type and returning all nodes which contain a reference the selected country. And so on down the line.

I dunno if that is too specific or not. But from a user pov it would seem to be an intuitive way of making a hierarchy with node references. It also just use HS as a widget rather than extending it into a new type of CCK field.

That won't work. The structure is loosely defined, it cannot be generated automatically. To put it simple: there's no function that I can query to find out what the hierarchy of content types is. You'd have to write that yourself.
Yes, creating an UI for this is possible. But I'd rather not do that. I'd prefer to see that as an add-on module.

Any other ideas that can work automagically, i.e. that don't require a UI?

P.S.: The country/state/city hierarchy makes more sense in a taxonomy. You could then still provide per-item information by providing one "information node" per term.

I'm trying to create a book database and face a similar task. I have author nodes referenced by "series" nodes and "book" nodes. (I use Views to show referring nodes on the "author" node). So, when I create a new "book" node I'd like to be able to limit the choice of the series by the author they referenced. I suppose series can be defined by taxonomy by authors and books have to be nodes.

By the way, I'm willing to sponsor the solution to my problem, up to $200 (not much, but unfortunately I can't afford to spend more right now)

this is the best solution for you:
http://drupal.org/project/relativity

esmailzadeh: while that may be a good module, it's not related to the issue being discussed here.

I'm looking to do the same thing. Right now I have three node reference fields in a content type that are related to one another. I'm looking for a way to do chained select lists. It is looking like maybe using the Active Select module API will be my best bet ( http://drupal.org/project/activeselect ) .

For example, I have a content type for 'Work Area', a content type for 'Equipment' which references the 'Work Area', and a content type for 'Problem' which references the 'Equipment'. These are master type tables with many records that I allow users to add records as needed. The final content type has node reference fields for 'Work Area' -> 'Equipment' -> 'Problem'.

I need to do the same thing and would sponsor up to $400 for it... So, that makes $600 total. I bet some of the rest of you can scare up a few dollars from your employer or client? :)

I have products tagged with a taxonomy and would like people to be able to drill down through the taxonomy to select various products to add to their personal sales pages.

In #196518: Token support for advanced view argument, CCK now has the necessary improvements for controlled hierarchies.

For now, the form must be submitted to have the field's value passed as the parent (argument) to another field. See #40 & the last part of #44 for ideas on how AHAH can complete the feature.

Subscribing...

I can make following module, for, like, $1000.
That module will use selected taxonomy vocabulary and use it's hierarchy to present to the user HS node reference widget that represents that hierarchy. It will be user responsibility to provide proper vocabulary. Though it will be easy with the modules such as Node Auto Term (you get term-node relationship for free when you create node). So with NAT module it will be possible to build flat vocabulary just in the process of creating nodes. Then you will transform it to hierarchical using something like Taxonomy Manager. And then you have hierarchical vocabulary where each term relates to one node and use HS widget with my module to select these nodes in Node Reference field.
In case when each term relates to more than one node it will work too: it just will be little harder for user to select: if term A is parent of term B, and there are several nodes tagged with A and several tagged with B, when you select ANY node tagged with A HS will expand to all nodes tagged with B.

Subscribing...

subscribing.

subscribe

subscribing!

Looks like no one is working this, so I'm taking a shot at this. The basic idea is to put a HS in widget setting form to let admin define a path in the hierarchy of node reference fields, and use this path to render HS for a particular node reference field.

So if we have content types like:

City
- State: Reference State

Address
- City: Reference City

Person
- Home: Reference Address
- Father: Reference Person
- Mother: Reference Person

Job
- Employee: Reference Person

then in Job.Employee's widget setting form, a HS is shown with the following dropdowns:
1st level: Person.Home, Person.Father, Person.Mother, where Person.Home can drill down, the other two cannot (no cycles)
2nd level: If admin chooses Person.Home in 1st level, then a 2nd level dropdown with Address.City is shown
3rd level: If admin chooses Address.City in 2nd level, then a 3rd level dropdown with City.State is shown

If admin has chosen Person.Home->Address.City, then in Job node edit, a 3 level HS is shown for user to enter the Employee:
1st level: City dropdown
2nd level: Address dropdown
3rd level: Employee dropdown

Let me know if you see any problem with this setup.

As long as it's abstract enough, I'll commit it. If it's not abstract enough, I'll still welcome it because it'd be a first step :)

Ok, here's my first crack at this. Once installed, select HS as node reference widget, in widget setting form, select referenced content types and save first, then use node reference path to define the hierarchy.

Still working on views filter part.

Hi jrao,
I tested your module, but it doesn't work.

If parent content type has a nodereference field too, there is an error message, when I try to set the nodereference path in field settings:
windows popup: "Received an ivalid response from the server"

If parent content type has no noderefence field, I can save the field settings.
But in node create/edit form, there is the same error after selecting an item in first selectlist (parent).

Perhaps the same mistake like issue http://drupal.org/node/617024 ?

Ok, here's completed version, with views filter module added.
- Install: extract the files to hierarchical_select\modules directory, then install them in Drupal
- Document: I added some comments on top of hs_nodereference.module on the design of this module, it also listed the example content types and field lineages I used during testing
- Usage of the field widget: See http://drupal.org/node/257922#comment-2201806
- Usage of the views filter: an extra option form is added for all node reference field filter, where you can choose to use dropdown (the old filter) or HS (the new filter). When using HS, you need to choose a content type for the filter. Then in option form, the same node reference path in field widget is displayed, use it to choose the field path you want to use

Micha1111: Thanks for testing the module, could you try the new version? If it still doesn't work, let me know your content types and node reference path, I'll try to reproduce it locally.

Sorry, but there is same error after installing your modul.zip files
Perhaps my own misconfiguration, so I try to explain, what I have done.

Content type 1:
leagues (10 nodes)
name

Content type 2
teams (10 nodes per league)
name
inleague => nodereference field to content type league

Content type 3
players (20 nodes per team)
name
inteam => nodereference field to content type team

Content type 4
matches (270 nodes)
home: select a league (level 0) => select a team of selected league (level 1) => select a player of selected team (level 2)
guest: select a league (level 0) => select a team of selected league (level 1) => select a player of selected team (level 2)
matchresult

Could you give a step by step tutorial for all settings ?
How to set the hierarchie ?
In which database tables are these settings stored ?

Thanks in advance !!

YES, I found out the problem !!

I'm using IE8, I think there is an ajax problem.
IE8 cannot show/open the next select box after selection of an item in first select box.

In FF 3.5 every thing works fine, very nice module !!
So, I don't need a tutorial.

BTW, I have problems with views2 too in IE8 => blank pages after changing some settings.

Is it a bug in hs and views ?

Micha1111: I'm glad it's working for you in firefox, however I couldn't reproduce the ajax problem under IE8 (either in compatibility view or non-compatibility view), seems to me HS and Node Reference modules works in IE8. Note I'm using latest HS 3.x-dev version

@Micha1111: You're probably using a conflicting module. Maybe jQuery UI?

@jrao: Great work! :) I'm inclined to not include this in HS itself though, because it's so big already. Maybe it's time for your own first module on d.o? :)

Wim Leers: Sure, let me just apply for cvs access and get this one published :)

Awesome :)

Ok, the code for this has been published as a separate module: http://drupal.org/project/hs_nodereference

Awesome! :) Congrats :)

Hi,

I have created two content types Country and City but the node reference path is always none, can you please tell me how can i add node reference path.

Thank you

here the same - path is not applicable.

Please open new issue on the project page http://drupal.org/project/hs_nodereference