Category to Tag Converter leaves posts without categories

[westi]

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

[Otto42]

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.

[sillybean]

My patch does a couple of things:

1. prevents the default category from being selected for conversion
2. 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.

[FFEMTcJ]

See also #5714

[ryan]

set_default_category() will create a lot of expensive taxonomy queries. We might have to lose that part.

[sillybean]

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?

[Denis-de-Bernardy]

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...

[Denis-de-Bernardy]

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.)

[Denis-de-Bernardy]

punting to future pending tests.

[sillybean]

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...?

[sillybean]

This appears to have been fixed at some point. The "uncategorized" posts do not appear in 3.0 with my test scenario.