Project:Taxonomy Lineage
Version:6.x-1.x-dev
Component:Code
Category:bug report
Priority:normal
Assigned:xjm
Status:closed (fixed)

Issue Summary

The regular expression for splitting the lineage string chops off numbers at the beginning of term names. I've attached a patch to fix this.

AttachmentSize
lineage_numeric_term.patch530 bytes

Comments

#1

Status:needs review» needs work

I believe this patch will leave a number fragment at the beginning of the term name for vocabularies with weights higher than 99. I'm not sure how best to solve that, though.

Edit: For reference, here's how the weights get added:

<?php
function lineage_string($term) {
 
// add 10 to the weight cause negative numbers don't sort the same
  // in strong form as they do numerically.
 
return sprintf("%02d", $term->weight + 10) . $term->name . "\n";
}
?>

I'm also not sure if the "add 10" bit is relevant in D6 (by default, weights are positive from 0 and up). Maybe lineage_string and the handler should both check the max number of digits in the weight field (something like and then use that to determine how many digits to output/trim.

Edit: something like

<?php
$r
= db_query("SELECT MAX(`weight`) FROM {term_data} WHERE `vid`='%d'",$term->vid);
$max_weight = db_result($r);

$digits = floor(log($max_weight+1)) + 1;
return
sprintf("%0".$digits."d",$term->weight) . $term->name . "\n";
?>

I don't think negative weights are possible, but if if they were, one could add the absolute value of the minimum weight to all the weights whenever it was less than zero. Edit: I tested this and you can set a term's weight to be negative without taxonomy.module complaining or changing it.

This leaves the issue that the lineages would be wrong when term 100 or 1000, etc., was added, so all lineages would need to be updated at that point.

#2

Title:"Taxonomy: Hierarchy" Field: Terms names beginning with numbers don't work correctly» Fix weight string handling for D6
Version:6.x-1.0» 6.x-1.x-dev
Assigned to:Anonymous» xjm

I notice that the weights sort incorrectly over 100 in D6 even without the patch, so I'm going to broaden the scope of your issue a little to include the base problem. A complete patch will:

  1. Fix lineage_string to work in the D6 weighting system,
  2. Trigger a full term update when a term weight jumps to the next power of 10, and
  3. Fix the handler to reflect these changes, paying attention to the # of digits rather than stripping all numbers from the beginning of term names

Note: currently, {term_data} only handles weights from -128 to 127, but this can be modified with contrib and may be fixed in the future, so I'm just going to make the patch ask the database how many digits to use.

I'll try to come up with a reasonable patch.

#3

Status:needs work» needs review

The attached patch resolves all of the above:

  • It works with any arbitrary range of weights, in keeping with the D6 taxonomy weighting system.
  • It updates all lineages whenever the range of weights changes to ensure proper sorting.
  • It introduces a hyphen between the weight and term name in the lineage string to prevent numbers getting peeled off in the views handler.
  • It fixes the views handler to use the new weight string format.

Note #1

This patch depends on #613372: Override processing at admin/content/taxonomy to trigger lineage_update_all(). Apply the latest patch in that issue, then this one. Direct link to that patch: http://drupal.org/files/issues/lineage_6_1-613372-3.patch

Note #2

Since the patch includes more than one file it is rolled at the directory level. So, either,

  • apply the patch from your modules/ directory, or
  • apply the patch from within the lineage directory using the -p option:
    .../drupal/sites/all/modules/lineage $ patch -p1 < lineage_6_1_507472-3.patch

Note #3

To get the new format of weights to be generated for your taxonomy, simply disable and re-enable the module after applying the patch.

AttachmentSize
lineage_6_1_507472-3.patch 4.45 KB

#4

Status:needs review» fixed

Thanks for the patches xjm.

Committed.

#5

Status:fixed» closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.