nodereference : problems when different nodes w/ same title ?

And there's a related problem if you use a select list and have nodes with the same name -- you just get a list that repeats the title with no idea which is which. I'm one of the ones trying to make cck into my relationship application, and I also have a lot of repetition in node names, so I've run into this, too. I'm still noodling around on possible work-arounds...

I have played a bit with the relativity module which is kind of what I am trying to emulate. It has the same problem (only displays the title of potentially selectable node) but instead of presenting them in a drop-down select list, you click a link that says 'add to existing event' (or whatever the node type is) and it takes you to a list of events that you can select from. It still only displays the title, but the listing could be expanded to show other info from the node that would make it easier to pick the right one.

This is of course much more complicated that picking from a drop-down list or autocomplete box, but is probably the only way to ensure that you are selecting the right link. I could visualize creating the list using views, where you can filter it as necessary to find the link you want, then selecting it, but it would still be a 2-step process.

Other than that, I don't see a solution for anyone with a longish list of nodes that may or may not include duplication.

So, thinking further, maybe we need a third widget. Keep the two current ones, which will work fine for simple needs and short lists of available nodes, and create a third widget type that does the 2-step of taking you to a page to filter out the node you want, then attaches it.

I'm not sure I have time to work on this idea right now, but if you think it might work and want to give it a shot I can help you debug it.

Could this be a fast workaround?
Simply concetenate the nid with the title (in displaying the results, and also in the database queries)

--- Autocomplete field shows this: ---------------------------------------
[ John O]
John Doe [15] <= node id
John Doe [34]

The User would have no problem, because the Autocomplete function is somekindof full text search.
We could helpthe Use, if some other fields of the John Doe node would be included in the Autocomplete result set. And from the SQL point of view: Have a look at the phpmyadmin queries if you update one table row, you get a list of all columns in the WHERE statement (for somekind of 'this should really be the right row independent of all Index fields that exist') - and for us the node id should be unique and everything solved.

Thats some kind of thing I would like to have with CCK nodes. If I have for example a CCK content type of 'Peron' and I search for 'John' I would get my two nodes 15 and 34 with John Doe, but also would see f.e. the City and/or email of alls 'John')

--- Autocomplete field shows this: ---------------------------------------
[ John O]
John Doe - New York - john@doe.com [15]
John Doe - Chicago - johnny@gmail.com [34]

On the Widgets Settings Page, I would wish to have thepossibility to select which of the existing CCK content fields are displayed in the autocomplete result.
Autocomplete Field > edit > Widget Settings > Data settings > [v] Person *** [Multiple Select List of additional content fields to display] ***

As a workaround I will now force the node title to be unique.

# vi modules/node.module

function node_validate($node, $form = array()) {
  // Convert the node to an object, if necessary.
  $node = (object)$node;

//////////////////////////////////////////////////////////////////////
// UNIQUE NODE TITLE REQUIRED (PER CONTENT TYPE)
// to have no problems with nodereference to duplicate entries
// 2006-07-10 drupal@easytouch.at

  $which_types = array(); // in my case no exceptions

// if you want to allow duplicate node titles
// for some content types, uncomment this array
/*
  $which_types = array('book',
                       'content-company',
                       'content-person');
*/

  if (in_array($node->type,$which_types)) {
  }
  else {
    // search for node with this title
    $query = "SELECT * FROM {node} n";
    $query .= " WHERE n.title = '".$node->title."'";
    $query .= " AND n.type = '".$node->type."'";
    $query .= " AND n.nid <> '".$node->nid."'"; // this allows update of the actuel edited node itself
    $result1 = db_query(db_rewrite_sql($query));
    $row = db_fetch_object ( $result1 );

    if ($row) {  // result means the node title would be a duplicate
      $error_message = $node->type.' '.$node->title.' already exists';
      form_set_error('title', t($error_message));
    }

    if ($node->title == '4712') {
      form_set_error('title', t('Title 4712 is not allowed.'));
    }
  }
//////////////////////////////////////////////////////////////////////

Next step will be to lookup the node-types that are allowed to
be connect in the nodereference.module as yched mentioned...

@yched

Could you pleasegivea high level example (on your application level) how you have your content-types organized, that you need the same title within the same content-type? Would be interesting to know what the problems are in 'real project life' above the module layers.

I also have seen around the forums a lot of attempts where people are trying to get independent of the node-title, leaving it automatically filled and only use cck fields for the data. I am also thinking about displaying info about the active selected referrer node - at the moment between user has choosen it from the list and before clicking submit button - to help the user with his selection, if there are multiples. (but we first have to fix the nodereference.module to respect the allowed types)

I also must have the ability to allow duplicate node names. For example, I have a cck node for events and many events have the same name, esp repeating events. Trying to add enough extra text to make all of those names unique would make them too long to display well in a calendar.

I agree with yched on the requirements, I had tried to do something like this in one of the iterations of the nodereference field, but it didn't work (because the autocomplete only stored the name, so the database update picked up the wrong one). Yes, it will be difficult to figure out how to do it...

the solution that easytouch is proposing at #5 seems univoque and valid, always from a final user point of view ;)

also thanks easytouch for the workaround at #6, but pasting those lines into my node.module and uncommenting the array gives me following error:

Parse error: parse error, unexpected $ in /home/kiteatla/public_html/drupal/modules/node.module on line 2525

about the error at #13:
sorry, my bad,easytouch hack do work (thx yched, your comment made me give another try!)! I pasted the whole code in node.module, but actually function node_validate($node, $form = array()) { already exists there, so just skip the first 4 lines, and be sure that if you uncomment the array, that you remove the upper empty one.

about additional node fields to display:
@yched: if i understood right, what you propose is easytouch solution (#5, second part of the comment: have checkboxes to select which fields to display in select box) on steroids.
So far so good, as far as is not overkill for the scope, but i am no coder so i'd better shut up ;-]

yched (#15): I have my-own widget that displays one another node field in addition to node title. It helps to distinguish one node from another (with same title: it's a common place in my example), but I made it so brutal so I hesitate to represent it ;-)

I agree that Views module is the right thing to use instead of hard-coded database queries.

(#2): Another my project is a taxonomywidget that limits potential references by taxonomy terms with per-field settings. It helps to reduce a number of candidates and allows to implement more logic in use of nodereference field.

Now I'm updating it to use with my already published Add and Reference and Form restore modules: when You about to add a node from taxonomy-limited nodereference field (or edit already referenced) it must have altered taxonomy form with only allowed terms avaliable to select.

There's the trouble with 'tags' vocabularies: it needs for another settings to allow or not the creation of new tags from referenced nodes, if so - added tags must go in widget settings as allowed or we have an inconsistence.

Another trouble is a category.module. I don't like it but peoples do. Should I make it compatible?

I agree that we need a way to differentiate nodes with same titles for nodereference. I have a field that refers to blog posts and many of them have the same title. My field is a multiple autocomplete and I can select a blog titled "TEST" and one titled "test" hit save, and when I come back, only one of them is referenced. I do not feel this should go in another module, but rather be a patch to nodereference.module or the autocomplete widget. I did look at the above issue and saw it was "wont fix"ed. What is the current plan of action?

Fixed by recent commit to use views as nodereference selector.

Yched, there is another problem with autocompletes noted at http://drupal.org/node/83572. I'm having that problem myself and it's fairly critical -- once you select an item there is no way to go back to an empty option even when you have marked it not required. There is a patch submitted for that issue, but I don't know how that impacts what you're doing here. Can you look at that and see if we need that patch or not, or make sure that problem gets solved, too when you update the autocomplete feature?

Committted. Thanks yched!!

this isn't a problem if you create the relationship with the cck subform module

http://subform.googlecode.com/svn/trunk/subform_trunk.zip

(also provides incline CRUD operations on the child nodes right in the parent node page)