When using voting actions and a node requires an update (e.g., promote to front page, etc.) the taxonomy terms are loaded as an array of objects and passed to taxonomy_node_save() as a normal part of the update. The original code handled only an array or terms NOT an array of objects. This resulted in a database update warning of duplicate key during update and all taxonomy terms gettig lost for the node.

Here is the patch required to fix:

diff -c /home/sites/drupal-4.7.0-beta4/modules/taxonomy.module\~ /home/sites/drupal-4.7.0-beta4/modules/taxonomy.module
*** /home/sites/drupal-4.7.0-beta4/modules/taxonomy.module~     2006-01-26 02:33:20.000000000 -0600
--- /home/sites/drupal-4.7.0-beta4/modules/taxonomy.module      2006-02-28 12:32:12.000000000 -0600
***************
*** 644,649 ****
--- 644,652 ----
            }
          }
        }
+       else if (is_object($term)) {
+         db_query('INSERT INTO {term_node} (nid, tid) VALUES (%d, %d)', $nid, $term->tid);
+       }
        else if ($term) {
          db_query('INSERT INTO {term_node} (nid, tid) VALUES (%d, %d)', $nid, $term);
        }

This patch handles the object case and rewrites the term table correctly.

versions:
drupal 4.7-b4
all modules secified on the Voting +1/-1 project page (http://drupal.org/node/48774) as of 2/28/2006

Comments

webchick’s picture

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
commented
Project: Drupal core » Vote Up/Down
Component: taxonomy.module » Code

This sounds like a bug in one of the modules that is not passing taxonomy_node_save what it expects (which is an array, not an object), not a bug in taxonomy_node_save itself. Filing against vote up/vote down module for now, though this may actually be a bug in links or voting API.

crolex’s picture

crolex commented

I'm new to Drupal but... I think the root of the bug is that the updated $node is read in from the database as opposed to beng built from a submitted edit form. The resulting $node->taxonomy element is fully populated with taxonomy context.

Note that the node is read in from the DB in voting_actions_votingapi() which is well above the voting +/- logic. It could be fixed there but I suspect that fixing it in the taxonomy.module (at the point of use) is more robust in that there may be other node auto-update apps in the future.

Should this be assigned to votingapi.module?

eaton’s picture

eaton commented

Vote up/down doesn't do any node saving on its own -- so the problem would indeed lie in the voting actions module that does the node_save call. I'll take a look and see what's up.

eaton’s picture

eaton commented

I just tested the CVS version of voting_actions.module with simplevote, and I can promote/unpromote without triggering any error. I'll have to install vote up/down to see if the problem lies there.

crolex’s picture

crolex commented

Eaton,

Just checking... make sure that your test is voting on nodes that have existing taxonomy associations. It's the rewriting of the pre-existing taxonomy terms that causes the failure.

crolex’s picture

crolex commented

One more item... the nodes that I was using that had the problem were weblinks.

eaton’s picture

eaton commented

crolex, yes -- I added some terms to the nodes in question and voted them up, voted them down, promoted, unpromoted, etc. No problems using simplevote + votingapi + voting actions.

There were some recent CVS schema changes to both votingapi and voting actions to manage some new features, but they shouldn't affect any module that used the standard functions and constants for the API -- and they certainly shouldn't have an impact on this. Again, I'll try to take a closer look at how vote up/down is doing its thing.

frjo’s picture

frjo commented

I can replicate this problem when using categories, after voting they are reset. I would very much appreciate any help in fixing it.

I just got this error.

Warning: Duplicate entry '1-18' for key 1 query: INSERT INTO term_node (nid, tid) VALUES (18, 1) in /home/u1145/xdeb.org/web/vigillar/includes/database.mysql.inc on line 120

Warning: Cannot modify header information - headers already sent by (output started at /home/u1145/xdeb.org/web/vigillar/includes/database.mysql.inc:120) in /home/u1145/xdeb.org/web/vigillar/includes/common.inc on line 233
frjo’s picture

frjo commented

Using the last cvs versions of Drupal and all the modules including Vote up/down Package I can't reproduce this bug anymore. Can anyone confirm that it's gone?

jackdaw’s picture

jackdaw commented

I think that it is either still there, or maybe has been reintroduced. Have been testing a site similar to your (vigillar) for 5 days now, with the newest packages available then. It ran fine until yesterday, when I started getting errors like this:

Duplicate entry '1-12' for key 1 query: INSERT INTO term_node (nid, tid) VALUES (12, 1) in...

It resets categories for already posted storylinks, which I guess makes it a huge error. Note though, that I updated the vote_up_down package to the newest cvs version yesterday morning, before the errors started popping up.

jackdaw’s picture

jackdaw commented

... and note that I have been running another similar testsite for 2 weeks now, with the newest packages from then and no errors. It has as many (or few) storylinks as the one mentioned above, but I don't use categories on it yet (on the other, I use free tagging).

So without being an expert, I guess the bug has either been reintroduced, or is linked to the usage of categories together with the vote_up_down package.

frjo’s picture

frjo commented

I still can't reproduce this bug on vigillar.se. Something must be different on our sites and I hope we can pinpoint it and get rid of this serious bug.

Have you remembered to run "example.com/update.php" after updates?

I'm running the following version of the modules. All are the latest cvs version as of 15 minuts ago, including Drupal core.

$Id: actions.module,v 1.18 2006/04/18 02:16:23 jvandyk Exp $
$Id: links.module,v 1.12 2006/04/08 02:59:37 syscrusher Exp $
$Id: taxonomy.module,v 1.272 2006/04/11 17:57:37 killes Exp $
$Id: vote_storylink.module,v 1.13 2006/04/14 10:34:59 frjo Exp $
$Id: vote_up_down.module,v 1.6 2006/04/14 10:34:59 frjo Exp $
$Id: votingapi.module,v 1.24 2006/03/12 18:10:20 eaton Exp $
jackdaw’s picture

jackdaw commented

Right, my corresponding versions are not exactly the same:

$Id: actions.module,v 1.17 2006/02/09 19:37:00 jvandyk Exp $<br>
$Id: links.module,v 1.11 2006/03/24 05:15:28 syscrusher Exp $<br>
$Id: taxonomy.module,v 1.271 2006/04/07 15:32:17 unconed Exp $<br>
$Id: vote_storylink.module,v 1.13 2006/04/14 10:34:59 frjo Exp $<br>
$Id: vote_up_down.module,v 1.6 2006/04/14 10:34:59 frjo Exp $<br>
$Id: votingapi.module,v 1.24 2006/03/12 18:10:20 eaton Exp $<br>

I've maybe been too lazy, using the downloadable release packages for everything except the vore_up_down package, where (then) I had to use the cvs.

I'll try to update everything and tell you how it goes. But are you saying that I should run the "example.com/update.php" also when updating modules? Being a newbie, I thought that it was just for when I updated the Drupal core.

frjo’s picture

frjo commented
Assigned: Unassigned » frjo

But are you saying that I should run the "example.com/update.php" also when updating modules?

Yes, in Drupal 4.7 modules can hook in to this update function.

links, votingapi and voting_actions use it among others.

frjo’s picture

frjo commented
Version: 4.7.0-beta4 » 4.7.x-1.x-dev
Status: Active » Fixed
Anonymous’s picture

(not verified) commented
Status: Fixed » Closed (fixed)