The only time this should occur is if you edit the slugs. Everything else should stay put and not cause duplication. Same thing for taxonomies.
It’s also why I have this note in the edit tab:
“DO NOT EDIT the post type slug unless also planning to migrate posts. Changing the slug registers a new post type entry.”
For the technical explanation, we use the post type and taxonomy slugs for indexes in the arrays we construct and save. It’s much more stable than using indexed arrays that are just numerals. However, that caused unintended duplicates if someone renamed the slug, as it no longer matched the previous entry, and instead added a new one.
That said, I consider it a happy accidental feature at this point, because it allows for decently quick duplication in cases where someone wants or needs many post types or taxonomies with similar settings. They can just rename the slug and let the duplication occur.
I see.
Well, now I have ticked to migrate posts.
And it seemed to work out better.
So now there should be no trace left of the original CPT/slug stuff?
correct, that will do a query for all the posts/taxonomy terms associated with the original slug, and update them to point to the new slug. It’ll then remove the original from the values to be saved to our options.
You should be good to go with those migrate checkboxes checked when appropriate.
Marked as resolved – not ideal, but not bug.
Thanks for the replies.
Let us know if you have any other questions.