Flat Taxonomy Terms are identified via their slugs and not their names, when saved from the Post Edit Screen

[ArminBraun]

Hi,

Armin here from the WPML development team. I came around this issue when a client complained about some of his flat terms getting automatically translated to the wrong language when he attached them to posts via the post-edit screen.

In actuality though I think this is a bug in WordPress itself and can be reproduced as such:

1. Create a tag named 'foo', but with slug 'bar'.
2. Create a tag named 'bar', but with slug 'foo'.
3. Go to the post edit screen and try to attach the tag 'bar' to a post.
4. After you hit the 'Update', instead of 'bar', 'foo' will be added to the post.

Video demo: ​https://drive.google.com/file/d/0B4tzrh7EeW30QzFucVc4SDlTLWs/view?usp=sharing

I don't think this is right obviously.
I do understand the complication involved here though, since it is possible to have the same flat term name, used by multiple terms in it's taxonomy, just by using different slugs.
Still I think in any case, even without handling the ambiguous case of duplicate term names, it would be the right way to go, to use the term name to identify flat terms added from the post edit screen right?

[Pawel Wawrzyniak]

I can confirm that the problem exists and I was able to reproduce this issue.
Tested with WP 4.0.1.

[boonebgorges]

Confirmed. Here's the trace: edit_post() -> wp_insert_post() parses 'tax_input' and passes to wp_set_post_terms() -> wp_set_object_terms() -> term_exists(). term_exists() will look for a 'slug' match before a 'name' match.

I agree that, in the case of the post.php interface, user expectation would probably be to match 'name' first. But I don't think this should be fixed all the way down the stack, since from a developer's point of view, 'slug' is probably more of a canonical handle for the term. So a possible fix would be to pre-process 'tax_input' in edit_post() and convert names to slugs before calling wp_insert_post().

[ArminBraun]

How about this ? Just filter the names to slugs in the \wp_set_post_terms, where the comma separated tags are handled anyhow ?

[helen]

This has probably been a problem for longer, but getting it off the trunk report for now.

[boonebgorges]

ArminBraun - Your tagslugname.diff​ is along the right lines. In 30615.diff​, I've changed this logic to use the get_terms() function instead of a direct DB query, and I've moved the translation logic to edit_post() rather than wp_set_post_terms(). Regarding this second decision: while it's likely that most people passing a comma-separated list of terms to wp_set_post_terms() are going to unwittingly experience this same bug, it's possible that at least some of them are already accounting for it in their own code. Putting the fix into wp_set_post_terms() could break things for them. By moving the fix into edit_post(), we can be sure that it only affects the Dashboard interface. Do others have thoughts about this?

[boonebgorges]

In 31359:

Parse non-hierarchical tag input into term IDs before sending to wp_insert_post().

When editing a post, non-hierarchical taxonomy terms are sent as the
comma-separated list entered into the tax_input metabox. Passing these
values directly to wp_update_post() meant that they were interpreted as
term slugs rather than term names, causing mismatches when a typed string
matched the slug of one term and the name of a different term. We fix the
problem by preprocessing tax_input data sent from post.php, converting it to
unambiguous term_ids before saving.

Props boonebgorges, ArminBraun.
Fixes #30615.

[boonebgorges]

In 31392:

Don't parse empty 'tax_input' keys in edit_post().

This fixes a bug introduced in [31359] where saving a tax_input that contained
only whitespace would result in a random tag being erroneously added to the
post.

See #30615.