Nodereference optional

This would require optionally adding some 'text' (and maybe 'format') columns to the existing 'nid' column in the field's db storage. Pretty much the same way text fields have an optional 'format' column. Then implement some logic to use the text as a fallback when no nid is available. Probably not too hard per se.
The Views integration part might be a little tricky, though.

This is not something I'm planning to work on in a near future. Anyone interested on working on a patch ?

it will be really nice to have such an option. the current nodereference has a flaw under autocomplete mode: whenever a user put something into the field which does not match an existing node (referenced), the user can submit the form. Content is created and the field is showing blank (even the field is set as required). user's input gets lost. not quite user friendly. I will be happy to see such a feature to be implemented in the future

I had the same need as zmove so I made a patch to implement this feature. It seems to be working in my testing, but still may need some polish.

If yched and karens don't want this as part of CCK, please let me know and I will pull this out into a separate module.

I found that Tokens don't work. I am looking into it.

This patch is working to save plain text or a node reference. Tokens are working as well.

Please review and provide feedback.

zmove and xqi: If this is still a feature you would like to use, please try this patch and post a review. If this has any chance of getting committed, we need testing by other people.

maintainers: I know you are understandably cautious about applying patches to the 6.x-2.x branch. Is this a feature that you can see applied to the 6.x-3.x branch? I am still struggling with the decision whether to fork nodereference and release a module with additional features or maintain a patch for my installation of nodereference.

maintainers: I know you are understandably cautious about applying patches to the 6.x-2.x branch. Is this a feature that you can see applied to the 6.x-3.x branch? I am still struggling with the decision whether to fork nodereference and release a module with additional features or maintain a patch for my installation of nodereference.

I can only speak by myself. The 6.x-3.x branch is designed to host the remove button, multigroup module and nested fieldgroups patches. So something like this extension to CCK noderef field would have to be developed under the 6.x-2.x branch. Anything that goes to 6.x-2.x, will also be ported to 6.x-3.x.

So this feature request is ok where it is. The problem I see is that everyonw involved in CCK is now mostly focussed on D7. I would say only bug fixes and minor features will be added to CCK2.

The patch here adds a complex feature to noderef, so it would have to be tested with a lot of sites to be confident it doesn't add a can of worms that would be hard to deal with at this point. The patch here seems to be a good starting point, now it would need as much reviews as possible. Next... I can't tell.

markus: I appreciate your response and I appreciate your efforts on CCK 6.x. I agree that this does add a complex feature and will require extensive testing before it can be committed.

everyone else: If this is a feature you think should be part of CCK, the only way it will happen is if multiple people provide testing and feedback.

To add to what Markus said, the main difficulty is not finding people to apply the patch, test it and say 'it works for me, +1'.
- It's finding people to review the code and make sure it's not evil, or doesn't lead to tricky issues later on. There are not much more than a handful of people able to do that for CCK, and 3 of them are buried with work already.
- It's also accounting for the fact that any new feature means additional code to later maintain, debug, support.

Related issue: #496114: Accept also usernames that are not provided by the autocomplete function

Hi, I've posted the issue Markus has referenced in #11.
I'd like to subscribe... maybe we'll get some pretty results also for the userrefence module.

Just wanted to point out that this is an AMAZING addition, kswan. Totally blows the autocomplete feature of nodereference to a new level! :D
The exposed filter part is my main wow-point, FYI.

Anyhow, just wanted to say thanks for the spectacular addition you posted:
#375690-14: Nodereference autocomplete doesn't match all of view's fields

Thank you for the kind comments, biocomp.pat.

To explain a little further, I refactored the patch in #6 above with the patch in http://drupal.org/node/375690#comment-1695154 plus the recommendation by yched into a separate module.

The new module is available on github at http://github.com/kswan/super_nodereference.

There is a much more complete explanation on the github project page.

kswan, thanks for the great module! I just sent an e-mail to your site and then thought maybe this is a more appropriate place to ask.

I have one question that I just can't seem to figure out. When I save the node it just prints out the field contents "XXXXX [nid:123]" rather than the "Full Node" as I've selected in the Display settings. The funny thing is, if just edit and re-save the node it all works fine.

Using Devel I've found that on the first save the field contents ("XXXXX [nid:123]") are being saved to the fields "['value']" and the [nid] field is NULL. When I resave the node it's populated correctly and the [nid:123] portion of the field is removed from the [value] and the [nid] is populated correctly.

I'm using a view with an exposed filter.

Do you have any idea how I could fix this?