[MASTER] term_node tid getting set to "1"

The original line is verbatim from taxonomy.module.

Something else is wrong if the code doesn't work... Something's setting the key, but not the value....

Hmm, http://drupal.org/node/89270 mentions that $term is an object, but $term->tid is not being set. Possibly $term is in the wrong format during saving, or the format changed and this place in the code wasn't updated....

Had the same problems (came here from http://drupal.org/node/89270 ,which seems to be caused by this one )

Looks like $term is indeed in a wrong format, since it is a category object (or array of those, if there is more than one category assigned to the node).

As bdragon mentioned, the taxonomy_node_save() function is legacy code from taxonomy.module and therefore expects a taxonomy object (or array of those), but gets called from within the taxonomy_nodeapi() function (wrapper version) with $node->category as the second parameter. I changed the two calls there (insert and update) to pass $node->taxonomy instead, which seems to be already available at that moment (for updates as well as for inserts) and everything works fine.

This fixes the 89270 problems with the views also (at least for me), since they need to look up the categories in the term_node table via the tid, which is always 1 without the patch.

NOTE: I'm quite new to drupal in general and the category module in particular, so the 'needs review' part should be taken somewhat seriously ;)
(I'm also not too familiar with cvs and the patch standards around here; The diff is against the current 4-7 branch (fileversion 1.15.2.9), but the HEAD version (fileversion 1.24) is identical. Any hints and corrections concerning the 'local habits' are welcome :)

Hm, after sleeping over it I think I should clarify the 'needs review' part of the fix:

I'm pretty sure that $term needs to be a taxonomy object (or array of ...), otherwise it wouldn't have a tid. But I'm not really sure about the assumptions of my proposed fix:

I only *observed* that at the time of the call to taxonomy_node_save(), the $node already contains proper taxonomy object(s), so I just used them and it works. However I'm not too familiar with the taxonomy wrapper, so I don't know where these taxonomy object(s) in the $node come from and if they will *always* be there at that moment!?

I noticed that there are two helper functions in the module that convert category objects (or arrays of ...) to taxonomy objects. So if my assumption of the taxonomy object(s) already being available in the $node is wrong, we could use those to get the taxonomy object(s) that taxonomy_node_save() expects, but it would be more code and an additional function call.

To sum it up, it would be nice if someone more knowledgable of this module could confirm/deny the assumption of the taxonomy object(s) always being available in the $node variable.

HeO: Don't be shy about marking bugs as duplicates. It helps increase the signal-to-noise ratio, and that's something that is really needed here. :-)

I'll take a look at this in a bit.

I'm tracking this thread now, while trying to get rid of the duplicate entry issue and category views.
http://drupal.org/node/65355 (and http://drupal.org/node/89844)

As i reviewed the tables, my term_node tid is 1 for all entries.
I have a bad install of category, where category legacy was missing.
This lead to uncategorized nodes, as i posted here: http://drupal.org/node/89545
Now i wonder if the missing tid refers to these missing term IDs from all my categories.

With further testing i find this:
I have several containers assigned to a node type.
If no categories are selected nothing happens, but selecting categories throws the duplicated entry error for each one beyond two.

I'll try the patch, altough i'd probably need to fix the tables first or redo all categories.
About the patch, are these the only changes?
- taxonomy_node_save($node->nid, $node->category, $node);
+ taxonomy_node_save($node->nid, $node->taxonomy, $node);

changed
taxonomy_node_save($node->nid, $node->category, $node);
with
taxonomy_node_save($node->nid, _taxonomy_categories_into_terms($node->category), $node);

That gave me the same results of changing
taxonomy_node_save($node->nid, $node->category, $node);
with
taxonomy_node_save($node->nid, $node->taxonomy, $node);
as suggested.

By debugging taxonomy_node_save() i noticed the tid was being passed an object.
This solved my "duplicate entry" errors when updating.

@inforeto
Sorry for the late reply, been away over the weekend :)

Yes, the two changes from $node->category to $node->taxonomy are the only changes in the patch. The effect should be identical to your second approach using the helper function to convert the category object(s) to taxonomy object(s) before passing them in taxonomy_node_save(). *If* my assumption of the taxonomy object(s) being already available in the $node variable are valid all the time, I would prefer the first approach - no need to do the conversion multiple times (See comment #5).

As for the fixing of the term_node table after patching, a possible approach would be to 'manually' drop all the wrong (tid = 1) entries, then opening all your nodes that use categories in drupal and resubmitting them without any changes. This will produce the correct entries in the term_node table, but depending on the amount of content you already have (and on your confidence in altering the database directly), this might be more work (and mor error prone concerning oversights) than fixing the table directly via update statements.

Thanks guys! HeO's patch from #4 (above) committed to HEAD and 4.7.

Re-activating this issue because of facing with bug that described in subj, but my drupal version is 5.1 and patch by HeO is already committed in that version. Making clean install of drupal 5.1 along with only 2 modules: Views-5.x-1.5 and Category-5.x-1.1. All parts of modules are enabled except of "Views RSS", "Views Theme Wizard", "Category access control lite" and "Category export". Creating new container and assigning it to some content type i.e. story and then sequentially creating some categories in this container. When submitting some story and choosing one of category. "tid" values in table "node_term" always set to "1". That leads to "Views" module doesn't work correctly because it uses that table to filter data by terms.
Did some investigation: as I said HeO's patch is already there, so it is not the solution. But when applying patch provided by jvandervort everything seems to work fine. Below is code from taxonomy module and taxonomy wrapper to compare:

Taxonomy module

if (is_array($terms)) {
    foreach ($terms as $term) {
      if (is_array($term)) {
        foreach ($term as $tid) {
          if ($tid) {
            db_query('INSERT INTO {term_node} (nid, tid) VALUES (%d, %d)', $nid, $tid);
          }
        }
      }
      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);
      }
    }
  }

Taxonomy wrapper

if (is_array($terms)) {
      foreach ($terms as $key => $term) {
        if ($key != 'tags' && $key != 'legacy') {
          if (is_array($term)) {
            foreach ($term as $tid) {
              if (!empty($tid)) {
                db_query('INSERT INTO {term_node} (nid, tid) VALUES (%d, %d)', $nid, $tid);
              }
            }
          }
          else if (isset($term->tid)) {
            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);
          }
        }
      }
    }

See the difference: in wrapper "($terms as $term)" (next to foreach) part changed to "($terms as $key => $term)", but "$term" (in last db_query) remains intact.
I'm not the guru in php, but for me changing this "$term" to "$key" (according to jvandervort's patch) made everything working and now tid's are correctly inserted into node_term. Have to be like that:

if (is_array($terms)) {
      foreach ($terms as $key => $term) {
        if ($key != 'tags' && $key != 'legacy') {
          if (is_array($term)) {
            foreach ($term as $tid) {
              if (!empty($tid)) {
                db_query('INSERT INTO {term_node} (nid, tid) VALUES (%d, %d)', $nid, $tid);
              }
            }
          }
          else if (isset($term->tid)) {
            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, $key);
          }
        }
      }
    }

Please test it on your own and if it is a real, I propose to commit it to next version of Category module.

Subscribing. I am having a problem on 5.1, every time I create a new node or update an old one, I get a 'duplicate entry' error. Has anyone looked at the category code and reviewed the above change? I would, but I am not clear on where I am supposed to make the change.

Thanks,
Maria

Maria find the file "\modules\taxonomy\taxonomy.module", open it and replace the following string:
db_query('INSERT INTO {term_node} (nid, tid) VALUES (%d, %d)', $nid, $term);
with new one:
db_query('INSERT INTO {term_node} (nid, tid) VALUES (%d, %d)', $nid, $key);
Don't forget to save backup copy before proceeding. Please, report your results here.

this patch works for me

Banshee,

I made the change at line 575 of taxonomy.module, and I don't appear to be getting the error. I will repost if that changes. Thanks!

Maria

Update: I added a new page (before, I just updated an old page), and received the same error.

I think the problem here comes back to the taxonomy_nodeapi function. There this code block appears twice:

      if (empty($node->taxonomy)) {
        if (!empty($node->category)) {
          $node->taxonomy = $node->category;
        }
        else {
          $node->taxonomy = taxonomy_node_get_terms($node->nid);
        }
      }

The problem is that $node->taxonomy and $node->category have a different structure. I was able to fix it on my install with a function to translate from categories to the taxonomy term structure:

function taxonomy_terms_from_category($category)
{
  foreach($category as $key => $term) {
    $terms[$key]=$term->cid;
  }
  return $terms;
}

and

          $node->taxonomy = taxonomy_terms_from_category($node->category);

I just took another look at the code. That needed function is already there, so the fix is basic and logical. It means simply replacing in taxonomy_nodeapi the two instances of:

          $node->taxonomy = $node->category;

with:

	  $node->taxonomy = _taxonomy_categories_into_terms($node->category);

I think this is addressing the cause, rather than the symptoms in some of the earlier fixes. Patch attached.

Digging back further on this issue, it seems it may have been fixed in 1.25, but then the same symptoms came back in 1.26.2.1 where the category to taxonomy assignment was introduced.

http://cvs.drupal.org/viewcvs/drupal/contributions/modules/category/wrap...

Hence my patch here is in a different context to the earlier posts. This new patch fixes this issue again, but I don't fully understand why those assignment blocks were added in 1.26.2.1

The CVS log indicates these changes were for http://drupal.org/node/59728 and http://drupal.org/node/90145 . These issues seem to be current, and so may be a related bug.

The offending patch seem to be actually coming from http://drupal.org/node/115693 , and is referenced in http://drupal.org/node/59728 at #23 . So to validate his patch, it should only be necessary to make sure that simplenews and forum are happy with that form of the taxonomy field.

Heh, actually, I copy-pasted my patch from the section of the code your patch touched, IIRC.

Hmm...

I still think the taxonomy needs to be injected earlier than it is, but you're right that it's in the wrong format...

So with your patch alone, simplenews works properly?

In any case, I tested on one of my test sites, and I certainly noticed a reduction in the number of warnings. ;)

Patch from #19 committed to HEAD and DRUPAL-5.

Leaving open for feedback.

Marking as master issue.

Duplicates marked:
http://drupal.org/node/121399
http://drupal.org/node/122115
http://drupal.org/node/115783

Patch committed to DRUPAL-4-7 (4.7 is also exhibiting the problem apparently.)

Duplicates marked:
http://drupal.org/node/65355
http://drupal.org/node/89844

Hi,

I implemented the patch in #19 and got a view filtering on category working fine - thanks very much for that. I seem to need to re-categorise my content to make it appear in the view, though: is that to be expected?

Also, nodes seem to no longer be showing the categories they've been tagged with. Also, when I switch my (now fixed) view to "View Type=Table View" and have as the second field "Taxonomy: All Terms", then that does not have any content. Any ideas?

have implemented the patch in #19, but am still having the same problem with no nodes returned when trying to filter a view on category.

The filter just fixes the problem of not writing nodes to the node terms tables, which solves the duplicate entry issue.
But the nodes are still uncategorized to taxonomy terms.

Test if newer nodes appear in the results, if so, older nodes might need edition.
Or perhaps it is category nodes that need edition so that the equivalent terms get created.
At least this is a possibility that must be checked.

Hi, I tried applying the patch and am still getting the same error, wanted to make sure I did this correctly, since I'm fairly new to drupal.

error:
user warning: Duplicate entry '1-37' for key 1 query: INSERT INTO term_node (nid, tid) VALUES (37, 1) in /home/cardboar/public_html/humanosity/drupal/includes/database.mysql.inc on line 172.

what I did:
I opened up taxonomy.module.copyme and made the two changes in sbj's patch. I then uploaded and replaced the taxonomy.module.copyme file. After still getting the error, I deactivated and reactivated the category module. Still the same error.

I also only get this when I have multiple categories within one node submission.

Sorry a little clarification: I applied the patch in post #19 on version 5.x-1.1

I also have the Views, CCK, and Video modules installed.

I've tried applying the patch in #19 to 5.x-1.1 and 5.x-1.x-dev (already had the patch), and error persists.

user warning: Duplicate entry '1-122' for key 1 query: INSERT INTO term_node (nid, tid) VALUES (122, 1) in /home/.puppy/fredburks/dev2.transformationteam.net/includes/database.mysql.inc on line 172.

I have multiple categories (Country,State,City). When I select only Country, the error disappears, but as soon as more than one category is selected, the error happens for every extra category.

I'm also using Active Select module if that makes any difference.

Any ideas?
Andrey.

Upgrading to core 5.2 and using latest dev of Category seems to work for me now.

I have also updated to 5.2 and latest version, and I checked my taxonomy.module after installing the wrapper- the code from patch on #19 is in place.

Unfortunately, I still get the error!

What else could this be?

Im having same problem and cant seem to fix it.

    * user warning: Duplicate entry '14' for key 1 query: INSERT INTO fc3_node_revisions (nid, vid, title, body, teaser, timestamp, uid, format, log) VALUES (14, 14, 'Event Test', 'Testing Event', 'Testing Event', 1193066875, 1, 1, '') in /home/ross/public_html/fc3/includes/database.mysql.inc on line 172.

    * user warning: Duplicate entry '14' for key 1 query: INSERT INTO fc3_node_comment_statistics (nid, last_comment_timestamp, last_comment_name, last_comment_uid, comment_count) VALUES (14, 1193066875, NULL, 1, 0) in /home/ross/public_html/fc3/includes/database.mysql.inc on line 172.

Is this issue of such severity that we should consider offering a bounty? If this issue needs to be fixed in order to move Category into a stable 6.x version, maybe we should consider it, for the good of the project as a whole.

Only recently updated my Drupal installation (core & modules) to the last CVS of Drupal 5,
and the fix in #19 actually breaks things for me. Everything used to work fine, and now
term_node tid gets set to 1 upon node creation. I don't really understand the architecture
but reverting exactly that change solves the problem, so apparently, $node->category is a
hash table of term objects rather than category objects, as far as I'm concerned.

By the way, there's probably a typo on line 567 that may affect those left with legacy
vocabulary (not me): it goes

          db_query('INSERT INTO {term_node} (nid, tid) VALUES (%d, %d)', $tid, $nid);

I guess it should be $nid, $tid instead of the other way around.

I had thought that turning off the category_menu module had helped me... I was wrong. The error messages still appear. Ridiculous.

Ok. I have a setup with latest Category 5-2.
As far as i understand category and taxonomy have a different format. So why are the following lines (865 and 878) in the nodeapi function of taxonomy.module.copyme?

$node->taxonomy = $node->category;

Adding _taxonomy_categories_into_terms helps me out here.

$node->taxonomy = _taxonomy_categories_into_terms($node->category);

Views still works for me.
Patch attached.

i tought the conversion function was used in the file already, have it been reverted? Please review.
i haven't looked at it since i patched my own site in 2006.

Category 5.x-1.1 comes with Revision 1.26.2.2 of the wrapper, which do not have the patch yet.
Revision 1.26.2.3 has the patch included.

I have tested the patch on a backup of two production sites and it solved the inmediate problem of tid=1.
The values were stored in $term->tid, so i could not test if the other three queries work or not.

in category.inc

function category_node_get_categories_by_container($nid, $cnid, $key = 'cid') {
$result = db_query(db_rewrite_sql('SELECT c.*, n.title FROM {category} c INNER JOIN {category_node} r ON c.cid = r.cid INNER JOIN {node} n ON c.cid = n.nid WHERE c.cnid = %d AND r.nid = %d AND n.status = 1 ORDER BY c.weight'), $cnid, $nid);
$categories = array();
while ($category = db_fetch_object($result)) {
if $key =
$categories[$category->$key] = $category;
}
return $categories;
}

in taxonomy.module.copy

function taxonomy_node_get_terms_by_vocabulary($nid, $vid, $key = 'tid') {
if ($key == 'tid') {
$key = 'cid';
}

$categories = category_node_get_categories_by_container($nid, $vid, $key);
return _taxonomy_categories_into_terms($categories);
}

all the keys should be replaced: tid with cid (which is default), but also name with title, vid - cnid, etc...

This resolves some a issue with simplenews where categories ar not listed in sent/notsent newsletters :)

also i did a rewrite of the validation hook for taxonomy used in simplenews

case 'validate':
global $form_values;
if (empty($form_values['taxonomy']) && !empty($form_values['category'])) {
$form_values['taxonomy'] = $form_values['category'];
}
if (category_is_cat_or_cont($node->nid)) {
$type = category_node_get_type($node);
$is_cat = $type == 'category_cat';
if ($is_cat) {
taxonomy_save_term($edit = _taxonomy_prepare_edit_term($node, TRUE), TRUE);
}
else {
taxonomy_save_vocabulary($edit = _taxonomy_prepare_edit_vocabulary($node, TRUE), TRUE);
}
}
if (empty($node->taxonomy)) {
if (!empty($node->category)) {
$node->taxonomy = _taxonomy_categories_into_terms($node->category);
}
else {
$node->taxonomy = taxonomy_node_get_terms($node->nid);
}
}
taxonomy_node_save($node->nid, $node->taxonomy, $node);
break;

form_values and terms conversion :) have fun :D

terms conversion should be written in a separate function :p

I am totally confused now... As I understand correctly this is thread is about an issue that for some reason the nodes do not get the right taxonomy term assigned so that when I use a views filter by taxonamy term there is no output from views. I have this problem. Now which of the gazzillions patches up here and elsewhere (which are referring here mostly) is actually working? I tried a few none seemed to to anything. I am using the dev version from Jan 22 08 at the moment and can´t get any views filtering to work nor can I get something in the "categorybrowser"module f.e.

What can I do to make this work? Which patch to apply which version to install (without breaking any other fragile things connected)

The current patch is the one in post #41 or #19, both have the same code.
The rest of the code are pieces to check and test from reviewing the patches.

First check your version of the wrapper to see if it is not already patched.
I'm not sure about this, i think the dev for drupal 6 had it, and the packaged for 5x do not, but still check just in case.

Then apply the patch and check the database to see if new items are no longer being stored with tid of 1.
(if not, please do troubleshoot)

A final but important step is to fix the existing categories.
There's no tool to mass edit the categories, so you need to edit and resubmit every one.
The terms should show up in views when the right tid values exist in the database.

Ok this gets as strange as it can get.
As I said earlier I had the DEV 5.x-1.x installed that has the wrapper module version

// $Id: taxonomy.module.copyme,v 1.26.2.4 2007/04/07 20:22:14 bdragon Exp $

and the patches above are in place in that version...
Now all of the sudden I got the:

• user warning: Duplicate entry '1-127' for key 1 query: INSERT INTO drupal_live_term_node (nid, tid) VALUES (127, 1) in /home/13/fgcuried/drupal/includes/database.mysql.inc on line 172.
• user warning: Duplicate entry '1-127' for key 1 query: INSERT INTO drupal_live_term_node (nid, tid) VALUES (127, 1) in /home/13/fgcuried/drupal/includes/database.mysql.inc on line 172.
• user warning: Duplicate entry '1-127' for key 1 query: INSERT INTO drupal_live_term_node (nid, tid) VALUES (127, 1) in /home/13/fgcuried/drupal/includes/database.mysql.inc on line 172.

errors which I hadn´t got before (and I am sure I only disabled and then reanabled the wrapper thingies).

Now I investigated and installed the 5.x-1.1 release wrapper and patched it and got the same duplicate errors. Then I installed the same 5.x-1.1 release wrapper without the patches. And now it works. I have to reedit every node but in general it works great :)
All my problems I had before seem to be gone too (taxonomy access f.e.)
Now I have the 5.x-1.x dev version running with the 5.x - 1.1 release wrapper is that a problem? (oh and I need the dev version otherwise pathauto doesn´t work at all)

Also should I clear the term_node table before reediting everything just in case?

Just to clarify: for me the patches above made it NOT work (or broke it) and I have used them from a fresh install right from the beginning of building my site.....

The patch was for 1.26.2.2.2, bundled with category 5.x-1.1
The dev version have modifications.

so we can settle that the dev version as it is introduces the tid=1 bug again?

I need the dev version as the release has other bugs (pathauto and some menu stuff mainly)… anything that could cause an issue with running the dev version with the release 1.1 wrapper?

ok more info - using the wrapper of 5.x - 1.1 release with the rest of 5.x 1.x dev is actually working quite fine UNTIL you enable freetagging for a container.

then I get the following error...

user warning: Duplicate entry '0-173' for key 1 query: INSERT INTO drupal_live_term_node (nid, tid) VALUES (173, 0) in /home/13/fgcuried/drupal/includes/database.mysql.inc on line 172.
user warning: Duplicate entry '0-173' for key 1 query: INSERT INTO drupal_live_term_node (nid, tid) VALUES (173, 0) in /home/13/fgcuried/drupal/includes/database.mysql.inc on line 172.
user warning: Duplicate entry '0-173' for key 1 query: INSERT INTO drupal_live_term_node (nid, tid) VALUES (173, 0) in /home/13/fgcuried/drupal/includes/database.mysql.inc on line 172.

(for three freetags)

Any ideas how to fix that last little puzzle for a working category install?

This is the code that deals with freetagging:

          // See if the term exists in the chosen vocabulary
          // and return the tid, otherwise, add a new record.
          $possibilities = taxonomy_get_term_by_name($typed_term);
          $typed_term_tid = NULL; // tid match if any.
          foreach ($possibilities as $possibility) {
            if ($possibility->vid == $vid) {
              $typed_term_tid = $possibility->tid;
            }
          }

          if (!$typed_term_tid) {
            $edit = array('vid' => $vid, 'name' => $typed_term);
            $status = taxonomy_save_term($edit, TRUE);
            $typed_term_tid = $edit['tid'];
          }

          db_query('INSERT INTO {term_node} (nid, tid) VALUES (%d, %d)', $nid, $typed_term_tid);

It calls taxonomy_save_term() which is used to get $edit['tid']

investigating for 2 days now :(

What I have found so far is that it seems to be a problem of timing. the nid,tid sql call is called before the insert taxonomy is called. that makes it a problem because for some reason at that point the $edit['tid'] is still empty. After the "insert" case in the taxonomy_nodeapi function is invoked the $edit variable has the tid that we needed earlier... I am not good enough to figure out how to fix that... any more pointers I can look at?

I have debug error output to see the flow it takes...
the "edit['tid']2:" is thrown out at the end of taxonomy_save_term() and displays the value $edit['tid'] has (notice the one call before with an empty value)
the "curr_tid2: status: 1" is called just before the db_query in the freetagging code above- curr_tid display the $edit['tid'] status the returned $status value from the taxonomy_save_term function call.
the "insert" is thrown just one line after the taxonomy_save_term is called inside the taxonomy_nodeapi "insert" case.
-----------------------------------------------------------------------------

edit['tid']2:
curr_tid2: status: 1
curr_tid2: status: 1
user warning: Duplicate entry '0-287' for key 1 query: INSERT INTO drupal_live_term_node (nid, tid) VALUES (287, 0) in /home/13/fgcuried/drupal/includes/database.mysql.inc on line 172.
curr_tid2: status: 1
user warning: Duplicate entry '0-287' for key 1 query: INSERT INTO drupal_live_term_node (nid, tid) VALUES (287, 0) in /home/13/fgcuried/drupal/includes/database.mysql.inc on line 172.
edit['tid']2: 288
insert
edit['tid']2: 289
insert
edit['tid']2: 290
insert

-----------------------------------------------------------------------------

Ui it seems I found a way to fix it... but I am not sure what the fix actually does - if someone can shed a light on it and if its a viable solution I would greatly appreciate it.

in line 504 the taxonomy_node_save function starts - this is the function that holds the code from inforetos comment #53:

function taxonomy_node_save($nid, $terms, $node = NULL) {
.
.
.
}

in the end of this function you find the call to the category_node_save function

category_node_save($node, TRUE);

Well I moved this all the way up to the first line of the taxonomy_node_save function and magically it works. Looking at the code of both I think there is a "check" missing in the taxonony_node_save to see if we want to execute the "old" standard taxonomy code or the "new" category code - both seem similar with the category code of course much better working... the new version of the taxonomy_node_save looks like this:

function taxonomy_node_save($nid, $terms, $node = NULL) {

  category_node_save($node, TRUE);


  if (empty($node)) {
    $node = node_load($nid);
  }

  if (variable_get('taxonomy_maintain_db', 1)) {
    // BEGIN legacy taxonomy code that keeps the old DB tables up-to-date
    taxonomy_node_delete($nid);

    // Free tagging vocabularies do not send their tids in the form,
    // so we'll detect them here and process them independently.
    if (isset($terms['tags'])) {
      $typed_input = $terms['tags'];
      unset($terms['tags']);

      foreach ($typed_input as $vid => $vid_value) {
        // This regexp allows the following types of user input:
        // this, "somecmpany, llc", "and ""this"" w,o.rks", foo bar
        $regexp = '%(?:^|,\ *)("(

[^"]*)(?>""[^"]* )*"|(?: [^",]*))%x';
preg_match_all($regexp, $vid_value, $matches);
$typed_terms = $matches[1];

foreach ($typed_terms as $typed_term) {
// If a user has escaped a term (to demonstrate that it is a group,
// or includes a comma or quote character), we remove the escape
// formatting so to save the term into the DB as the user intends.
$typed_term = str_replace('""', '"', preg_replace('/^"(.*)"$/', '\1', $typed_term));
$typed_term = trim($typed_term);
if ($typed_term == "") { continue; }

// See if the term exists in the chosen vocabulary
// and return the tid, otherwise, add a new record.
$possibilities = taxonomy_get_term_by_name($typed_term);
$typed_term_tid = NULL; // tid match if any.
foreach ($possibilities as $possibility) {
if ($possibility->vid == $vid) {
$typed_term_tid = $possibility->tid;
}
}

if (!$typed_term_tid) {
$edit = array('vid' => $vid, 'name' => $typed_term);
$status = taxonomy_save_term($edit, TRUE);
$typed_term_tid = $edit['tid'];
}

db_query('INSERT INTO {term_node} (nid, tid) VALUES (%d, %d)', $nid, $typed_term_tid);
}
}
}
if (isset($terms['legacy'])) {
foreach ($terms['legacy'] as $tid) {
if (!empty($tid)) {
db_query('INSERT INTO {term_node} (nid, tid) VALUES (%d, %d)', $tid, $nid);
}
}
}
if (is_array($terms)) {
foreach ($terms as $key => $term) {
if ($key != 'tags' && $key != 'legacy') {
if (is_array($term)) {
foreach ($term as $tid) {
if (!empty($tid)) {
db_query('INSERT INTO {term_node} (nid, tid) VALUES (%d, %d)', $nid, $tid);
}
}
}
else if (isset($term->tid)) {
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);
}
}
}
}
// END legacy taxonomy code
}

}

?>

I might be full of it - as said I am no php pro and this whole topic is a bit too complex for me to understand but it works (dev install release wrapper with the above "patch") for now. I would really really love some feedback on it...

function taxonomy_node_save($nid, $terms, $node = NULL) {

  category_node_save($node, TRUE);


  if (empty($node)) {
    $node = node_load($nid);
  }

do more debugging. better get those $terms to work before saving categories.
remember the those two functions are basically saving two copies of the terms/categories:
terms on taxonomy_node_save and categories on category_node_save, and the numbers might not match.

the thing is, if categories are saved first, the values in $terms must not be overwritten before saving the taxonomy terms.
that gets rid of the 1s, but might not save the right values if taxonomy tids are different than the category cids.
in a new install, chances are the numbers match, but the fix will break once they differ for any reason.

apart of that, category_node_save needs $node, so the node_load() must come first.

i don't use free tags, so can't test right away, so please have another look at taxonomy_save_term() to see where exactly $edit['tid'] loses the right value.

well I did look to catch the tid somewhere taxonomy_save_term() but its never there when its needed - thing is that somehow taxonomy_save_term() gets called twice - the first time it would need the tid for saving

db_query('INSERT INTO {term_node} (nid, tid) VALUES (%d, %d)', $nid, $typed_term_tid);

but there it is not available -EVER- I really put error readouts in almost every line of the function and could never get a tid or anything that would get it into the $edit['tid']

the second time taxonomy_save_term() is called the tid is available and everything works great but the db_query is not called again. I really understand only half of what I am seeing so maybe I am missing something obvious (I am a designer not a programmer so since using drupal I have been getting pretty alright with PHP but don´t understand the grand concepts yet).

As far as I have tested everything works great but your explanation makes sense that it might not work at one point. I don´t know what to do :(

oh nooooooooooooooo
why all tids in node_term table are 1?
even after aply these patchs!

inforeto: I have been running my "patch" now for quite some time and I have not come to any issue but I am afraid that at one point this hack is biting me. You wrote:

/// that gets rid of the 1s, but might not save the right values if taxonomy tids are different than the category cids. ///

May I ask under what circumstances would the tids be different then the cids?

This is such a critical bug and it would be really nice to fix this once and for all for the 5.x category module. can´t some of the grand category module gods lend a helping hand here pretty pretty please as this affects each and every one who uses the category module and none of the suggested patches work with a category version that is also working with tokens correctly (so pathauto and all the other tokenized modules). A final cat module 5.x release that does work with tokenz and does not have the tid bug would be really really helpfull.

Theoretically all should be fine, but should be checked.

Problems usually arise with the existing terms upon installation.
See http://category.greenash.net.au/installation

ah that sounds promising :) since I had category from day one and still testing the site without much content it should be all well. should I put this in a patch for others (not that I know how to do a patch never done it before ;) or are my instructions above clear for people wanting to work with this?

Yeah, but post new patches on a separate issue please.

The patch on this thread is still under review.

$node-taxonomy is empty after applying the patch in #19. It may also be empty before, I haven't checked.

Either way, that's what is causing the problem with simplenews.

A workaround for simplenews is to check for $node-category and use it instead of $node-taxonomy if it's present. Patch for simplenews workaround attached for reference.

@thomas:
Have you tried resubmitting the categories to see if it saves the value after patching?
And, also, check what version of the wrapper you had, because patch on #19 was for version 1.26.2.2.2

I didn't try resubmitting the category to see if it saves the value after patching, so that may be what has to happen. I checked the version before applying the patch and it was the correct version.

it works perfectly after i uninstall and reinstall the wrapper.

Changes in drupal from 5.7 to 5.10 affected the wrapper.
The patched wrapper i was using in 5.7 no longer works after upgrading.

Edit:
revision 1.26.2.4 seems to work. I was using revision 1.26.2.2.