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?

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.

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

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

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

$view = views_get_view('events for this place');
print views_build_view('block', $view, array(0=>$node->nid), true, $view->nodes_per_page);

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.

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.

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.

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.

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 :

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

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

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

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

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.

    * warning: Invalid argument supplied for foreach() in W:\www\modules\cck\nodereference.module on line 305.
    * warning: Invalid argument supplied for foreach() in W:\www\modules\cck\nodereference.module on line 305.

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:

Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -u -F^f -r1.28 nodereference.module
|--- nodereference.module       12 Jun 2006 19:36:54 -0000      1.28
|+++ nodereference.module       4 Jul 2006 23:15:53 -0000
--------------------------
Patching file nodereference.module using Plan A...
Hunk #1 succeeded at 23.
Hmm...missing header for unified diff at line 30 of patch
  The next patch looks like a unified diff to me...
can't find file to patch at input line 30
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|unction nodereference_menu($may_cache)
|  */
| function nodereference_field_info() {
|   return array(
|-    'nodereference' => array('label' => 'Node Reference'),
|+    'nodereference' => array('label' => t('Node Reference')),
|+    'nodereferrers' => array('label' => t('Node Referrers')),
|   );
| }
|
--------------------------
File to patch:

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.

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.
2. To define a reverse relationship to an existing node-ref field:
   • Respecting the semantic equivalence of node-type-instances of the referring field. For example, if the refering field is "parent" and the refered_by field is "children", all nodes which reference a node via the "parent" field should show up in its "children" list.
   • Itself equivalent across content types. The cck fields are of course intrinsically reusable.

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]
• Field 1
• . . .
• Field n

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.

/**
- * Implementation of hook_field_formatter().
+ * Implementation of hook_field_view_item().
  */
-function nodereference_field_formatter($field, $item, $formatter, $node) {
(...)
+function nodereference_field_view_item($field, $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

case 'nodereferrers/load':
  $types = array_values($field['referrer_types']);

.

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 :

<?php print l($field_refererrer[0]['title'], 'node/'. $field_refererrer[0]['nid']); ?>

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?

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.

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.

Looks unnecessarily complex for the immediate task at hand.

Allright, fine by me.

A few remarks on the last version of the patch, though :
It does not use the standard *_formatter hook for display
A call to db_rewrite_sql is probably necessary in order to account for node access rights

I have the time to test. Promptly and really pushing the limits I might add.

But I am just not that proficient with CCK internals and issues of this thread to take lead on updating the patch itself.

Alright, I really need this fix, so I tried to re-roll the latest patch (dopry's #90) and got this:

patching file nodereference.module
Hunk #4 FAILED at 61.
Hunk #5 succeeded at 190 (offset 28 lines).
Hunk #6 FAILED at 205.
Hunk #8 FAILED at 242.
Hunk #9 FAILED at 365.
Hunk #10 succeeded at 495 (offset 114 lines).
Hunk #11 succeeded at 389 with fuzz 1.
Hunk #12 succeeded at 562 (offset 144 lines).
4 out of 12 hunks FAILED -- saving rejects to file nodereference.module.rej

Next, I looked at each of the hunks to see why they failed. Wherever the replacement was clear I did it by hand. Wherever there was some mis-matching code, I commented out the 'good' code from CVS as well as "-" statements from the patch.

Here are the functions/cases that need to be further reviewed and merged:

nodereference_field_formatter
nodereference_widget
    case; 'nodereference_select/prepare form values'
    case 'nodereference_autocomplete/validate':
    case 'nodereference_autocomplete/process form values':

I attached this semi-patched file and would greatly appreciate if you could review the remaining differences and sync it with all the latest changes. I do not understand this code enough to fix it myself.

KarenS and yched, could you please help?

Marking critical, since this problem is the easiest to resolve now before more changes to nodereference take place.

Let's get it fixed, tested and commited before making any more changes to nodereference.

I don't think critical should be used for this reasons.

bi-direction linking is automatic if you create the link and nodes with my cck subform module

http://subform.googlecode.com/svn/trunk/subform_trunk.zip

just a heads up.. I'm working on a DRUPAL-4-7 nodereferrers.module this weekend... I'm adding the necessary db_rewrite_sql's, content_formatter support, and support to select both referring nodetypes and referring fields for the referrers list. I have all of the original stuff from the first back reference patch done so far.

Will this require any further patching to existing nodereference module?

Look forward to checking out nodereferrers as soon as possible!

@dopry: Given that a few more weekends have passed than originally announced, would it be possible to post your reworked module in its current state here? As in, for the bleeding-edge people who need to have it now and can save stability and feature-completeness for later? Please? Thanks!

sry... its living at http://cvs.drupal.org/viewcvs/drupal/contributions/sandbox/dopry/noderef...
until I get more time to work on it again...

@karen, yched, jonbob: an feelings about pushing this to cck. The last part that remains, besides a thorough debugging, is the nodeapi code to keep the references sane.

Anyone getting the following error using the nodereferrer.module provided above?

Parse error: syntax error, unexpected $end in /yourpath/nodereferrer.module on line 202

Is this because I am using 4.7 instead of CVS?

Is this because I am using 4.7 instead of CVS?

No, this is because there is a brace missing in the last function of the file (the switch statement isn't closed). But even if this is fixed, the links are not shown on the resulting page, at least in my 4.7 setup. Anyways, we can't expect the module to work because it's not finished yet, just give it more time. (For my site, I customized the previously mentioned nodereferencedby module until dopry's nodereferrer is done. Which works for the time being.)

This is slated to become part of the CCK, right? Any idea of a possible timeline? Feburary? June? 2007?

thanks,

Jeremy

A few more questions / issues...

What about for those of us who have CCK in production? Would this new module display the referrers created in the past? If not "out-of-the-box" how could it be possible to effect the conversion?

Then finally, what about referrers to non-CCK nodes??? How could those be handled?

The problem with having a separate module for this is that it's not a seemless integration. It's a totally different field, you can't even dream of sorting it together with the referrers

I'm going to start working on reintegrating the stuff I did with nodereferrers with nodereference. I decided they are too closely related to live in separate modules. chx is also working on making a table for the back references instead of querying the node references. It should save us some jumping through hoops to assemble the data. We are also considering taking control of the data layer for this module away from CCK. When you update a node with a node_reference field, you can't easily update a referrer field on another no so far as I can tell...

chx & dopry: It could be nice to consider Eaton's proposed relationship API as the back-end for this. Other modules could also build on such API.

My vote is not to wait on any new APIs that can take forever and instead just get it done.

Working on a project that entails implementing a moderately sophisticated data model in CCK I see this functionality as nothing less than a must-have. We can make it more extensible later, perhaps for 5.x

Another thing I want to figure out is how to get node referrers for non-CCK nodes. E.g. a "blog entry". Could this be possible with the solutions discussed on this thread?

dkruglyak, the relationship API provides the basis for linking any node type, CCK and non-CCK. ;-) Also, Eaton has provided code, so if we want it the API is already there, and we can build on it instead of building something from scratch.

Attached is my module to help in this effort but it lacks real CCK powah -- it's done for a custom site. I am pretty sure though that dopry will be able to reuse it by assigning better values to the table/field/key variables. And probably iterate.

I figured out a way around using nodeapi by remerging my nodereferrer field with nodereference.module. This way we have access to most of the data we need in hook_field...

The attached patch is a continuation of my earlier patch series that introduced the nodereferrer field. The node referrer has been update to select on both node type and field instance. Cache clearing works on nodereference and node referrer fields. Give it a spin.. its probably got some bugs. This patch was generated from DRUPAL-5. If we can get it happy for DRUPAL-5 I'll backport to DRUPAL-4-7

oh yeah status.

Can we stick to the term 'backlink' or 'backreference' field? One of the most confusing thing while working in the code of this module was to distinguish between the almost identical terms 'nodereference' and 'nodereferrer'.

A related (but not the same) issue is http://drupal.org/node/120408

subscribing"

subscribing

subscribing

subscribing

Haven't read now the whole thread, but I think such a backreference should be realized by means of a node-relationship module. 'nodefamily' and 'relativity' are two such, I already have a more or less working patch for nodereference using the former.

what's going on with this? what do we run dopry's patch against>?

subscribing

Happy birthday node 60756, you're now one year old! :)

I think the fundamental issue that's blocking anything happening here and blocking any commits is that relationships are complicated. And not just personal relationships with your colleagues, gf/bf/spouse, boss or friends. Relationships in information architecture are also complicated. There are so many different uses, applications, approaches, that all require so many different relationship types, ordinalities, display formats, places to define those relationships. Etc...

I think that part of the problem that has made this particular thread lose direction, has to do with not separating parts of this whole solution in to simpler bits. Looking at this objectively, as a new-comer to the thread and issue, I can see three main areas where developers and drupal users want options in inter-node relations;

• The relationship

  • What are the criteria that define the set of nodes that can be on the LHS of this relationship? (e.g. node type, view, taxonomy term...)
  • What are the criteria that define the set of nodes that can be on the RHS of this relationship? (examples as above)
  • Do LHS nodes require this relationship? RHS nodes?
  • What is the ordinality of the relationship? (e.g. 1:1, 1:many many:many)

• The UI to draw those relationships

  • Can node-editors draw this relationship when editing a node meeting LHS criteria?
  • Can node-editors draw this relationship when editing a node meeting RHS criteria?
  • Who can draw this relationship? (Permissions/ACL)
  • (I'm sure there are other points where flexibility is arguably required here. These are the main ones that I can think of)

• The display format of the relationships when a node is viewed

  • obviously the related nodes and their type of relationship should be defined in the $node object for themers
  • Drupal users need to be able to display the list of nodes without theming skills. Possible display formats that could be offered as options to the user are; a list of links, teasers, full nodes, table of titles and other fields, a views.module view

In tackling these problems...

The main issue, and most complex is the relationship itself. I'm not an information architect (yet), but the efforts shown at http://groups.drupal.org/node/1966 seem to be the most general solution to relationships that can be implemented drupal-wide. However it's probably a long way away (drupal 6 at earliest). For the short term, it seems that a lot of people in this thread have their own implementation that works for their needs (self included).

Keeping that in mind, I think we should consider implementing an AS SIMPLE AS POSSIBLE patch, that doesn't try to handle all possible relationship types (possibly is restricted to node type for criteria), but does try to deal with the UI for handling the drawing and displaying of such relationships. This code could later be ported and integrated with the relationships API or some other relationship layer that handles the details of the relationship itself (and it's storage) when it becomes available. It could be that the UI layers are ported into a different module (a field is arguably not the correct place for a relationship).

The UI to draw relationships is largely already implemented in nodereference, and works well. It is fully implemented for LHS nodes. Implementing it on the RHS could be a new CCK field that has the same interface as nodereference but INSERTS the values in opposite order. The name of the field and it's help/description text needs to be different to it's RHS equivalent (e.g. LHS label could be "This node's parent", While RHS's label could be "This node's child/children"). At that point we'd need to decide what different ordinalities we want to deal with (remembering that it should be kept simple and will ideally by a handled by a relationship layer in a future iteration).

I purposely haven't tried any of the patches in this thread to maintain my objectivity about this. But It sounds like some of the code in this thread already does the above. Am I right?

The last and simplest point is the display and themability of the related nodes. CCK already has a way of offering display options through the "display fields" tab.

I think that any integration with views.module should only be exposure of relationships to views. And the relationship layout should take care of this.

PS. subscribing...

The thread on groups.drupal.org you referenced seems to be stale, so I have decided to answer here.

* the relationship

The IMHO most important thing is to define a data structure that can hold what we could possibly want from relationship, so let's look at the most complicated cases.
The mathematical model for relationship is a graph (not a tree, those are a special case!). To make life a bit easer we can say all points in the graph are nodes. Each each in the graph can be directed, but doesn't have to be. Each edge of the graph can have properties. And we need to make sure we don't run into cycles when following edges ...
This is just a way to say we want to support many:many relationships with properties attached to them.

That means we probably need 2 database tables:
1 for the relationship itself (rel-id, rel-type, lhs-id, rhs-id, direction), and one for the properties attached to it. Maybe a third for defining possible properties ...

* the UI to draw them & display

I think this would be the task of a relationship cck field to can be added to all nodes where we would possibly want to diplay/edit (part of) the relationship. Permission may become interesting, haven't yet thought of a clear model for that ... but cck field permissions may be a first step here.
And another major player to do fancy things with relationships sure is the views module ...

All right, can't think of more right now.

subscribing

It sounds like _you're_ working for your car-r-r. Simplify-y, ma-an!

I think trying to account for relationship types with a single CCK addon (nodereference) is probably biting off too much. As noted upthread, they're complicated. It seems to me that there are so many possible relationships that the solution is to allow them to be extended (easy enough w/current data structure) rather than try and build a one-size-fits-all module.

However, it would be a nice improvement if, at least at the $node object level if not the theme, nodes were aware of being referenced. I can and do add this easily enough when I need it with nodeAPI, so maybe I should put my money where my mouth is and make a simple little module for it. Maybe it'll start a trend... ;)

Anyone have a PHP snippet or a specialized View that can be displayed any and all incoming nodereferences for a given node, that will work with the current version of the CCK (1.5)?

Anyone have a PHP snippet or a specialized View that can be displayed any and all incoming nodereferences for a given node, that will work with the current version of the CCK (1.5)?

subscribing

Are there any news that the back link functions will make it into core? I allways add own developments to build CRM applications using Drupal with content in context using the backlinks.

You need to check what's going on with nodefamily and relativity, I think any solution for back-referenceable links must come from there.

If depending on an external module is not wanted, maybe nodereference should have it's own database table saving
<refid, fieldname, source-nid, target-nid> ?
That would also allow editing of relation data on both ends of the relation ;-)

Changing the code to save this data in an extra table shouldn't be too hard, migration of existing data is another matter ...

I could make a little patch saving the relationship data in an extra table, or do we wait for some kind of release of the relationship api, or is there any other plan on how to move forward with this topic?

subscribing

I am pointing to dopry's project "Node Referrer" which I think is a very good approach. It acts a bit like "computed_field" meaning that it creates a mere "read-only" field that displays referrers. A comment was posted on this thread earlier by the author but it wasn't very clear to me that the project was still alive and so interesting when I first read the thread, so I'm reposting the link to the project here:

http://drupal.org/project/nodereferrer

subscribing

I'm very interested in this functionality. Does the patch dopry provided in post #124 work with the current version of CCK?

I'd like to try out his nodereferrer module as well, but it seems there are no releases of it yet. :(

@Fayna: The patch in #124 is likely not complete - I'm not sure if I tried that one as well, but it might not even work. I had a look at the nodereferrer module as well, and it seems you should definitely try this out. No releases just means that there's nothing to download through the website, but all the code does exist in CVS. (So don't rely on it functioning properly as it isn't released yet, but it's certainly in a better state than the above patch.)

For getting code out of CVS, see the Checking Out from the Contributions Repository page (part of the overall CVS handbook for Drupal), specifically, the terminal command for this module in its current state should be
cvs -z6 -d:pserver:anonymous:anonymous@cvs.drupal.org:/cvs/drupal-contrib checkout -d nodereferrer contributions/modules/nodereferrer

I think I got it now. Thanks jpetso! :)

As an aside.... nodereferrer is getting close to a 1.x release. I've been putting in some time with it lately... It's recently gotten some of my attention thanks to christefano. It should be pretty stable currently and dev releases should show up on the project page in the next few days.

Anyone know if anyone is working on the aforementioned "userreferrer" yet? KarenS mentioned it back in post #127. I'd be interested in testing that.

Anthony Pero

Subscribing. greetings, Martijn

NodeReferrer (or NodeReference for that matter) may not fulfill each and every need regarding node relationships, but it solves the basic issue here, which was to provide a reverse link for NodeReference fields. Rejoice!

Hey all,

this may help -> more specifically, a version of the nodereference field that works in Drupal 6 is in this post.

Matherion

Subscribing.