Opened 3 years ago

Closed 3 years ago

#13391 closed defect (bug) (wontfix)

wpmu-terms.php fails if there are more terms in the blog's terms table than there are in wp_sitecategories

Reported by: mkanat Owned by: donncha
Priority: normal Milestone: MU 2.9.x
Component: Administration Version: 2.9.2
Severity: normal Keywords: close
Cc:

Description

fix_blog_terms in wpmu-terms does this:

$maxterm = $wpdb->get_var( "SELECT max(cat_ID) FROM {$wpdb->sitecategories}" )

Then later it does this:

$term_id = $row->term_id + mt_rand( $maxterm+100, $maxterm+4000 );

However, if there are thousands of terms in the blog's terms table, and only a few terms in wp_sitecategories, this will result in term_ids that conflict with other term_ids in $wpdb->terms.

The simple (though probably not ideal) solution is to change the $maxterm line to:

$maxterm = max($wpdb->get_var( "SELECT max(cat_ID) FROM {$wpdb->sitecategories}" ),

$wpdb->get_var( "SELECT max(cat_ID) FROM {$wpdb->terms}" ) );

Attachments (1)

terms.diff (1.0 KB) - added by mkanat 3 years ago.
Patch, v1

Download all attachments as: .zip

Change History (6)

By the way, the reason this bug is marked as "major" severity is that running wpmu-terms.php on a blog with this problem causes the terms table to basically be fubar'ed beyond recovery.

  • Keywords close added
  • Milestone changed from Unassigned to MU 2.9.x
  • Owner set to donncha
  • Severity changed from major to normal
  • Status changed from new to assigned

wpmu-terms will not be in WordPress 3.0.

  • Version changed from 3.0 to 2.9.2

mkanat3 years ago

Patch, v1

I discovered that my code above was slightly wrong. I have a working version now with the attached patch.

  • Resolution set to wontfix
  • Status changed from assigned to closed

Closing as wontfix due to this page not appearing in 3.0. Leaving the milestone attached however for record keeping purposes.

Note: See TracTickets for help on using tickets.