The revisions tab on node does not show an accurate Term column if there are multiple term reference fields attached to a node bundle. The issue is the formation of the SQL in the _revisioning_get_all_revisions_for_node() function, inside the "if ($include_taxonomy_terms) {". If there are multiple fields the SQL created adds a LEFT JOIN to the table for each term reference field and adds that table's *_tid field to the SELECT statement aliased as term. The result is you have one field in the SELECT statement named `term` for each term reference field attached to the node bundle in question.
Sample SQL using term reference field called term_field1 and term_field2 searching for ficticious node nid=12345.
SELECT r.vid,
r.status,
r.title,
r.log,
r.uid,
r.timestamp,
u.name,
ttd_field_term_field1.name AS term,
ttd_field_term_field2.name AS term
FROM `node_revision` r
INNER JOIN `users` u ON r.uid=u.uid
LEFT JOIN `field_revision_field_term_field1` r_field_term_field1 ON r.vid = r_field_term_field1.revision_id
LEFT JOIN `taxonomy_term_data` ttd_field_term_field1 ON r_field_term_field1.field_term_field1_tid=ttd_field_term_field1.tid
LEFT JOIN `field_revision_field_term_field2` r_field_term_field2 ON r.vid = r_field_term_field2.revision_id
LEFT JOIN `taxonomy_term_data` ttd_field_term_field2 ON r_field_term_field2.field_term_field2_tid=ttd_field_term_field2.tid
WHERE r.nid = 12345
ORDER BY r.vid DESC;
When the foreach goes to loop through the result it only grabs that last `term` field in the SQL's SELECT statement, meaning the other get ignored, or even more annoying if the last field id null nothing gets printed at all.
Additionally it would likely be more efficient to check the taxonomy_maintain_index_table variable in the variables table as run this query against the taxonomy_index if taxonomy_maintain_index_table = TRUE.
I'm working on a patch, but it may take a little while to get to it.
| Comment | File | Size | Author |
|---|---|---|---|
| #10 | revisioning_incomplete_terms_1458714_D7.patch | 4.09 KB | sjpatrick |
Comments
Comment #1
rdeboerThanks for pointing this out jalama!
Look forward to your patch.
Rik
Comment #2
Nick Bell commentedDid you ever get to a patch? Would be grateful for any help sorting out this problem.
Nick
Comment #3
rdeboerNope.
Sorry.
Comment #4
Nick Bell commentedThanks Rick
Could you give me any tips? I'm looking at function _revisioning_get_all_revisions_for_node but not sure where to go from there.
I was wondering whether the easiest thing might be to replace this table with a View (I have a nice view set up showing what I want with multiple taxonomy terms).
Comment #5
rdeboer@md2017
Hi Nick,
I think bigjim was referring to function
_revisioning_get_all_revisions_for_node(...)in file revisioning_api.inc -- oh ooops, so were you...A canned View like you suggest is probably even better, if it has the complete functionality...
Rik
Comment #6
Nick Bell commentedOK here's my attempt, which yields what I want. Its base is Revisioning 7.x-1.4+4-dev. It should work for Tags as well, but I haven't tested it. Can someone have a look? I've never done a patch before.
Comment #7
rdeboerHi Nick,
Thanks so much for your work on this. Well done.
It would be nice for you and us to learn about the "diff" command (whose output is effectively what a patch is) and its option to ignore blanks.
The way things are at the moment I'll have to go through your code line by line to find out what the differences are.
Rik
Comment #8
Nick Bell commentedDo I just diff against http://ftp.drupal.org/files/projects/revisioning-7.x-1.x-dev.tar.gz ?
Comment #9
rdeboerI need a proper diff/patch file to review and apply.
The diff should be agains the 7.x-1.x branch, ie. 7.x-1.x-dev snapshot.
Rik
Comment #10
sjpatrick commentedI also ran into this issue while working on an intranet feature we are migrating from our D6 site to our new D7 model.
I tried applying the code changes listed above but still wasn't getting results that looked like they did in D6.
So I took my own stab at it.
Patch included.