This patch is an emanation from this thread (nodereference : problems when different nodes w/ same title ?)

It implements the idea submitted by JonBob in http://drupal.org/node/57902 (allowing the user to define the referenceable nodes by selecting a views.module view), and extends it by using this view's fields to provide additional info about the selectable nodes.

The intention is to avoid ambiguous node selection, for instance when several referenceable nodes have the same title, or when the title alone doesn't convey all the necessary information.

I guess the UI for the field setting form is still a bit rough, but other than that, it is quite functionnal AFAIK.

CommentFileSizeAuthor
#53 nodereference.module_10.patch2.52 KByched
#49 nodereference-default-views.patch_0.txt968 bytesEgon Bianchet
#47 nodereference-default-views.patch.txt806 bytesEgon Bianchet
#44 nodereference.module3.patch8.04 KByched
#36 nodereference.module2.patch8.13 KByched
#19 nodereference.module_8.patch8.23 KByched
#5 nodereference.module_7.patch6.94 KByched
#4 nodereference_0.module12.48 KByched
#3 screenshot-select.png4.5 KByched
#2 screenshot-autocomplete.png4.75 KByched
nodereference.module_6.patch5.83 KByched
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

yched’s picture

yched CreditAttribution: yched commented
Status: Active » Needs review

status...

yched’s picture

yched CreditAttribution: yched commented
FileSize
screenshot-autocomplete.png4.75 KB

Here's a screenshot for the autocomplete widget

yched’s picture

yched CreditAttribution: yched commented
FileSize
screenshot-select.png4.5 KB

... and another one for the select widget

yched’s picture

yched CreditAttribution: yched commented
FileSize
nodereference_0.module12.48 KB

Updated patch :
- rerolled against current 4.7 branch
- cleaner integration with views API
(an "even cleaner" version _might_ be possible if this Views patch gets accepted by merlin - current code is OK though)
- adds validation step on field settings form : does the submitted view really exists ?
- handles the (unlikely) case where the view does not contain the "node title" field

reviews welcome :-)

yched’s picture

yched CreditAttribution: yched commented
FileSize
nodereference.module_7.patch6.94 KB

Oops - I uploded the module itself...

Here is the actual patch

KarenS’s picture

KarenS CreditAttribution: KarenS commented

Hi yched!

I'm trying to get current with all the latest changes to cck and test out your patch (since I am one of the ones that needed this functionality), but I'm not sure everything is working as it should after my upgrade. Just reading through your patch it looks like there should be some place where I can select a views view to display, but I don't get that option anywhere (nor do I see anything about the formatter in any fields, for that matter). There are lots of changes to cck and I don't know if I am missing something in cck that should have gotten upgraded or if it is something in your patch, so any clues about your upgrade experience and where I should be expecting to see this option would be helpful.

Thanks.

yched’s picture

yched CreditAttribution: yched commented

Hi Karen, thanks for (trying to) reviewing this :-)

There should be a textfield on the bottom of the (nodereference) field setting form, below the "referenceable types" checkboxes, that allows you to type a views name. If you don't have that, something's wrong indeed...
(The UI on this field settings form is still raw BTW - I can probably do better...)

As for my personal cck upgrade experience (as I said somewhere in some other (?) thread), it went rather well, with two DIY steps :
- my views had to be resaved (the cvs log warned about that), plus have the types in their 'node: type' filters reselected.
- I had to manually update my customized version of date.module (the old one, now gone from cck 4.7, and which I'm still using until we can work out something on this issue in your own date.module ;-) )

But none of these two points seem related to this patch, so please let me know if you still have problems in applying it.

BTW : I do see field formatters options in the views fields table.

yched’s picture

yched CreditAttribution: yched commented

forgot to say : this patch requires 4.7 versions for everything invloved (core, cck, views)

Well I don't know if there really is a 4.7 views branch, but you got the point

KarenS’s picture

KarenS CreditAttribution: KarenS commented

I don't have that field, plus I am getting errors on content_views.inc right where it is trying to find the formatters, so something is definitely wrong with my installation. I guess I need to backpedal and see what I did wrong...

KarenS’s picture

KarenS CreditAttribution: KarenS commented

Finally got this working (whew!) I like this approach, it should work well. The main change I would suggest is offering a drop-down list of available views to choose from instead of the textfield (which also takes care of whether or not it is a valid view, at least at the time the field is created). A simple query of view_view is all it would take to create the list.

yched’s picture

yched CreditAttribution: yched commented

Yes, you're probably right about the drop-down list.
I will get that in the next version (it seems Earl has accepted a suggestion I made for views API, that will make the code in this patch cleaner - waiting for the commit)
Plus I also need to provide better explanation on the field setting form.

KarenS’s picture

KarenS CreditAttribution: KarenS commented

Now is it possible to blend this together with http://drupal.org/node/60756 so we only have one nodereference module? Or maybe set this feature up to be an optional additional module that builds on the nodereference module? Not sure what is best way, I just want to find a way to get back to a single base module for nodereferences.

yched’s picture

yched CreditAttribution: yched commented

These patches aim at completely different things, so blending them into one hybrid patch is no good practice IMO - "keep patches separate" seems a frequent advice in issue threads.
I'm aware that it makes reviewing kind of tricky when you want to follow two different patches, though :-/

Not too keen on externalizing this into a new module either- this patch is really about enhancing the usability of the original nodereferences widgets, I think it would end up being quite confusing to add 2 new widgets.
Plus my ultimate goal here is to solve the issue about autocomplete widget not being trustworthy (see
this comment on the original thread - second item), which is, I think, a "usability bug" in nodereference.module itself.
This patch is "only" a first step towards this, I another have patch ready (not posted yet, I'm still working out the best way to integrate with the jQuery migration thing, since it requires a modification of the core autocomplete fetaures) that takes care of that, and both should IMO land in noderenference/module itself.

On the other hand, the patch you refer to does seem to be about adding a new field type, so I think it would be a better candidate for externalization (and i think the last updater mentioned the possibility btw...)

Hem, I'm not really being cooperative, am I ?

KarenS’s picture

KarenS CreditAttribution: KarenS commented

I understand, I wasn't sure if it would make sense or not. I'm just trying to wrestle all these versions and patches into something coherent that I can rely on as the 'right' version to use to be sure my database will continue to be functional as cck matures, since I rely on this field extensively. I tried suggesting that someone set nodereference up as a separate project to help organize these efforts, but no one took me up on that idea :-)

yched’s picture

yched CreditAttribution: yched commented

I tried suggesting that someone set nodereference up as a separate project to help organize these efforts, but no one took me up on that idea

I guess I skipped that. It might be a good idea.

I guess this discussion is off-topic for this thread though (did I just dodge ?)

KarenS’s picture

KarenS CreditAttribution: KarenS commented
Title: Allow additional fields to be displayed about referenceable nodes » Use views as a nodereference selector

The discussion in http://groups.drupal.org/node/1323 made me realize another benefit of this approach -- you can use the view to filter nodes that can be selected from in any way you want -- by content type or date or title or anything else. That is *much* more flexible than just being able to limit the options to a specific content type. So that's another great reason to incorporate this functionality into the nodereference module.

I'm changing the title to reflect this, but feel free to change it back if you don't agree.

+100 on getting something like this committed. I think it only needs a bit more work (i.e. adding a drop-down selector for choosing a view).

edrex’s picture

edrex CreditAttribution: edrex commented

I'm interested in this patch as a way to implement flexible access control. For example, the view can limit available nodes to just those that are associated with a group of which the user is a member.

yched’s picture

yched CreditAttribution: yched commented

@Karen :
Yes, that was (part of) the point - even though my own private original itch here was the "display additional fields" part. I guess the title you've set suits both aspects :-)

One small remark about these "views defined" referenceable nodes : there could be some unexpected behaviour if the filters use time-related criterias, in which case a given node can get in and out of the scope of the view as time goes by.

Example :
- "my_content_type" contains a noderef field whose scope is defined by "my_view"
- you create a "my_content_type" node A, with a reference to some node B, that is in the scope of "my_view" at this time.
- later on, node B gets "out of the view" (gets too old, for instance...)
- as long as you don't try to edit node A, nothing changes, it still references node B
- but if you edit node A, even if you submit the form without changing anything, validation fails.

I'm not sure if and how we should deal with these cases.
Maybe just a warning on the noderef field settings page ?
Maybe check for the consistency of the reference on "node A" load / view ?

I don't think this should stop the concept from getting in, though.

I should post a new and cleaner version of the patch in the next few days, now that this Views patch got in.

yched’s picture

yched CreditAttribution: yched commented
FileSize
nodereference.module_8.patch8.23 KB

Updated patch :

In the field settings form :
- selection of the view using a drop-down select, as per Karen's suggestion
- some info about the "advanced mode" (maybe too much ?) in the views selector "#description"
Please feel free to correct / improve the wording :-)
In the code :
- cleaner Views-related code, thanks to a recent change in Views API

This requires the latest Views CVS (HEAD) - and, as previously, is targeted for Drupal 4.7 + CCK 4.7

webchick’s picture

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
CreditAttribution: webchick commented

subscribing; no time atm, but I owe yched a review on this one. :)

edrex’s picture

edrex CreditAttribution: edrex commented

+1 This patch lets me do cool s**t with CCK. Sweet!

Also, it doesn't introduce a Views dependency into CCK. If views.module is disabled the functionality bows out cleanly and the admin UI goes away.

I'm continuing to test this patch.

yched, what do you think about exposing exposed view filters to allow inline filtering? Not sure how this would work in terms of ui. If we did a fancy ajaxy inline submit we'd have degrade to something compatible. Popup? IFRAME? Just a thought. My use-case is to further limit very large sets of nodes ie by category.

yched’s picture

yched CreditAttribution: yched commented

@edrex :
I think I could see a use for this with the select widget, which could surely use a means to narrow the list- I don't quite figure out how this would play with the autocomplete widget, though.
Plus, I'm afraid the technical details are a little beyond me ATM. Let's get this committed first :-)

yched’s picture

yched CreditAttribution: yched commented

correction to the requirements :
patch in #19 requires latest 4.7 branches of everything invovled : Core + CCK + Views
(Views HEAD is now targeted for 5.0)

beauregard’s picture

beauregard CreditAttribution: beauregard commented
Title: Use views as a nodereference selector » How to use it?

I installed the newest CCK and used the nodereference.module_8.patch. On my website users can work with two custom node types: Schools and Courses. Now I would like that users creating a node "course" can reference only nodes of type "schools", which they created themselves. As I understand this patch is for this, but how to do it?

Thanks for any help

RayZ’s picture

RayZ CreditAttribution: RayZ commented
Title: How to use it? » Use views as a nodereference selector
beauregard’s picture

beauregard CreditAttribution: beauregard commented

yes, thanks... so easy. Looks great, will now do some testing

yesterday’s picture

yesterday CreditAttribution: yesterday commented

@Karen, #9:
I am having trouble using this patch (with appropriate CCK, views, core)... Creating new content types now throws some content_view.inc problems. Editing types with noderefs gives a form with no widget options. How did you overcome this in post #10?

KarenS’s picture

KarenS CreditAttribution: KarenS commented

It sounds like you have some configuration problems which have nothing to do with this patch. Go to update.php and see if you need to appy an update to any of the cck modules (I'm guessing you do). After doing that you need to manually empty your cache table using phpmyadmin or some such. Then go and try to edit all your fields (not just the nodereference field) and save them to make sure they are updated. Afte that you should be able to get this patch working.

yesterday’s picture

yesterday CreditAttribution: yesterday commented

KarenS:
i tried everything to make this work, but this patch only causes strange behavior once applied. My most recent attempt involved the creation of a new drupal installation (4.7.3); fresh db and only stock modules. Installing/enabling cck (4.7.0) and views (4.7.0) was fine. At this point, the nodereference module appeared correctly in the module list and was enabled. I think copied the patch file 'nodereference.module_8.patch' to the cck directory and executed the command 'patch -b < nodereference.module_8.patch'. The nodereference module was successfully patched. Now, however, in the modules list, the nodereference module appears listed without a description value. When nodereference is then enabled, the option to make a new CCK field a nodereference is not available.

What am I missing here?

yesterday’s picture

yesterday CreditAttribution: yesterday commented

Sorry, my last comment got chopped, continuing....

[...] I then copied the patch file 'nodereference.module_8.patch' to the cck directory and executed the command patch -b < nodereference.module_8.patch. The patch completed successfully. Now in module listing, the nodereference module is shown without a description. I thought this was strange but enabled it anyway. When creating new CCK fields, the nodereference is not an option (even with it enabled).

What am I missing?

KarenS’s picture

KarenS CreditAttribution: KarenS commented

Did you empty your cache table after making this change? You will need to do that.

yched’s picture

yched CreditAttribution: yched commented

@yesterday : I was just about to ask the same thing as Karen :
Can you make sure that after enabling nodereference module, the cck cache entries are cleaned (see http://drupal.org/node/78969)
In short : edit an existing content type, or manually delete (phpMyAdmin...) the entries in the cache table, or -even bettre :-) - apply and test the patch in the thread i mentioned above.

If this does not solve your problem, maybe you could post _your_ patched nodereference.module, so that we can have a closer look ?

I'd really like to move this as RTBC, to give it a chance to get committed when JonBob is back in the area...

yesterday’s picture

yesterday CreditAttribution: yesterday commented

Thanks for your help regarding this issue. I resolved it (somehow) by editing the patch file. In my modules/cck/ directory I had both the expected nodereference.module file and yched's patchfile. Running patch -b < nodereference.module_8.patch told me that nodereference.module was patched, but then I would run into the problems I listed. I changed the patch file's expected file location line and removed the module/cck/ prefix. Then I patched, which apparently works now. I was getting strange behavior trying to apply the content_admin.inc patch that you referenced above: after applying that patch, I would get file could not be opened errors. Permissions were correct. I ended up applying that small patch by hand.

My problem with the content_views.inc foreach() warning are still persisting. I get the warning only one time on one page (whichever I pull up) after truncating the cache table. I've checked out all the things that KarenS has found as culprits and still cannot track that down. It started happening when using this nodereference.module patch, but I'm not willing to blame it entirely on the patch. I will have to do some more digging myself.

Lastly (the point relevant to this thread) and probably @yched, is that when I maee a nodereference as a select list tied to a view (which has appropriate filters, fields, and sort criteria) and tried to make a new piece of content that uses that field, the dropdown list would be populated with blank entries. Apparently the view was selecting the right nodes, but it is not displaying any of the fields that I chose as options in the control. I resolved this by changing the display type from Teaser to Table List. This seems trivial, but shouldn't this be mentioned somewhere?

yched’s picture

yched CreditAttribution: yched commented

Glad you could work it out !

I don't know if content_views.inc warnings are related to this patch - I never experienced them.
Could you be more specific about that ?

I'll look into this "teaser view" / "table view" thing - thanks for reporting that :-)

KarenS’s picture

KarenS CreditAttribution: KarenS commented

I think the warnings are from the issue at http://drupal.org/node/81284, which has nothing to do with this patch except that installing any new module sets that warning off again. There is a patch for that problem at that link.

yched’s picture

yched CreditAttribution: yched commented
FileSize
nodereference.module2.patch8.13 KB

New version of the patch
It takes care of the small issue pointed by yesterday, by (temporarily) forcing the view into a "list" type, as some other view types (the ones with 'needs_fields' = false) won't have the fields included in the query.

I think this is quite close to being RTBC now - could someone that's been using this patch put his +1 on that ?

KarenS’s picture

KarenS CreditAttribution: KarenS commented

yched, I couldn't get this latest patch to apply. The earlier patch works fine. Is the only change the addition of:

+ // make sure the fields get included in the query
+ $view->page = true;
+ $view->page_type = 'list';

If so, I will just add that and test.

yched’s picture

yched CreditAttribution: yched commented

Crap. Both patches have been generated the same way, so I don't know why one should apply and not the other. The only thing is that in the latter, the lines endings are converted to unix style (i've been advised to do so in the meantime). But maybe I'm doing something wrong anyway.

But, yes, the lines you mention are the only difference between the patches.

yesterday’s picture

yesterday CreditAttribution: yesterday commented

This patch has successfully accomplished the functionality described in this thread. Well done. Karen, thanks for your work with the content_views.inc problem, the patch worked for me. If I knew what you meant by giving this patch a +1, I'd do it.

KarenS’s picture

KarenS CreditAttribution: KarenS commented
Status: Needs review » Reviewed & tested by the community

Working fine for me, so I'm marking RTBC.

moshe weitzman’s picture

moshe weitzman CreditAttribution: moshe weitzman commented

I will dance a happy dance once this gets in ... thanks for your recent commits on the cck queue, karens.

beauregard’s picture

beauregard CreditAttribution: beauregard commented
Title: Use views as a nodereference selector » Use views as a nodereference selector / error when applying the patch

First of all, a great module! Thanks for this.
I just applied nodereference.module2.patch to the newest cck 4.7 cvs nodereference module and got these errors (using Cygwin):
Hunk #3 Failed at 182
Hund #7 Failed at 379

I shortly tested, the node-reference seems to work, so I don't know what effects these errors have

yched’s picture

yched CreditAttribution: yched commented

Yes, my patch in comment #36 is probably outdated now - Karen has done a great job committing lots of things lately.
I'm currently away from my coding environment, I'll update my patch as soon as I'm back (thursday)

yched’s picture

yched CreditAttribution: yched commented
FileSize
nodereference.module3.patch8.04 KB

Here's a re-roll against current 4.7

KarenS’s picture

KarenS CreditAttribution: KarenS commented
Status: Reviewed & tested by the community » Fixed

This seems to be working well and is obviously something lots of people want to see added to the module, so I have committed this to both cvs and 4.7. Thanks yched! This is very useful.

yched’s picture

yched CreditAttribution: yched commented
Title: Use views as a nodereference selector / error when applying the patch » Use views as a nodereference selector

Thanks Karen
(just switching the title back - probably doesn't matter now anyway...)

Egon Bianchet’s picture

Egon Bianchet CreditAttribution: Egon Bianchet commented
Status: Fixed » Needs review
FileSize
nodereference-default-views.patch.txt806 bytes

I noticed that you forgot to include default views

yched’s picture

yched CreditAttribution: yched commented
Status: Needs review » Needs work

You're perfectly right, Egon.

Yet, I think it would be better to :
- keep default views at the end of the list
- separate them in their own 'optgroup'
This would keep the interface more coherent with the admin/views page.

Egon Bianchet’s picture

Egon Bianchet CreditAttribution: Egon Bianchet commented
Status: Needs work » Needs review
FileSize
nodereference-default-views.patch_0.txt968 bytes

Good idea

yched’s picture

yched CreditAttribution: yched commented
Status: Needs review » Reviewed & tested by the community

This seems good to go. Thanks Egon

yched’s picture

yched CreditAttribution: yched commented
Title: Use views as a nodereference selector » views as noderef selector : update

just to show there's something new...

KarenS’s picture

KarenS CreditAttribution: KarenS commented
Status: Reviewed & tested by the community » Fixed

Fixed. Thanks Egon!

yched’s picture

yched CreditAttribution: yched commented
Priority: Normal » Critical
Status: Fixed » Reviewed & tested by the community
FileSize
nodereference.module_10.patch2.52 KB

Some other fixes required for the 5.0 version
- module_exist / module_exists thing (reported in http://drupal.org/node/93375)
- different behaviour of node_get_types (reported http://drupal.org/node/93372)
- change in views API : a call to views_load_cache is required to load the functions defined in views_cache.inc (I found that one by myself :-)

yched’s picture

yched CreditAttribution: yched commented
Title: views as noderef selector : update » views as noderef selector : 5.0 broken
KarenS’s picture

KarenS CreditAttribution: KarenS commented

Yes, I know that there are problems in the 5.0 version of nodereference, but as soon as we start changing it we can no longer easily apply the other nodereference patches, so my thinking was to get all the big nodereference fixes in while both versions are the same, then add in the 5.0 fixes to nodereference cvs version That is why I have been trying to push through the nodereference issues (at least the complicated changes) ASAP.

yched’s picture

yched CreditAttribution: yched commented

Allright, makes sense.
I got your request on http://drupal.org/node/62498 - I'm working on it

KarenS’s picture

KarenS CreditAttribution: KarenS commented
Status: Reviewed & tested by the community » Fixed

Committed. Thanks yched!!

KarenS’s picture

KarenS CreditAttribution: KarenS commented

Should say, I committed the patch at http://drupal.org/node/62498 which fixes this too.

Anonymous’s picture

(not verified) CreditAttribution: commented
Status: Fixed » Closed (fixed)
mshaver’s picture

mshaver CreditAttribution: mshaver commented

This is really a great addition to the nodereference fields. I'm wondering if or how it's possible to display the nodereference nodes as they are in the view. It seems like this is really a selection tool, but it would be really cool to have the display of the node fields in the node appear the same as the view.