Hierarchy gets lost when updating multiple weights

I tested your changes and it works for me. As far as I can see, this is the part of your patch that deals with this issue:

@@ -240,6 +240,7 @@ function taxonomy_batch_operations_form_
     case 'Save':
       foreach ($form_values[multiedit] as $key => $tid) {
         $term = taxonomy_get_term($key);
+        $parents = taxonomy_get_parents($key);
         unset($tid['check']);
         $tid['tid'] = $term->tid; 
         $tid['name'] = $term->name;
@@ -247,7 +248,7 @@ function taxonomy_batch_operations_form_
         $tid['synonyms'] = $term->synonyms;
         // weight is already set
         $tid['vid'] = $term->vid;
-        $tid['parent'] = $term->parent;
+        $tid['parent'] = array_keys($parents);
 
         taxonomy_save_term($tid);
       }

I say those changes are ready to be committed.

The other changes should have their own issues, IMO. The /content/ fix already has one, but what about the prefixes stuff?

Hello,
I just ran into the same thing last night.
And, I am glad to see it addressed.

I think there might be another issue associated with this. The two calls, getting the term and the parent both go to the DB.
But, the taxonomy is supposed to have been cached. Perhaps, this is overkill, but I changed this code to use a global variable for terms,
and populated the variable in taxonomy_get_tree, which is in core. (So, I guess this is sacred ground.)

    case 'Save': {
      global $g_called_vid;   // set by the third parameter arg(3)
      global $g_terms;         // Set in taxonomy_get_tree
      $tree = taxonomy_get_tree($g_called_vid);     // This might not have to be called.
      foreach ($form_values[multiedit] as $key => $tid) {
        $term = $g_terms[$g_called_vid][$key];
        unset($tid['check']);
        $tid['tid'] = $term->tid; 
        $tid['name'] = $term->name;
        $tid['description'] = $term->description;
        $tid['synonyms'] = $term->synonyms;
        // weight is already set
        $tid['vid'] = $term->vid;
        $tid['parent'] = $term->parent;
        taxonomy_save_term($tid);
      }
      drupal_set_message(t('Updated term weights'));
      break;
    }

Of course there are issues around this. For instance the tree needs to be revised when terms are added. But, cache can be updated in code and the DB updated at some other point, e.g. insert it right away or put it on a revision schedule.

In the last few years, I made an extensive use of a taxonomy which I loaded into a shared area. Even when the server crached the taxonomy was there to attach to when the server came back up. There was a real performance hit in loading the taxonomy, which we had starting with 32K terms and growing when repositories grew, doubling in size and getting bigger, handling phrases, etc. Taxonomy editing was being done offline. Now, I look at things like Oboedit, and am wondering if they can be integrated with Drupal. Drupal has really opened up an area for good tools for managing taxonomies, and some good concepts are emerging. For instance, taxonomy fields is one.

Here is where I need some help with PHP. taxonomy_get_tree puts objects in a static variable for caching. Nice trick. But, is there a way to access the taxonomy data structures outside of the subroutine? I turned them into globals because I really didn't know who to parcel out the arrays. But, perhaps there is a more elegant way.

One other note, although taxonomies can be tangled heirarchies, the routines for displaying them are limited to displaying a strict tree. Really, a tree is what is needed most of the time and it is less confusing to look at. But, it does lose information. Perhaps, an alternative display could be devised (selected by the user perhaps) which displays the entaglemets. And, on this subject, I am not certain if I can set a term to have more than one parent. I tried that, and found that the taxonomy modules simply assigned the last parent selected in the editing forms to be the single parent of the term.

This is one of four patches that should be committed as soon as possible IMHO. In waiting for that to happen, I have made a bundle of these four patches to simplify the patching. See http://drupal.org/node/166037.

I have committed the patch bundle, and released a stable version 1.0.