Terms migration assignation fails when 2 differents post types

[MaximeCulea]

This is an exemple to enlight a missing behaviour or documentation improvement. I have posts with categories that I want to migrate to news with topics.

1. I do a wp cli post edit to migrate the post type from posts to news: for post_id in $(wp post list --post_type="post" --format=ids); do wp post update $post_id --post_type="news"; done;
2. I do a wp term migrate to migrate the terms from categories to topics: for term_id in $(wp term list category --format=ids); do wp term migrate $term_id --from=category --to=topic; done;

It results in not having anymore the news assigned to the topics 😢 Which is kind of normal since it would also require to change the relathionships.

What do you think about this?
Do you think it's a good idea to patch it or just add a warning in the documentation? or even both?

Anyway, I would be glad to contribute to this! 😃

[schlessera]

Yes, I think this should be a supported use case, probably using an additional flag or two.

Do you have a plan of attack for this already?

[MaximeCulea]

As when you want to reassign the terms to the same old posts, I was thinking to add a tag reassign={false|true}, which will check the relationship table. If the treated terms have an "old" relationship in the relationship table, then it preserve the post id in order to assign it to the fresh created term.

I was also wondering about changing the whole behaviour of the term migration, because for now, it is "copying" the terms into the destination taxonomy. It could be maybe easier for preserving metas and relationships, to just change the taxonomy for a term, as we do for the post type. What do you think?

[schlessera]

The above does not really guarantee that the target taxonomy does even apply to the CPT you've migrated the posts to. That's also something that WP-CLI can't really change, as the CPT is registered via code.

I think we're missing a piece of the logic here, and I'm not entirely sure we can properly solve this reliably.

Should the reassignment logic check the taxonomy<=>CPT relationship and throw an error if incorrect?

[MaximeCulea]

You are totally right on one thing, it's not required that the taxonomy belongs to both CPT or the reverse.

Anyhow, we could check that and throw an error.

But that could lead to another issue, it means that the taxonomy should be edited to belong to two CPT, do the export, then fix it forever only with the new CPT? It looks like it's not handy :/