Incorrect retrival of node's taxonomy terms with revisions
| Project: | Pathauto |
| Version: | 6.x-1.1 |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs review |
Some background info:
I have a site that uses termpath-raw aliases for some node types. I noticed that sometimes when the assigned terms changed the alias did not update accordingly or reverted to a very old version. Deleting existing aliases and recreating them didn't help either.
The issue lies in pathauto_token_values() function. For a node it attempts to retrieve taxonomy related data using the following query:
$category = db_fetch_object(db_query_range("SELECT t.tid, t.name FROM {term_data} t INNER JOIN {term_node} r ON r.tid = t.tid WHERE t.vid = %d AND r.nid = %d ORDER BY weight", $vid, $object->nid, 0, 1));This query should account for different versions of the term assignment eg. if my node was tagged with "foo", then "bar" and eventually "baz" in the same vocabulary then this query will return the term based on term weight and not the currently assigned term.
The solution to fix it is actually simple:
$category = db_fetch_object(db_query_range("SELECT t.tid, t.name FROM {term_data} t INNER JOIN {term_node} r ON r.tid = t.tid WHERE t.vid = %d AND r.nid = %d ORDER BY r.vid DESC, weight", $vid, $object->nid, 0, 1));Fixing this query is only half of the problem - Token module borrowed this functionality in node_token_values().
Instead of
$term = db_fetch_object(db_query_range("SELECT t.tid, t.name FROM {term_data} t INNER JOIN {term_node} r ON r.tid = t.tid WHERE t.vid = %d AND r.nid = %d ORDER BY weight", $vid, $object->nid, 0, 1));it should be
if (!isset($term->name)) {
$term = db_fetch_object(db_query_range("SELECT t.tid, t.name FROM {term_data} t INNER JOIN {term_node} r ON r.tid = t.tid WHERE t.vid = %d AND r.nid = %d ORDER BY r.vid DESC", $vid, $object->nid, 0, 1));
}
else {
$term = db_fetch_object(db_query_range("SELECT t.tid, t.name FROM {term_data} t INNER JOIN {term_node} r ON r.tid = t.tid WHERE t.vid = %d AND r.nid = %d ORDER BY weight", $vid, $object->nid, 0, 1));
}Since this issue spans across two different modules I'm not sure how to submit patches. Any suggestions?
#1
Great find. Can you just make two issues and submit two patches?
#2
Patch for Pathauto attached.
Patch for Token can be found here - http://drupal.org/node/423322
#3
This makes sense, but perhaps even better would be a change like the attached. Thoughts?
#4
+1 This seems like a better solution than mine
#5
Applied to
6.x-1.x: http://drupal.org/cvs?commit=199982
5.x-2.x: http://drupal.org/cvs?commit=199984
6.x-2.x: http://drupal.org/cvs?commit=199992
#6
#7
Automatically closed -- issue fixed for 2 weeks with no activity.
#8
#485210: SQL Error - Unknown column 'r.vid' in 'where clause' query
I think the patches for 5.x should be reverted. Right?
#9
Fixed - http://drupal.org/cvs?commit=223522
#10
Automatically closed -- issue fixed for 2 weeks with no activity.
#11
The current implementation of pathauto_token_values() has a problem when the revisioning module is enabled.
In this case the where clause of the second query should filter by the actual node revision (the one indicated by $object->vid value).
I attached a very simple patch to resolve this issue.
Thanks for this excelent module.
Leandro
#12
The revisioning module?
Seems reasonable enough. Anyone else care to check?
#13
Yes, the revisioning module.
In my previous patch, I only considered the bulk node alias generation, but I didn’t consider saving a pending revision. In this case, the $object->vid value corresponds to the saved revision, not to the current node revision (indicated by vid column value in the node table). For this reason, a join with node table is required.
The new node alias shouldn’t be generated until the new revision is approved. The alias could be generated using the rules module.
I attached a new version of the patch and also submited the corresponding patch to the token module (#423322: Incorrect retrival of node's taxonomy terms with revisions).
I hope this will be the good one.
Leandro
#14
I had same issue outlined at top of this thread. I already had the patched versions of pathauto so it seems the official patch has not resolved the issue in all cases. I did find, however, that Leandro's patch in comment #13 worked for me (even though I didn't have the revisioning module installed).
#15
I experienced the exact same issue with versions enabled. The patch in #13 fixed the issue using the current development version 6.x-1.x-dev.