Make WordPress Core

Opened 6 years ago

Closed 5 years ago

#12253 closed defect (bug) (wontfix)

MU global taxonomy can be disrupted when blog db tables are copied directly in

Reported by: donncha Owned by:
Milestone: Priority: normal
Severity: normal Version: 2.9.2
Component: Multisite Keywords:
Focuses: Cc:


If you've used MU much you'll probably have noticed that term_ids increase whenever you edit a category or tag. There's actually a bug #12206 about it but I closed it earlier today. This is how we maintain global tags/categories in MU. Whenever one is changed you have to assume some other blog may have used it already so you have to give the changed tag/cat a new term_id.

That makes it easy to maintain the correct term_id for the same tag or category across blogs.

Well, that all goes out the window when you copy a blog into a wpmu site using phpmyadmin and not through the WP importer.

It's not normally much of a problem except if you want to do something with the global tags like use the sitewide tags plugin. The problem showed there with numeric categories instead of the correct category showing on the tags table.

I received a patch for fixing the plugin that checked the cat_ID before inserting the post into the tags blog. (props Nasim Mansurov) Upon investigation I discovered he had copied his first blog's db tables directly into his MU site.

MU really should handle that more gracefully. It should do a once off check of the categories and tags, comparing them against the data in the sitecategories table and adjust the term_ids in the local blog's taxonomy.

Change History (11)

comment:1 @donncha6 years ago

For 2.9.2 I'm going to add a wpmu-blogs.php action on the blog listing that will bring the site admin to a fixing page. Will add a patch here later.

comment:2 @wpmuguru6 years ago

In 3.0 the terms from the original WP blog are inserted into the sitecategories table. That will eliminate the issue where someone does a SQL import of the main blog.

For subblogs imported via SQL, we can probably simulate that by changing the terms (using SQL) in a blog or two to create inconsistencies, conflicts, etc.

comment:3 @wpmuguru6 years ago

  • Milestone changed from Unassigned to 3.0

Setting this to 3.0 so it shows up in the 3.0 list.

comment:4 @donncha6 years ago

I'm going to add a "Global Terms" site admin page. That will be able to do a similar job to the upgrade site page that jumps through each blog on a site fixing the terms on each. It should also have a form to enter a blog_id to fix one individual blog.

I think that's better than cluttering up wpmu-blogs with a blogaction that will rarely be required.

comment:5 @wpmuguru6 years ago

I like that idea.

comment:6 @donncha6 years ago

Just checked in http://trac.mu.wordpress.org/changeset/2076 to MU 2.9 which is a barebones fixer page but it works well on the examples I threw at it.

I see WP 3.0 is feature frozen now so this might get a spit and polish before the next minor release perhaps, but I'll add it to MU 2.9.2 if I can get people to test it.

comment:7 @donncha6 years ago

The page now renames term names if the slug is different as this is a limitation of MU.

comment:8 @Denis-de-Bernardy6 years ago

One' thing I'm simply not getting is, how hard is it to keep a term's ID unchanged when you merely click save... I can understand when it's name or url changes, but for the rest? :-|

comment:9 @wpmuguru6 years ago

We could make this into a plugin as well. That might give us an indicator of how many people would use it.

comment:11 @ryan5 years ago

  • Milestone 3.0 deleted
  • Resolution set to wontfix
  • Status changed from new to closed

I think we decided on this as a plugin back when we were working on the MU merge.

Note: See TracTickets for help on using tickets.