#6035 closed defect (bug) (worksforme)
Category to Tag Converter leaves posts without categories
Reported by: |
|
Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | major | Version: | 3.0 |
Component: | Import | Keywords: | |
Focuses: | Cc: |
Description
The category to tag convertor lets you convert the default category - only it fails because the posts still end up categorised within that category even if they are in other categories
Attachments (2)
Change History (18)
#2
@
14 years ago
- Keywords has-patch needs-testing added; needs-patch removed
- Version changed from 2.5 to 2.7
My patch does a couple of things:
- prevents the default category from being selected for conversion
- sets the default category on all posts that have no categories after the conversion
There must be a better way to get all post IDs than to select them straight from the db, but I couldn't get get_posts to work with numberposts=-1 as the codex indicated.
#3
@
14 years ago
- Summary changed from Category to Tag Converter fails to convert the default category to Category to Tag Converter leaves posts without categories
#5
@
13 years ago
- Component changed from Administration to Import
- Owner anonymous deleted
- Severity changed from normal to major
#6
@
13 years ago
set_default_category() will create a lot of expensive taxonomy queries. We might have to lose that part.
#7
@
13 years ago
That part is kind of essential. Otherwise there's no way to make sure each post comes out of the cat2tag conversion with at least one category attached. You could have a post with several categories, none of them the default one, and convert all those categories to tags, leaving the post bereft. However, I'm all for a less expensive way of doing it.
Would it be better to do something like:
SELECT wp_term_relationships.object_id FROM wp_term_relationships, wp_term_taxonomy WHERE taxonomy = 'category' AND wp_term_taxonomy.term_taxonomy_id = wp_term_relationships.term_taxonomy_id
to get all the post IDs that have categories, and then set the default category on all the other ones?
#8
follow-up:
↓ 9
@
13 years ago
please give the attached patch a shot. I haven't run it at all, but it should work.
in particular, try:
- when the default term_id and term_taxonomy_id are the same and not the same
- whether leaving the order field empty is fine (it should be; else make it default to 1)
- whether a few plugins that would normally interact with category updates still work as expected. I believe I left all of the hooks in there, but you never know...
#9
in reply to:
↑ 8
@
13 years ago
Replying to Denis-de-Bernardy:
- when the default term_id and term_taxonomy_id are the same and not the same
(this is because I'm only 99% certain of the semantics in the hooks; it's not entirely clear whether/when term_ids and term_taxonomy_ids should be passed.)
#12
@
13 years ago
- Version changed from 2.7 to 2.8.4
Sorry I disappeared for a while there. Your patch is missing a semicolon on the last echo in the set_default_category function, and a few line numbers have shifted around in the latest release. Otherwise it works beautifully in my test scenarios.
I'm not sure under what circumstances the default term_id and term_taxonomy_id wouldn't be the same...?
The problem is more generic than this.
In theory, a post must have a category associated with it. A lot of code in WP makes that assumption.
If you use the cat2tag converter, it is possible to convert all of a posts categories into tags, leaving a post without a category. This results in some odd behavior on the Manage Posts screen, among other places.
A check needs to be put into place to adjust posts after tag conversion, such that all the posts that now have "no" categories get put into the default category.