It would be great to have [nid:n] hidden form the user perhaps in a hidden field.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

yched’s picture

True, I'd also prefer them to be hidden. The whole notion of 'node' is absent from drupal UI, let alone nids.

Unfortunately drupal's current autocomplete feature does not allow multiple target fields on clicking on a completion proposal.
I tried to propose a rework of autocomplete in that purpose a few months ago, but it did not catch (and my proposal was probably not so good after all). See http://drupal.org/node/125231.

Thinking about this now, I'm saying we could maybe hack this on our own, by adding an additional JS event on the autocomplete field, so that when the regular autocompletion updates the content of the field (and adds the [nid] part), our own jQuery bit could simply intercept the '[nid]' part and paste it in a hidden input.

Well, not too clean, and I'm not sure I really feel like spending time on this right now.
Leaving the issue open for feedback, if any.

Keith Adler’s picture

Disappointing that it functions in such a lose fashion. I will address it as I think it seriously impairs the value that can be created from Drupal by having it.

yched’s picture

I might not like the [nid] part from a UI point of view, but I'm not sure what you mean by 'loose fashion' ?
AFAIK, it's not 'loose', it's actually rather reliable...

z.stolar’s picture

@Keith Adler: Did you manage to progress on this?

dydecker’s picture

Version: 5.x-1.x-dev » 6.x-2.0-rc4

Is there a way to accomplish this in Drupal 6?

Moonshine’s picture

Wow, this one goes back further then I would have thought. I agree [nid:x] really needs to be hidden from the user. Honestly I can't see using autocomplete unless it is :/ I guess I'll have to dig in further as I assumed it was a simple display issue, but it sounds like it's actually used in some way.

KarenS’s picture

The nid has to be available somehow because titles are not unique. Without the nid if there are duplicate titles there is no way to know if you have found the right one.

Moonshine’s picture

Yep, I'm with you there. :) I'm just thinking along the lines of Yched above, where jQuery could do some behind the scenes work to keep that info available. I actually have this on my "rainy day" to-do list and hope to get to it in a few weeks here.

cdale’s picture

I just created an issue that people here might be interested in #322383: Autocomplete nid/vid extraction. i.e. CCK Nodereference.

Dracolyte’s picture

Karen's point is a good one. Unfortunately, my client won't accept the visibility of the [nid: NN]. So call me a shameless hacker, but all I did was change this line (in 6.12 it's line 901) in the cck nodereference.module from this:
$matches[$row['title'] ." [nid:$id]"] = '<div class="reference-autocomplete">'. $row['rendered'] . '</div>';
to this:
$matches[$row['title']] = '<div class="reference-autocomplete">'. $row['rendered'] . '</div>';

Are there any horrors I've unleashed by doing so?

KarenS’s picture

#10, if you have any duplicate titles you are hosed, you have no way of knowing if you found the right match and you might be either storing or retrieving the wrong one. If your titles are unique it will work.

markus_petrux’s picture

One possible approach that could make things easier would be adding an flag in nodereference that can be used to disable the output of [nid:n]. Maybe a hook, or maybe an additional argument that could be passed somehow to the autocomplete widget. Such a flag could be exploited by modules such as unique_field, or custom modules.

Dracolyte’s picture

Yes, I agree with Karen in #11 completely. I'm using a view that will help reduce possible redundancy, and my "solution" is really a cosmetic touch that will not be right for all sites.
One cool thing, though, is that using that same area of the nodereference module, you could easily write code that displays additional information about the node in a way that looks more user-friendly.
Thanks.

giorgio79’s picture

#7
I believe that having duplicate node titles is bad design and a bad practice. For one Google will filter you into oblivion.

That should not be the reason we have the nid listed there. I think duplicate titles is the issue that needs fixing, and [nid:xx] a removal :)

Aren Cambre’s picture

I believe that having duplicate node titles is bad design and a bad practice.

I strongly disagree. It is good that the node titles can be the same. Suppose you have a node type that will have many entries from many people or that uses the automatic node titles module. You have a risk of namespace collision if you force unique node titles. Or suppose you don't even care about the node title? Why not set them all the same?

It is good design that the NID is the differentiator and not the node title.

P.S., #234449: Remove [nid:xx] after referenced node is selected marked as duplicate of this.

giorgio79’s picture

Or suppose you don't even care about the node title? Why not set them all the same?

In that case a web CMS may not be what you are looking for...

Aren Cambre’s picture

Ok, well, I guess I will throw away my Drupal time tracking system because of the thousands of duplicate node titles. Thanks for the clarity.

giorgio79’s picture

#17 clarity is the last thing I see in having all node titles be the same...

#12 proposition seems to be the best, to preserve the current functionality and have a flag if someone does not want the [nid... stuff.

markus_petrux’s picture

Status: Active » Closed (won't fix)

However, no one has taken the time to work on that idea, so I'm afraid this is "by design" (because the [nid: x] is necessary to 100% prevent problems with dups) ...or "won't fix", unless someone comes with a patch for review, and even then I think it's too late during the life cycle of CCK for D6. Such a feature would have to be worked for D7, and then backported.

Aren Cambre’s picture

Project: Content Construction Kit (CCK) » Drupal core
Version: 6.x-2.0-rc4 » 7.x-dev
Component: nodereference.module » field system
Status: Closed (won't fix) » Postponed

Moving to 7.x fields module.

Seems like "postponed" is the correct status. "Won't fix" means rejection of the issue; instead, you're just awaiting developer availability.

yched’s picture

Project: Drupal core » Content Construction Kit (CCK)
Version: 7.x-dev » 7.x-2.x-dev
Component: field system » nodereference.module
Status: Postponed » Active

noderef is not in D7 core

bohart’s picture

for disable [nid:n] information without hack module i put this code to mymodule

/**
 * Implementation of hook_menu_alter().
 */
function mymodule_menu_alter(&$items) {
  $items['nodereference/autocomplete']['page callback'] = 'mymodule_nodereference_autocomplete';
}


/**
 * Menu callback; Retrieve a pipe delimited string of autocomplete suggestions for existing users
 */
function mymodule_nodereference_autocomplete($field_name, $string = '') {
  $fields = content_fields();
  $field = $fields[$field_name];
  $match = isset($field['widget']['autocomplete_match']) ? $field['widget']['autocomplete_match'] : 'contains';
  $matches = array();

  $references = _nodereference_potential_references($field, $string, $match, array(), 10);
  foreach ($references as $id => $row) {
    // Add a class wrapper for a few required CSS overrides.
    $matches[$row['title']] = '<div class="reference-autocomplete">'. $row['rendered'] . '</div>';
  }
  drupal_json($matches);
}
Ofer Morag’s picture

@bohart,

Would you mind explaining where this code goes to hide nid in autocomplete?

Thank you,

OM

bohart’s picture

@Ofer Morag,

if you want remove [nid:n] information from autocomplete nodereference field than you can load and enable module from attachment.

cdale’s picture

It should be noted that the code provided in #22 and #24 will not handle the case where there are two or more nodes with the same title.

danielb’s picture

mautumn’s picture

@bohart, when your mini module is installed, is there any configuration required? I have installed and activated it, I cannot see any config anywhere, no readme.txt - and yet it doesn't appear to be having any effect... Am I missing something?

On this little debate about [nid] in displayed titles, this is the most ridiculous idea I have come across in nearly 30 years of software development!

  • This is an extremely poor and confusing UE (User Experience) - a strong enough reason on its own not to use it in commercial applications.
  • This gives away potentially commercially sensitive information - [nid] is a row counter...
  • I fail to to see how a [nid] can help a user choose between two or more identical node titles. Are they supposed to remember the [nid]s of every record?!

I fail to understand why a designer even offers the nodereference autocomplete unless they are using unique node titles - either directly with an appropriate primary key (like unique account numbers), or indirectly, using automatic node titles - e.g. name and postcode.

For those of us who know about primary keys, autonodetitles, and the like - who never have duplicate node titles - we should not be penalised and forced down this amateur route. #12 seems to be the best compromise.

mautumn’s picture

@bohart You mini module is working now! Partly. It works when selecting a record via Autocomplete. However, it doesn't work when selecting a record via Search-and-reference - part of the Node Relationships module. I guess this wasn't not in your initial remit?

tmase’s picture

If anybody is interested in how to NOT display the node-id in the selected value, here is the sollution:
Open the file autocomplete.js in the misc-folder of your installation.
On line 147 delete the piece of code "this.selected = node;"
Should help ;)

SeanA’s picture

How about an extra option under the widget settings that allows the [nid:xxx] display to be turned off as in #10? Along with a description that says something like "disable this only if the referenced node titles are unique (such as provided by the unique field module)".

Aren Cambre’s picture

Expecting that few end users care about NIDs, seems like it should be hidden by default. Maybe should instead show by role?

xlyz’s picture

+1 for roles as per #31

fgm’s picture

Project: Content Construction Kit (CCK) » References
Version: 7.x-2.x-dev » 7.x-1.x-dev
Component: nodereference.module » Code

nodereference and userreference for Drupal 7.x are now maintained separately in the References module: moving issue over there.

jcarlson34’s picture

Subscribing...

perandre’s picture

My support goes out to #31.

fgm’s picture

Component: Code » Code: node_reference

Categorizing.

kevinob11’s picture

I am in agreement with #31, I think role based or not showing the NID at all makes the most sense. However I think the nid still needs to be passed in a hidden input, as I believe there are plenty of legitimate reasons to have non-unique titles (tickets in a customer support portal where ticket title is a subject defined by the customer, event signups where no title is necessary, etc etc). Actually I think it makes the most sense to allow users to choose what they want displayed there. If you have an autocomplete that selects from more than one node type I could see wanting "type: title" to be displayed and nid to be passed in a hidden field.

yched’s picture

+1 for #37 - The real fix is an 'advanced' autocomplete element that fills the nid in a hidden input. Core doesn't provide that, but noderef can definitely ship with its own.
Another one of those developments that never happened in noderef D6 because it was too buried in the CCK package to receive the love and features it deserves.

obrienmd’s picture

+1 on #37, it doesn't make any sense at all to base a noderef on title, but being able to customize what is presented in the input box on autocomplete (perhaps driven by the same view as autocomplete) is a huge need. I think having a hidden field for nid (the only important stored value for a reference) makes a ton of sense.

danielb’s picture

In response to #37
Currently the autocomplete suggestions do not show the node ID - it is only when you select an option that it appends the nid to the prefill. So the status quo does not help you at all in the scenario where you have multiple nodes with the same title. If you are selecting nodes by a view, however, you can add in any extra fields you like to disambiguate the autocomplete suggestions. There's your advanced option.
The nid stuff, which was added for internal technical reasons, should be hidden from the user.

danielb’s picture

I tried to come up with a cheaty solution without doing much work, but right after my javascript fired and removed the nid and stored it in a hidden field, something else kicked in and put it back :/ Going to have to do it the long way.

andypost’s picture

subscribe

perandre’s picture

I couldn't make the module in #24 work with autocomplete. It would save my day if it did.

moondev’s picture

You all may be interested in my module, it replaces the autocomplete fields with select drop-downs. That way i store the nid in the option value and just the title in the display:

http://drupal.org/node/1017756

good_man’s picture

After reading the responses, what I have in mind are two things to add:
- See how taxonomy autocomplete works (doesn't display nor tid, just term name)
- Replaces it in javascript, just like #365241: Add select event to autocomplete feature but with out hacking the core, e.g. in node_reference.js file.

danielb’s picture

I don't think there is any choice other than to hack/patch core, or duplicate autocomplete and call it like 'awesomecomplete' or something and change it to handle the key/value pairs. Then depend on that module. We could submit it to http://drupal.org/project/elements for consideration in core.

good_man’s picture

I've succeded in making this change along with #298676: Allow alternative nodereference titles, the noticable thing about references module is that it needs refactoring ASAP.

I'll publish the patch here once I done testing.

good_man’s picture

FileSize
10.33 KB

Well this gonna a long patch somehow, and changed the structor also, I used fakeadd to add the new required files because I don't have CVS access to this project.

Changes:
1- Extracted/modified field's new schema (nid, title) from node_reference.module to node_reference.install, not just it's the best place for it, also to ease the process of update hook_update_N().
2- Added node_reference.js that contains the required js code to override autocomplete's default behaviour.
3- Modified the main file to make the autocomplete field into a fieldset that contains autocomplete field to hold title value, and a hidden input to hold nid value. You can autocomplete the title then change it (e.g. add some letters), and it's still true, so this will solve #298676: Allow alternative nodereference titles too.

Finally, I've done a lot of testing, really a lot, but you may expect some bugs, I've added some @todo so if you can help with them please jump in.

The patch against the latest header.

obrienmd’s picture

good_man, I will test further tomorrow, but should this work w/ views providing data for display (rather than raw title)?

good_man’s picture

I didn't understand your point, but until now no views support yet, just the regular views' support for fields, i.e. NO relationship for node ref. or user ref, but you can get them outputed in a view just like any other field.

I'll try to work on that too, but after that what I really want to see is:
1- refactor both modules, node ref. & user ref. many code can be abstracted.
2- use relation module (if it makes sense to use it), but it's a step 2, as relation is not ready yet AFAIK.
3- from point No #1 we have additional ref. like fields ref. and comments ref.

danielb’s picture

good_man’s picture

Status: Active » Needs review

ok let's now ask for a review.

Status: Needs review » Needs work

The last submitted patch, custom_title.patch, failed testing.

good_man’s picture

ohh the test is different from the new head now, will reroll a new one.

good_man’s picture

What the heck with the current head? it's pointing to an older version than 7.2 tag? should I keep this patch against the head or 7.2?

fgm’s picture

Version: 7.x-1.x-dev » 7.x-2.x-dev

All work should currently be applied to 7.2.

Note that all features are postponed until after we have a proper release with all bugs fixed.

good_man’s picture

Are you refering to Views integration or other issues?

shaunjohnston’s picture

If it is of any help to anyone, I have written a small module for D6 to (allegedly) cleanly strip the [nid:n] from autocomplete text fields while preserving the node id association.

It does this by creating a hidden field for each autocomplete field, and in principle turning the visible field into a 'display' field. Any selected nodes from the autocomplete dropdown are then funneled through the displayer, which passes them to the hidden field and then strips the [nid:n] for display.

This is done via jQuery, and no core code is hacked to make it possible. It could probably be vastly improved, and also easily adapted to D7. Admittedly it is still a workaround and doesn't address the core issue, but at least it helps to mitigate the UI issue without breaking maintainability.

I posted the module in a related post on the CCK issue queue here: #640832-7: Remove [nid:n] in nodereference fields, so only title is shown

danielb’s picture

I think a fix for this could be easily based on sdj's js code, just port the behavior to Drupal 7 and attach it in the right place.

good_man’s picture

@danielb: sdj's js code won't store the title, it will only remove [nid:n] from the text field, so do we need this one or a custom title? if the latter the title of this issue should be changed as well.

shaunjohnston’s picture

My feeling is that 'Custom Title' node reference fields should be in a new widget (or at least there should be a flag when selecting autocomplete for a node reference to turn custom titles on or off). There are many instances where I use nodereference autocomplete, where the user shouldn't be able to specify a custom title.

CUclimber’s picture

Would it be possible to configure the display so that instead of just the Title field we could choose to have an additional field? For example, if I have 3 nodes called:

Broadway Theater [nid: 5670]
Broadway Theater [nid: 5671]
Broadway Theater [nid: 5672]

It would be far more useful for my users to see it along with part of the Location field, such as:

Broadway Theater - New York, NY
Broadway Theater - Boston, MA
Broadway Theater - Los Angeles, CA

It seems to me that this would be a highly desirable feature for autocomplete, or any list for that matter.

jcarlson34’s picture

@CUclimber there actually is a way to do what you want. This option was available in 6.x CCK node reference and is currently able to be patched into the References module. Once the bugs are worked out, it will be added to the module.

This option uses views to add and customize additional information for your autocomplete field. Check it out here: #945004: [release blocker] Missing views-mode for picking userreference and nodereference

geerlingguy’s picture

Subscribe.

phenaproxima’s picture

Status: Needs work » Needs review

#48: custom_title.patch queued for re-testing.

Status: Needs review » Needs work

The last submitted patch, custom_title.patch, failed testing.

marcoscano’s picture

subscribe

lionslair’s picture

Your awesomne thank you very much.

dgastudio’s picture

any update on this? how about show a custom field from referenced content instead of nid?

perandre’s picture

Just noticed this sandbox: http://drupal.org/sandbox/arshad/1446618 Check it out.

danielb’s picture

kervi I made a module for that http://drupal.org/project/field_reference
It still puts [a:bunch of:junk] in the autocomplete though :(

tomas.teicher’s picture

Is some of these solutions and patches made in that way, that works when I have two nodes with same title?

I am going to restrict references so user can reference only his own nodes. (with setting "VIEWS - NODES THAT CAN BE REFERENCED")
But two users can have two different nodes with the same title. Each user should see only his own nodes in autocomplete.

Would this work with patches above? Is [nid] information only removed from display or also associasion of title with particular nid is lost with these patches?

Desi Raaj’s picture

anyone willing to port this to D7?
using autocomplete widgets

shadcn’s picture

Desi Raaj’s picture

Thank you Arshad C.

dpatte’s picture

I totally agree with #40