Reverse link on node record for nodereference field

I'd like to apply this, as this feature used to exist and it is needed. However, we need to figure out the best way to not force it on users; I can see cases where this information would get in the way. Perhaps we can find a way to be able to theme it out in node-content-foo.tpl.php?

I realized that, too. I am re-writing the patch to add a widget settings option where you can elect whether or not you want to have a reverse link. Will post it later today.

The problem is, this shouldn't be set per-widget. It would be quite reasonable to have the listing show up on one content type but not another, both referenced from the same type.

I really think we should look into how a theme could suppress this list.

My concern about surpressing in the theme is that you have a lot of processing going on that isn't necessary if you don't want the reverse links. Also I like the idea of being able to add customization with themes, but we have a lot of users who don't know how to do that so I think the out-of-the-box solution should not require customization of themes, just some sort of select box to turn it on or off somewhere. I do see your point about other nodes maybe needing to handle things differently so I can see we need some sort of cross-node solution. I will do some more thinking on this.

OK, here's an attempt to address all the outstanding issues with this field. I am using this field type extensively, so hopefully, if it isn't perfect at least it isn't too badly broken. Addresses the following:

1) Creates a reverse link on the referenced node using nodeapi.

2) Adds a settings item to select which content types you want reverse links on, selected at the same time you select which content types you want to reference. The reverse link above is not show on nodes that are not in the list of 'linkable' types.

3) Addresses the issue of not being able to see the difference between nodes that have duplicate titles by providing an option to prepend one or more other fields to the title (the nid, the uid, etc.)

4) There was a function in there to produce a list of referenced links that was using one of the tables that no longer exists, so I rewrote that function to work in the new db structure.

5) Added in a blank value option in various places where fields were not required but no blank option was available.

JonBob, I'm not sure if #2 is an acceptable solution for displaying the reverse links, but think about it. The other alternative is to always display it and let people theme it out if they don't want it, as you mentioned earlier. I didn't originally like that idea, but it's so complicated trying to figure out all the kinds of options people might want that it might be the only viable solution.

Oops -- forgot to attch the patch.

i have not tried KarenS' patch, but i wonder if a good or complimentary solution would be to enable creating views of nodes using the referenced node as an argument. So we could make a view of nodes which are tagged with a particular node. Then, using 2 lines of PHP code, the view can be embedded in the node-content-whatever.tpl.php file.

a little more tinkering reqd by the implementer but more flexibility i think

That's an excellent idea. I themed the link so it could be altered, but doing something with views makes a lot of sense. There's no way of knowing if there will be one link or many. If you have a setup where you know ahead of time that there will be only one link, a simple link will look the best, but if there may or will be many links, the view would be best, so the solution probably needs both options.

I have been playing in another application with embedding views that depend on arguments, and when I get that working I will swing back around to this and try to add an option that uses the nid argument to automatically create the embedded view.

CCK is currently views-_enabled_.
Wouldn't that make it views-_dependant_ ?

I am thinking of it as an option, if views is enabled.

the missing link here is that although cck is "views-enabled" i do not see that the nodereference field is "views argumants-enabled". In other words you cannot currently make a view that selects all nodes that are nodereferenced to a particular node. Conceptually I don't this would be too tricky.

dado :
view args for CCK fields should be available now that this patch by dopry has been committed.

This includes arguments for nodereference fields - at least it works for me.

Are you sure you have the last versions of CCK and views ? There was a recent db update for views that corrected of problem with long argument names, that got truncated and thus "inactive" - and CCK field names are often quite long...

holy hoppin hesus you're rigth yched! i must have had a 5/1/06 version of cck. and i must say the process works like a champ. here's what i did

(1) i created views using nodereference arguments e.g. one view called 'events for this place',
and
(2) added this to node-content-my_type.tpl.php

I did a re-roll of the nodereference module. I tried to keep it as simple as possible while making themeing as flexible as possible, so what I ended up doing is pushing the view completely out to the theme and removing options to show or not show reverse links. You can then theme them out or change the display or whatever.

To make it easier to insert a view, I added a sub-theme function that does nothing if you don't set a views theme up and displays your view if you do. It has an example theme that you can put into your theme folder.

I left in the following changes that I had previously added:

3) Addresses the issue of not being able to see the difference between nodes that have duplicate titles by providing an option to prepend one or more other fields to the title (the nid, the uid, etc.), providing a theme you can use to control how those extra fields are displayed.

4) There was a function in the original module to produce a list of referenced links that was using a table that no longer exists, so I rewrote that function to use the new db structure.

5) Added in a blank value option in a couple places where fields were not required but no blank option was available.

I was sooo excited to find that 'nodereference' became available in Views filters after using KarenS's updated nodereference module (may 17th).

Unfortunately I found that nodes using the nodereference are not displaying the select list properly (shows : instead).
In addition, the Views Filters should allow 'Is All Of, One Of, etc.' similar to that of Node Type instead of allowing only 'Contains, etc.'.

Almost!

• Node display looks great (I just need to figure out how to theme it)
• The drop-down menu for nodereferences doesn't appear to include the title at all. I selected "nid" for "prepend to title" and all I see is "1 (nid: 1)", "4 (nid: 4)". If I select the blank entry for "prepend to title" all I see is "(: )" - the title doesn't appear to show at all.

Re: the filter options. Unfortunately, the only thing you can filter on right now is the number in the node reference field. You won't see a list of node names, nor have the ability to filter by 'one of' 'none of' and selecting a list.

Two reasons for this. One is that cck doesn't currently support a way to add in a filter handlers and lists, only filter operators. That could be fixed with a patch.

Second, the list could be quite long, maybe unmanageably long, so I don't know if it would be useful.

However, what would be useful would be to be able to do some 'LIKE', 'NOT LIKE' filtering on the nodereference title. That would take both a patch to the content module to add additional filter handlers and lists and some thinking about how to write a handler that would make the necessary substitutions so you are filtering by the title instead of the nid.

Anyway, I agree those would be better but the = != seemed like the best ones for now considering you only have the nid to work with. I agree this is not as nice as it should be, but it's a place to start.

The : issue is something I broke at the last minute when I tried to theme the append function. I'll find the fix and get it posted soon.

KarenS wrote :

cck doesn't currently support a way to add in a filter handlers and lists, only filter operators. That could be fixed with a patch.

I have posted some time ago a patch for CCK enabling the "advanced" view-filters options. It's there, and It happens to lack reviewers ;-)

It might need a re-roll, though. I'll do that quickly.

Sorry I missed that. I just posted a feature request for that, too. I'll test it when you re-roll it.

Re-rolled.

In fact you didn't miss it, you even left a comment there - that I did miss, I saw it only a few secs ago (I guess my spam filter needs some fine-tuning...)

In regards to the debate about whether or not the referred-to node should be loading the nids of the referrer node (item 2 in comment #5 above), I was thinking perhaps we can instead ask whether those referred-to node-types should load the referring nodes into the array from function nodereference_referenced_by_list() (perhaps a checkbox or something that asks whether the link should be 'bidirectional' or something). This way, we don't load the referrers for referees where its not needed, and the decision about how the refererrs should be displayed when doing a node view for a referee could be decided at the theme level...

We do something similar to this in the location module where we give the site admin the option of turning of the default themeing for a location, but where the location is still loaded, allowing the themer to have more control over where and how the location is displayed on a node view.

Here is a re-rolled patch that fixes the title append problem. I am holding off on other changes pending the outcome of the proposed patch to update the way that the content module handles filters.

Ankur, I finally ended up not loading the referenced ids anywhere but in the theme. I had played around with giving the user a play to select whether or not they want to see them, but as JonBob had pointed out, we have the potential for several different fields in several different content types that might be referencing several different content types and it gets nearly impossible to offer a selection option that covers all cases. You don't need that info loaded if you're using a views display (because views will load it) or if you don't want to see the referenced links, so I just put the function to load them into the view where it only gets called if you are trying to view reverse links. At least that was my intent. I may not have done it the best way.

Oops, it would help if I uploaded the right patch :-)

Because I neglected to properly search the existing issues :-), I just solved the same problem but with a quite different approach. I created a new field type 'nodereferencedby' which lists all the referrers of the node.

Of course, because this is a CCK field type, it means that only CCK nodes can show their referrers.

Here's the crude first version of this module. I'm curious to know what you folks think of it.

Unfortunately, your query won't work in all cases. The data is not always in a field called node_data_[field_name] It depends on whether the field has been defined as one with multiple values and whether the field is shared between content types. Sometimes the field data resides in the node_content_[content-type] file. Plus, there is no guarantee that the database structure might not change when you change your field settings or with future cck updates. You have use the content_database_info($field) function to find out where the data is stored.

You also used a private function to get the field info which may or may not work in php5 (which is more stringent about private functions than php4). I'm not using php5, so I don't know if that is actually a problem or not. Your query is much simpler than mine, so I was hoping you had found a less complicated way of doing a lookup, but in this case it won't work :-)

I am not sure there is a need for a separate module since this functionality is supposed to be added back into the nodereference module at some point, but I hope that doesn't sound discouraging. It's good to see people getting familiar with cck. It's going to be a great tool!

Karen,

This patch seems a nice addition to the nodereference thing.

A few remarks though : (based on the last version)

• somewhere in your code there is this line :
  
  $ids = db_query("SELECT nref.vid, n.* FROM {". $db_info['table'] ."} nref INNER JOIN {node} n ON nref.vid = n.nid WHERE ". $db_info['columns']['nid']['column'] ."=". $nid);
  
  I'm puzzled by the
  ON nref.vid = n.nid</code part :
My first impression is that It doesn't seem right to join nids and vids.
(yet that might be just me not going deep enough in your code logic...)
</li>
<li>
<code>function theme_nodereference_reverse_links($node, $op, $teaser, $page) {
  
  Isn't the $op param pointless ?
• It seems the 'view reverse links' part triggers sql errors when you ask a _preview_ on the node's _creation_ form
  You have an error in your SQL syntax (...)  near '' at line 1 query: SELECT nref.vid, n.* FROM node_content_evenement nref INNER JOIN node n ON nref.vid = n.nid WHERE field_lib_edi_ref_nid=
  I guess when you preview a not-yet-created node, some attributes are not set yet...

Sorry, a typo got my first point truncated.
Here it is :

somewhere in your code there is this line :

I'll take a look at this, but can't do it until tomorrow. The reason for linking the vid had to do with linking multiple value fields, which is when the nid and the vid are different, but it may be that my thinking was wrong. I'll take a closer look tomorrow.

Karen, thanks for your comments (#25). I'm not discouraged at all. ;-)

Nobody pointed out a really fundamental flaw to #24, so here is an improved patch, this time integrated with nodereference.module, and using content_database_info() to discover the database structure.

Regarding the use of a "private" function, I'm assuming you are referring to the call to _content_fields(). In fact, nodereference.module was already calling that function, which is why I thought it was fine to use it. I don't think PHP5 will have a problem with it, because apparently this function is "private" only by convention (with its '_' prefix). Of course, the fact that we can call it does not mean that we should... ;-)

Another comment on the patch :
I'm not sure about the message on (any) node deletion :
"Linked nodereference fields have been reset."

Maybe this should be kept internal ?
I guess I don't want my users to be bugged about bizarre things such as "nodereference fields"...

David,

I tried your patch out and found one other error that needs a fix -- in the function node_referenced_by_list you are ordering by delta but there is no column with that name (that's another leftover item from the old database structure).

I'm not really happy with my attempt to append data to titles, so I'm ready to drop that part of the code for now (unless someone comes up with a better way to do it.) The only other important thing that is not in your patch is that I tried to do some error checking to clean up things if the related node was deleted (producing the error code that yched mentioned.) Again, I'm not sure my approach was the best, but I think the general idea (watching for a node delete and trying to clean things up) would be useful. If that makes sense, you can work something like that into your patch.

With those changes (at least with the error correction), I'd be fine with using your patch.

Karen & David : I'm not sure I'm getting what's going on in this thread between the two of you (well at least between your patches :-)

Karen, are you saying you're considering dropping your patch in favor of David's ?

(No personnal opinion here.
I've applied Karen's patch and sort of used it, while I've only quickly looked at David's code.
I just wish not to loose track. Two patches is a thread is not that easy to follow...)

I was getting confused, too, so, yes I am saying I will just drop my patch so there is only one.

I posted a patch in this thread only to avoid creating a duplicate issue, but yes, it unfortunately makes things harder to follow... Sorry for that! I certainly did not mean to impose my patch over anyone's, but merely throwing additional ideas.

My patch does not attempt to do anything more than showing a node's referrers in the same format as the node references (which means showing titles only). It makes the thing very simple, not as powerful as Karen's attempt.

Also, this patch does not store any additional data; it merely uses the existing 'nodereference' data, so I don't think anything special needs to be done for the new 'nodereferencedby' fields upon node deletion. On the other hand, the fact that no data is stored makes me wonder if it is appropriate at all to create a field type, considering that it is actually "read-only". Is it appropriate to create a "read-only" field type only to benefit from CCK's field positionning and labelling? I did not find a better option, so tomorrow I'll probably try to improve my patch a bit more (at least fix the error that Karen reported in #31).

I have been working with David's patch and the more I work with it the more I think his handling of the referencedby nodes is preferable to the one I had taken. It seems to be working well (with the exception I reported already) and I think I like the option of adding the referencedby list as a field that you can use or not use on the node as he has laid it out. (And yes I think it is a valid field type.)

We may want to return more data than the nid and title, but it is becoming apparent that embedded views are a better way to handle more than a simple link list, and the field doesn't need to return any data when using views since views will handle its own queries. So I guess my feeling now is that the nid and title are sufficient for most situations.

His approach and mine are so different that it would be hard to actually blend them together, so that's why I think its time to settle on one and get it committed. Then we can build on it to add other functionality.

Here is an updated patch. I did more testing and did not see any problem.

+1 for the patch.

I tried it out in a situation where I was using a CCK node type with another CCK node-type with event module fields (which are added via nodeapi). I was having the second CCK node-type doing nodereferences to the first CCK node-type and tried to use views to display the referrers in a table with some event fields in some of the columns. Some of those columns were blank, but I think that may be a matter of 'views-enabling' the event nodeapi fields.

I think the patch still needs work. I tried to theme individual "nodereferencedby" fields to no avail. The problem is that hook_field_view_item() is not properly implemented for that field.

I also do not like the name ("nodereferencedby"). It's confusing. Maybe it should be renamed to "referrers". I'm very open to suggestions. English is not my mother tongue and perhaps I'm missing some obvious, more adequate word. ;-)

Personally, I think nodereferencedby is a good name that is clearly the counterpart to nodereference.

On the field not showing up, I think the missing element is that you need to define a column for nodereferencedby so it has a place in the data structure. The field shows up as a field instance, but has no 'value' anywhere. I would assume we would not actually store anything in the column, but instead update it dynamically.

Here's a new patch. The hook_field_view_item() is now properly implemented. I had to add a 'nid' column for the nodereferrers field type so the hook knows which node wants to know its referrers. That column is redundant in the database, but I found no better way to pass this nid to the hook.

Karen, I had already renamed 'nodereferencedby' to 'nodereferrers' before your reply. :-/ But this is now more consistent than the previous patch, which was using 'nodereferencedby' as the field type, but 'referrers' on some labels.

BTW, maybe I should not mix things up, but this patch also includes the nodereference theme function and adds some t() around labels to allow translation.

@KarenS
I was playing around with the wonderful backlink 'referrers' patch to nodereference.module,
but I messed things up.

If I now take the acutal cvs version of nodereference.module and apply patch5 I am ending up with
Call to undefined function: _content_fields()

Could you please send here an attachment in with the compelte nodereference.module that you are currently using?

Also a complete tar.gz of your cck folder would be VERY INTERESTING to play with it (as I like to test so much)
Thank you

OK, I figured out my path to happiness for CCK in the meantime.

PATH FOR CCK Version 4.7.0
1. Download and unpack CCK Version 4.7.0
2. Take the above patch5 and apply it to nodereference.module to get it working
3. delete modules/cck/date.module and date.install and get the KarenS version of the date module
4. download and install jscalender (CVS Version)

PATH FOR CCK Version CVS
Same for 1. to 4., but strangely thefunction _content_fields ismissing in the CVS Version of CCK.
So I take theonefrom the 4.7.0 Version of CCK and appenditsimplytothe endofcontent.module.

Now I have my two things that I want running:
A. backlinks from referrers (I use the above patch5 to nodereference.module)
Then I can display them in a block
http://drupal.org/node/70764
which is quite handy for me and my users.
B. The date field with jscalendar widget.

Now I have only two minor issues open:

X- jscalendar image icon does not show up in Internet Explorer (even after someone played with the .css and .js)

Y- If you have a jscalendar date field - and a autocomplete nodereference field in the same content type. Then if you edit such a node and type your autocomplete - you move with cursordown in the AJAX result list and selectyour candidate - BUT at the moment you press the [Enter] Button, the jscalendar pops up. (quite funny)

... but the javascript stuff has not that kind of priority

I was very glad to see that others had the need for this function.

Through a great deal of frustration I learned about how to patch files on Windows. Having completed that task, I ran into this error as I was editing the node that would be the referee. I got the same error while trying to create the same type of node. It now appears whenever I am viewing this type of node.

I have the cvs version of cck, with the additon of the lost function_content_fields as noted by easytouch.

I found this other thread about the renaming of the function _content_fields to content_fields.

See http://drupal.org/node/71184

Once I changed that, the patch works great.

+1 on committing this patch!

Will this patch work on the 4.7 version and is this a duplicate of http://drupal.org/node/60271 ? It is a huge patch to try to do manually.

Also will the cvs version work with Drupal 4.7?

Re-rolled David's patch from #40 with _content_fields replaced by content_fields.

This patch applies fine to the cvs and 4.7 versions of this module. And, yes, the cvs version of cck works fine with Drupal 4.7.

Disclaimer: I haven't tested the functionality of the patch, only that it applies.

New patch doesn't seem to work, at least using windows.

I tried it as is and got a warning that there was extra text. Trimmed the extra text and I get:

I am using patch -p0 --verbose  < %1.

Before I waste any more time on this, I assume this is to fix all of the database errors with node reference, as reported in http://drupal.org/node/60271 in which case why is this called a feature request and not a critical bug?

@lekei: Are you sure you're using the latest version (either 4.7 or cvs branch)? I just applied it to a fresh checkout of the 4.7 version with no errors using the same patch -p0 --verbose command.

And no, I don't think has anything to do with trying to fix http://drupal.org/node/60271. As the title says, it's about a new reverse links feature. But I better shut up since I haven't tested it. I just re-rolled the patch to fix the content_fields name change issue.

The notes for http://drupal.org/node/64743 (which appears to be a duplicate) indicate that this patch magically fixes the problem.

Since there seems to be no way to select an image in CCK without putting the image in a node and selecting the node, nodereference not working is a total show stopper for me.

I am using the last release of 4.7 (6/12/2006). It is always current since I use a script that automatically syncs all modules I have in use with ftp.osuosl.org (I intend to share the script but this bug has me so far behind schedule).

Sorry, by the fact that you added .txt I assumed that you were using Windows. Obviously you are using *nix since changing the command to patch -p0 --binary --verbose  < %1 makes the patch apply.

Unfortunately, this does not fix the bug in nodereference... still produces 3 errors on prevue. I will need to redo the project using non drupal (pure php) tonight.

I tested RayZ's patch (#46). It patched and worked fine here with the latest cvs. Thanks RayZ for the update.

Re: the preview problems, I think that is a content module problem since preview problems are being experienced in virtually every field type, so I don't think this thread is going to be able to address that.

There are now several threads proposing several completely different and incompatible approaches to the nodereference module development. I use nodereference extensively and I really don't want to end up using something that is completely different than the final version, so it would be nice to gather up all these threads and agree on an 'official' approach for the module. The approach in this thread is the one I prefer and I am currently using. I can maybe be convinced to go a different route, but I think the key point is that we need to close all of these threads but one and focus our efforts in a single direction.

If we can agree on a single patch/direction for this module, I would like to add to it some enhanced views capabilities -- to be able to sort and filter by the referenced node title instead of the nid, for instance, which I think is vital. I am also thinking about a way to embed a views view to do the node selection, which will help solve the problems with duplicate titles, create a way to limit the nodes available for selection, etc. Based on some work I have been doing with other views modules, I think I can create some custom views handling for nodereference without making changes to the content module (or at least with minimal changes), but I don't want to invest time doing that without some assurance that I am working on the 'right' version.

Maybe it's time for nodereference to become a separate project, as a couple other modules have done. What does everyone else think? If there is agreement on that, is anyone interested in setting it up and maintaining it?

Thanks KarenS, I proved that the problem is fundemental to CCK - ALL drop-down boxes don't work.

I have solved the problem by writing a module. It turns out that writing a module is far, far, simpler than using CCK or Flexinode with no way to work around the bugs.

It had to happen eventually, but I have always resisted writing a module for Drupal because of the core Drupal phylosophy that all modules are obsolete before you even start, since they (the core developers) even now have already abandoned all of us who use 4.7 and are working on a new and incompatible 4.8.

manually applied David's patch rerolled by RayZ at #46, and everything seems to work fine (CCK, Views, outputs, contemplate..).

Can i ask a thing:
now in Views Arguments we can also make use of "Node referrers" other than "Node reference".

Would it be possible to use these also as Filters, so to filter nodes that are referred by a particular node or nodes?

thx

A quick clarification regarding David's comment on this patch allowing for the same Theme Functions as the patch for themeing nodereferences: Would this then allow you to display any fields of a referenced node as you want providing complete reverse nodereference functionality?

Thanks for the answer. My appologies if this feels like an out of place question.

Here is an interim patch against cck-4.7 with a few changes since not all of us are using views to display output...

1. added a referrer_types option to the nodereferrers_list field type... So we can merrily select which field type to back reference per referrers list.
2. get the referrer nodes on hook_field(op==load)
3. probably completely broke whatever you were doing with views...

if people like this approach I'll go ahead and fix the views integration to use the data from load, and add do the node_load thing if people really think they need the full node, and not just the base data.

I guess I could actually attach the patch, eh?

Thanks dopry, I was just sitting down to add the referring-field-selection functionality.

I like the approach to reverse references taken by this patch, and with the ability to filter displayed refs to just one referring field, it goes a long way towards making node-refs semantically complete.

Testing the patch out right now. I will try to test the views stuff too, but it's not my forte.

Dopry, I see that your patch adds the ability to filter by content type, rather than by refering field. I think that filtering by refering field would be more useful as well as more semantically correct. There are two main use-cases for reverse links:

1. To display a global list of "referenced by" backlinks, as a navigational aid. This is the behavior provided by David's patch.

A bit elegant I think, right? I don't see a use-case for filtering by type which couldn't be done using field-level-filtering.

I'll take a whack at a version of David's patch which implements this type of filtering.

BTW, I'm leaning towards radio buttons rather than checkboxen for the refering field selection:

• [all]

I intednded to do referring fields next ++ content types.. I just didn't want to invest in the selection logic just yet. The big changes from davids patch was how load was handled...

Mulitple content types can share the same referring field.. So I want to display a list of referrers using the parent field and I only want stories... Does that cover your use case? We need both for a feature complete ui... Or some very intelligent views integration.....

You're right, dopry, you can't filter by type if there's no UI for it. But CCK is a storage layer. I think the need is for semantic reverse relations, with a simple UI. The "everything that references me in one field" capability is secondary, as it could easily be provided by a decorator. More complex filtering is trivial with something like views. Also, I think it would be useful to have the option to make these reverse relations bidirectional (editable on either end). I'd like to get that into this patch if possible, but it's difficult to see how that could work alongside type filtering.

I've been reviewing. I'll hold off on making a new patch if you're working on an updated version.

Eric

By all means go for it. We can play patch pong.

bump .... so I can track this easier.

Although there seems to be an approach in http://drupal.org/node/70764, I'd like to see a function for creating reverse link nodereference blocks. Drupal blocks already provide full control over block display and we could implement an option to filter reverse links by content type.

This would be a similar way how relationship module manages relationship links blocks.

just my 2 cents

Patch does not apply anymore. Neither against 4.7.0 nor CVS.

Man! This was a birth...

Attached patch applies against current CCK 4.7.0, is based on dopry's patch in #57 and fixes some hard-to-track-down bugs which came in through new revision of CCK. Additionally, I've implemented cache cleaning of referred nodes, which wasn't handled yet.

Although this looks good and I will implement this in one of our projects, I do not recommend comitting this. Reason: This code is very hard to maintain and from a lower view we are dealing with a new nodereferrers module for CCK here. Although it depends on nodereference module I would recommend to separate it into a new module. If I would have already dived deeper into CCK, I would have done this job, but for now this is too deep for me.

I'm also currently unsure if I'd rather vote for edrex' semantically way in #59.

Sun, ytmnd!

I would be completely happy seeing this functionality as its own field module. I'll try to strip it out at the end of next week and do just that. I like it as its own field type becuase it makes it optional, and exposes the ability to have a configuration for it. Code style looks ok, the queries at the end are strangely formatted. If your gonna put all the clauses on their own line, why not do the WHERE clause as well....

.darrel.

It seems you didn't build your patch upon last 4.7 cvs code (even though you built your patch against it) : you remove the recently added hook_field_formatter, and reintroduce the deprecated hook_field_view_item.

@dopry: Sorry, this was a fault due to my late night action. Benefit of this (fixed) notation: Only now I was able to see the duplicate code at this point.

@yched: That wasn't my intention. After I completed the patch I made a test if those functions were used, but they were not and so I removed them. I'm sorry I have to blame, but this is a result of missing documentation in cck modules. Neither in content.module nor in nodereference.module is clearly stated which functions will be invoked. Regarding current developments, even more important would be notices for functions being removed or replaced in upcoming versions. This is really messing and hard to understand. I'm already aware that this patch won't apply against current HEAD.

Fixed a critical syntax error of the last patch.

I've tried the patch with 4.7 and it wouldn't work. i was able to chose the referenced nodes but there were no backlinks created.

@killes: Did you set up a node refferer field in the referenced node and permit the display of referrers of the referring node's content type? Damn. We should definitely rename one of both field types. [=> "Did you set up a backlink field in the referenced node and permit the display of backlinks of the referring node's content types?"]

This patch works for me with 4.7, the backlinks didn't show up until I cleared the cache.

Ok, I didn't know that I had to add a new field. :p

Well, looks good though. I'd like to add that there is another patch you might be interested in which allows to completely attach referenced nodes into your cck content type. It's often not enough to display a list item only. Needed this feature in combination with this issue here for a current project.

subscribing ... would be nice to finally get this in

Needs work, again. Sorry to spoil the fun! ;-)

I fixed the cache problem described in #74, so now adding a reference to node B from node A causes B to update its view (and thus show A in its referrers).

But a problem remains: When removing a reference to node B from node A, node B still keeps node A in its referrers because B's view is cached. We can't clear B's cache when saving A, because at that point A no longer knows about B... An option might be to clear all 'content:' cache entries, but that seems extreme. I don't have any better idea right now.

Thanks for the update and hint, David. Will have a look shortly.

Clearing the cache of all contents doesn't look like a well solution. But maybe rather clearing the cache of all nodes that have a node referrer field.

I'd like to inform you that I'm in the need of using this functionality in a current project which will be launched in the next days. So there will be live testing on any patches flying in - hooray! ;) For now (no nodes have been deleted yet :) it looks very well.

I am using versions 4.7 of Drupal and CCK, along with the latest nodereferrer patch. The following error message only happens after I update a node with nodereferrers:

Warning: array_values() [function.array-values]: The argument should be an array in /webdocs/test/public_html/modules/contributed/cck/nodereference.module on line 121

This happens inside function nodereference_field($op, &$node, $field, &$node_field, $teaser, $page), under

It disappears after I refresh the page. ???

A ['view'] for nodereference is provided like so:

$field_nodereference[0]['view']

A ['view'] for nodereferrer does not exist. I think it's a problem you have to do the following to create a link :

Please don't change the title :-)

Oh, sorry. I didn't realize it changed the title up top! :-/

I think the whole approach of nodereferences is a no-go. As mentioned on groups.drupal.org we should rely on a small subset of Relationship module in short term, which could be extended to allow full featured relationships in long term. Current nodereference concept won't respect publishing states of referenced and referred nodes, too. See also this for even more discussion about integrity.

Anyhow, for those who can't wait and can live with those present features, here's the current version of nodereference module. It also includes a slight change regarding available nodereference and backlink variables at node view time, so referenced nodes and referred nodes are loaded completely as full-featured objects and not trimmed down to their node ids. That shouldn't have any effects on performance, since those nodes are loaded anyway.

Keep in mind: This module displays content depending on Drupal's cache and therefore

• disrespects publishing states of referenced nodes and referrers
• disrespects access permissions on referenced nodes and referrers and finally
• is not aware of deleted referrers, as long as cache isn't cleared manually.

Like Karen, I'm using this module already. So it could be that there will be a chance for a module upgrade later on. But don't expect this to happen.

hmpf, forgot the patch.
(proposing a "will add a patch later" checkbox for issue form...)

This patch fails for me on the Web server and in Mac's Terminal. Anyone else experiencing this?

Is the caching fixed in this latest release? I'm getting a problem where I submit node 'a', then create node 'b' which references node 'a'. But for the backlink to show on node 'a' I have to edit and resave it. Is this normal behaviour or should this work without resaving?

@robomalo: Don't know why. I verified that latest patch still applies. Anyhow, here's my latest version of this module.

@sun you may need to make a patch diff from an updated nodereference.module as I just tried to apply this patch and there were a couple malformed parts that I had to apply manually.

update version of #85...

Thanks for working on this, but my patched failed using the October 28th version of the CCK.

Hunk #4 FAILED at 61.
Hunk #12 FAILED at 418.
2 out of 12 hunks FAILED -- saving rejects to file nodereference.module.rej

My patch also fails with the latest version of nodereference.module.

Hunk #1 FAILED at 23.
Hunk #2 FAILED at 40.
Hunk #3 FAILED at 49.
Hunk #4 FAILED at 61.
Hunk #5 FAILED at 162.
Hunk #6 FAILED at 177.
Hunk #7 FAILED at 191.
Hunk #8 FAILED at 242.
Hunk #9 FAILED at 365.
Hunk #10 FAILED at 381.
Hunk #11 FAILED at 389.
Hunk #12 FAILED at 418.
12 out of 12 hunks FAILED -- saving rejects to file nodereference.module.rej

sun: tryed your module at #88 with latest CCK 4.7 version (v 1.56.2.23 ), and it throws the following warnings:

* warning: array_values() [function.array-values]: The argument should be an array in /public_html/drupal/modules/cck/nodereference.module on line 126.
* user warning: Table 'myusername_mydatabase.node_' doesn't exist query: nodereference_get_referrers SELECT n.nid, n.vid, n.title FROM node_ nr INNER JOIN node n ON n.vid = nr.vid AND n.status = 1 WHERE nr.field_ad_reference_nid = 518 ORDER BY n.created DESC in /public_html/drupal/includes/database.mysql.inc on line 120.

sticking with patch rerolled by RayZ at #46 not throwing any errors for the moment.

I am looking through this thread with a little bewilderment.

This looks like a worthy patch that people are already using on live sites, despite some stated shortcomings. Yet I have no idea of the right way to apply it to latest 4.7 CCK that I am using.

Could this finally get commited? If not, where do I start?

This patch needs to be re-rolled since there have been a number of recent changes to the nodereference module. I have been pushing through various nodereference patches to get them committed and this is one I would like to see added, but the patch is out of date now. Can someone re-roll it and confirm that everything works properly in latest version? We will need a patch for both the 4.7 and cvs versions, since they have diverged.

I did not actively follow this issue and all the work that was put into this by so many people in so many approaches. It is not my intention to delay the inclusion of the feature with additional debate.
So I'm sorry to come up with another suggestion :-)

I wonder if mfredrickson's recent viewfield module doesn't allow for a better approach : the nodereferrer field we're talking about is just an instance of a viewfield, using the right view with the right filter. Noderefence module could even provide a pre-defined, customizable view for each nodereference field, to save the user the bother.

Pros :
- provides more flexibility for the output (other fields than the title...), without the need to code a theme function
- does not clutter nodereference module - lets not add code and duplicate functionality if a more powerful feature exists somewhere else
- Views is magic, Views is the future (tm), I think it should be used it whenever there's no good reason not to...

Cons :
- obviously, makes the feature require Views module (and viewfield...)
- probably a tad bit less user-friendly
- maybe there are features in the current state of the patch that I'm overlooking, and that this approach would not allow ?

I am happy to help test this, if someone knows how to re-roll the patch or better give me ready-patched nodereference.module file. As I need this feature now, rest assured I will exercise all the functionality.

Not as sure about yched' suggestion... Even if it has advantages it will take a long time to implement and fully test. On the other hand the patch that we have here has been scrutinized quite a bit and is used by some people already.

I think we need at least a simple reverse link capability that doesn't use views. Among other things, if you have only a one-to-one relationship and all you want is to see the title of the referenced node, using Views seems like overkill.

There is a big discussion going on in groups about the best way to handle references, ordinality, etc, and this module doesn't begin to do all the things a complete node relationship solution would do, but there clearly is still a need for a simple way to link nodes together, which this module does. I think we should leave that kind of heavy lifting to another add-on module designed for that purpose, or use the viewsfield module for one to many or many to many links, and keep the core nodereference module fairly simple.

At the same time, we need to get something committed (after all this time) and there are people already using this approach (although I don't know how many). So maybe we need to get this re-rolled, examine it to make sure we are keeping it as light as possible, assuming that more complex functionality will come with the viewsfield or a yet-to-be determined relationship module, and then we can get that committed.

How does that sound?

Exactly, views is overkill. All I want to do is pull up a node, get NIDs of CCK referrers and traverse them any way I want.

Please, please, please - help re-roll this patch and I will test it speedily and thorougly to get it ready for commit.

To take a better decision maybe you want look at some Viewfield features described by mfredrickson.