Opened 15 years ago
Closed 15 years ago
#12253 closed defect (bug) (wontfix)
MU global taxonomy can be disrupted when blog db tables are copied directly in
Reported by: |
|
Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | 2.9.2 |
Component: | Multisite | Keywords: | |
Focuses: | Cc: |
Description
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)
#2
@
15 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.
#3
@
15 years ago
- Milestone changed from Unassigned to 3.0
Setting this to 3.0 so it shows up in the 3.0 list.
#4
@
15 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.
#6
@
15 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.
#7
@
15 years ago
The page now renames term names if the slug is different as this is a limitation of MU.
#8
@
15 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? :-|
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.