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

#48 custom_title.patch10.33 KBgood_man
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch custom_title_3.patch.
[ View ]
#24 nodereference_disable_nid module1.22 KBbohart


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

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.

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.

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...

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

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

Is there a way to accomplish this in Drupal 6?

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.

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.

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.

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

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?

#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.

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.

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.

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 :)

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.

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...

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.

#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.

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.

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.

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

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>';


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

Thank you,


new1.22 KB

@Ofer Morag,

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

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.

@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.

@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?

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 ;)

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)".

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

+1 for roles as per #31

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.


My support goes out to #31.

Component:Code» Code: node_reference


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.

+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.

+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.

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.

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.


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

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:

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.

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 for consideration in core.

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.

new10.33 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch custom_title_3.patch.
[ View ]

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.

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.

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

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.

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.

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

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?

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.

Are you refering to Views integration or other issues?

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

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.

@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.

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.

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.

@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


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.


Your awesomne thank you very much.

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

Just noticed this sandbox: Check it out.

kervi I made a module for that
It still puts [a:bunch of:junk] in the autocomplete though :(

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?

anyone willing to port this to D7?
using autocomplete widgets

Thank you Arshad C.

I totally agree with #40