I've noticed that when you have corresponding node reference field if a node of content type A gets deleted, the corresponding nodereference field in content type B still holds the value for the node of content type A that was deleted.
subsequently, when you then go and try to edit content type B, when you try and save on the node edit form, it comes up with the error 'this post can't be referenced.' This is because the node A no longer exists (because you just deleted it) so it cannot reference it.
should the intended behaviour be to delete the reference field in content type B node when the node of content type A is deleted. this way the fields would be up to date?
FYI - I have setup a multiple -> multiple corresponding node reference on each content type.
Comments
Comment #1
tayzlor CreditAttribution: tayzlor commentedEDIT: this is a duplicate of this issue - http://drupal.org/node/463444. i'm experiencing the exact same behaviour.
Comment #2
tayzlor CreditAttribution: tayzlor commentedEDIT: this is a duplicate of this issue - http://drupal.org/node/463444. i'm experiencing the exact same behaviour.
The weird thing is, if you check the database, the database values are totally correct (there is the same number of node references in each db table)
it is only on the node edit field that you can see a reference to the old NID. Could this be cached anywhere??
Also, funnily, if i then go and create another node reference programmatically (after i have deleted 2) then they totally disappear off the node / edit form and everything is back to normal.
seems like some kind of caching on the node / edit form or something?
Comment #3
domidc CreditAttribution: domidc commentedIt could be a cache problem.
What happens when you manualy flush the cache on admin/settings/performance? Is the deleted node gone in the node reference field?
Unfortunaly I dont seem to able to duplicate the problem.
This is my setup
I have three node types
Job
Office
Client
a job has a ref to an office and a client and the other two have a ref to the job.
I enabled normal caching. Deleted a job, the reference also disappeared on both the office and the client. In the database all is well too.
Cnr does flush the content cache when inserts and updates occur but not on deletion since drupal already does that. Do you have the latest core installed?
A possible sollution would be to flush that cache on deletion the same way as on updating and inserting. Try putting this function corresponding_node_references_clear_cache($node) in hook nodeapi where the delete operator is active in the switch.
You should end up with this.
Let me know if this solves your problem.
If not perhaps you could provide me the exact configuration of your node references and corresponding node references? Or perhaps you could send me a dump of your database and a copy of your code of the entire site if no security issues are involved.
Comment #4
domidc CreditAttribution: domidc commentedComment #5
domidc CreditAttribution: domidc commentedClosing it since no one is giving feedback
Comment #6
petermilad CreditAttribution: petermilad commentedHello,
I face the same problem, and I think the posted code differs from the original code in cnr.module a lot, it's not just a call to clear_cache() function. I tried emptying the cached data but nothing. the referenced node reference still exist in the field_content_NODE_REFERENCE field in the database. so, is there a solution for such a problem!?
Comment #7
CkPoMHbIu CreditAttribution: CkPoMHbIu commentedSubscribes :( Can not solve this problem :(
domidc, how can I help to you for understanding this issue?
Comment #8
CkPoMHbIu CreditAttribution: CkPoMHbIu commentedI have found a cause of error!
function corresponding_node_references_delete($home_node, $home_field, $away_node_type, $away_field) {
// Iterate through the field's references.
foreach ($home_node->$home_field as $reference) {
if (!empty($reference['nid'])) {
// Load the referenced node if it is of the specified away type.
if ($referenced_node = node_load(array('nid' => $nid, 'type' => $away_node_type))) {
// Iterate through the away node's references.
foreach ($referenced_node->$away_field as $key => $value) {
// Remove references to the deleted node.
if ($value['nid'] && $value['nid'] == $home_node->nid) {
unset($referenced_node->{$away_field}[$key]);
_corresponding_node_references_update($referenced_node);
break;
}
}
}
}
}
}
Threre are the check: if (!empty($reference['nid']))
But further the text follows: node_load(array('nid' => $nid, 'type' => $away_node_type)),
The variable $nid is not defined. It is necessary to use $reference['nid'].
Comment #9
petermilad CreditAttribution: petermilad commented@domidc #5
Me and CkPoMHbIu have subscribed this issue and we are eager to give you the info you need if the current is insufficient.
There is a temp solution for this bug. I created a custom module implementing the hook_nodeapi(), in case of deletion specific content types I search for the node id in the relation fields table and delete this relation myself, I find this fix is not right but just a quick fix, but such a feature should exist in the CNR module itself.
Comment #10
domidc CreditAttribution: domidc commentedGuys I ll look to it tomorrow, then we have a holiday in Belgium.
Comment #11
asak CreditAttribution: asak commentedSubscribing..
Comment #12
gweston CreditAttribution: gweston commentedsubscribing
Comment #13
petermilad CreditAttribution: petermilad commentedWell
seem to have the problem, this code snippet is from the corresponding_node_references.crud.inc line number 144
content_update() doesn't really update well, which it sets the references to NULL but doesn't entirely remove this row, this is it for now. I might end up replacing this line with deleting the original node and add the new updated node, but this solution is just for now and not acceptable at all.
Another solution is to add an sql statement "delete from the content_field__REFERENCING_TABLE where REFERENCING_VALUE is null"
Any other solutions ?
Comment #14
xenophyle CreditAttribution: xenophyle commentedsubscribing
Comment #15
mrfelton CreditAttribution: mrfelton commentedsubscribing
Comment #16
momper CreditAttribution: momper commentedsubscribe
Comment #17
etomilin CreditAttribution: etomilin commentedPatch in #8 seems to work fine. I checked DB - after patching it cleans up links for deleted nodes (which were left untouched causing problems before).
I think it should be reviewed and applied in the next release.
Comment #18
domidc CreditAttribution: domidc commentedThis is included in version 6.4 which is currently still in dev.
Comment #19
Exploratus CreditAttribution: Exploratus commentedSo no patch? What is the patch in #8? How do we apply?
Comment #20
etomilin CreditAttribution: etomilin commentedThis issue was fixed in 4.1