WordPress.org

Make WordPress Core

Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#30615 closed defect (bug) (fixed)

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

Reported by: ArminBraun Owned by: boonebgorges
Milestone: 4.2 Priority: normal
Severity: normal Version: 4.0
Component: Taxonomy Keywords: 2nd-opinion has-patch
Focuses: administration Cc:
PR Number:

Description

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?

Attachments (2)

tagslugname.diff (996 bytes) - added by ArminBraun 5 years ago.
How about this ? Just filter the names to slugs in the \wp_set_post_terms, where the comma separated tags are handled anyhow ?
30615.diff (3.0 KB) - added by boonebgorges 5 years ago.

Download all attachments as: .zip

Change History (11)

#1 @Pawel Wawrzyniak
5 years ago

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

#2 @boonebgorges
5 years ago

  • Keywords 2nd-opinion needs-patch added

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

#3 @SergeyBiryukov
5 years ago

  • Component changed from General to Taxonomy
  • Focuses administration added

#4 @SergeyBiryukov
5 years ago

  • Summary changed from Flat Taxonomy Terms are idenfied via their slugs and not their names, when saved from thePost Edit Screen to Flat Taxonomy Terms are identified via their slugs and not their names, when saved from the Post Edit Screen

@ArminBraun
5 years ago

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

#5 @helen
5 years ago

  • Version changed from trunk to 4.0

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

#6 @boonebgorges
5 years ago

  • Keywords has-patch added; needs-patch removed
  • Milestone changed from Awaiting Review to 4.2

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
5 years ago

This ticket was mentioned in Slack in #core by drew. View the logs.


5 years ago

#8 @boonebgorges
5 years ago

  • Owner set to boonebgorges
  • Resolution set to fixed
  • Status changed from new to closed

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.

#9 @boonebgorges
5 years ago

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.

Note: See TracTickets for help on using tickets.