[wp-trac] [WordPress Trac] #33864: Cannot add accented tag if non-accented look-alike exists (eg. szel, szél)

[WordPress Trac]

#33864: Cannot add accented tag if non-accented look-alike exists (eg. szel, szél)
------------------------------------+-----------------------
 Reporter:  geza.miklo              |       Owner:
     Type:  defect (bug)            |      Status:  reopened
 Priority:  normal                  |   Milestone:  4.4
Component:  Taxonomy                |     Version:  4.3
 Severity:  normal                  |  Resolution:
 Keywords:  has-patch dev-feedback  |     Focuses:
------------------------------------+-----------------------

Comment (by geza.miklo):

 You are absolutely right on being case-sensitive this way. That's not good
 too.

 I see 2 options:
 * add BINARY LOWER($field) = LOWER(%s)
 * check equality in PHP and use get_results as yout suggested

 Replying to [comment:5 boonebgorges]:
 > Switching to `BINARY` means, among other things, that term matches will
 be case-sensitive. This is a change from current behavior.
 >
 > Can I ask for a couple things -
 >
 > * Let's do a review of where `get_term_by()` is used in core. Are there
 places in the core interface where we depend on the case-insensitivity of
 a `get_term_by()` check?
 > * If we have a problem like this in `get_term_by()`, it's certain that
 the same problem arises elsewhere. At a very quick glance, `term_exists()`
 and `get_terms()` (with 'name') will be affected. Likewise with Posts. We
 should have a single solution for all of these.
 > * It looks like casting the field to `BINARY` means that we lose the use
 of the index. The comments on https://dev.mysql.com/doc/refman/5.0/en
 /charset-binary-op.html suggest that we should cast the comparison value
 instead: `$field = BINARY %s`. This needs testing.
 > * Another (maybe lame) idea is to do the byte comparison in PHP, where
 we can more easily control for things like case. So, maybe instead of
 `get_row()` we `get_results()`, and then loop through to find the one that
 matches the field value exactly.
 >
 > @pento or someone else with more MySQL expertise than me: what other
 side effects will we risk by doing a `BINARY` comparison here?

--
Ticket URL: <https://core.trac.wordpress.org/ticket/33864#comment:6>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform