[wp-trac] [WordPress Trac] #39768: Incorrect image returned with attachment_url_to_postid()

[WordPress Trac]

#39768: Incorrect image returned with attachment_url_to_postid()
--------------------------+---------------------
 Reporter:  ben.greeley   |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  5.4
Component:  Media         |     Version:  4.7.2
 Severity:  normal        |  Resolution:
 Keywords:  has-patch     |     Focuses:
--------------------------+---------------------
Changes (by SergeyBiryukov):

 * keywords:   => has-patch


Comment:

 Replying to [comment:8 vsamoletov]:
 > I'm sure you saw this https://stackoverflow.com/a/56283818, but just in
 case.

 I missed that, thanks for bringing it to my attention.

 [attachment:39768.diff] uses the `BINARY` approach.

 It looks like that could introduce some unintended regressions when
 dealing with accented characters, or if the column charset doesn't match
 the session charset, e.g. `latin1` vs. `utf8mb4`.

 Using `CONVERT()` appears to be a better option. While `utf8mb4` should be
 available on any modern install, that may not always be the case, so we
 have to check for it specifically, and fall back to the current query
 otherwise. This option also has some performance difference from the
 queries above in my testing:
 {{{
 SELECT post_id FROM wp_postmeta WHERE meta_key = '_wp_attached_file' AND
 meta_value = CONVERT( %s USING utf8mb4 ) COLLATE utf8mb4_bin
 Query took 0.0315 seconds
 }}}

 [attachment:39768.2.diff] uses the `CONVERT()` approach.

 Given that the main issue of `wp_unique_filename()` being case-sensitive
 is fixed as of 5.3.1, I'm now a bit less convinced
 `attachment_url_to_postid()` needs this change. That said, if
 [attachment:39768.2.diff] looks sensible, I guess we could give it a go.

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