[wp-trac] [WordPress Trac] #39358: Media search speed has been dramatically reduced

[WordPress Trac]

#39358: Media search speed has been dramatically reduced
--------------------------+------------------------------
 Reporter:  merts         |       Owner:  joemcgill
     Type:  defect (bug)  |      Status:  reviewing
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  Media         |     Version:  4.7
 Severity:  normal        |  Resolution:
 Keywords:                |     Focuses:  performance
--------------------------+------------------------------

Comment (by joemcgill):

 @dd32 Thanks for the detailed and thoughtful feedback here. You have
 rightly (in my view) identified the main challenge presented by #22744,
 which is how to balance the desire to improve the user experience for
 searching the media library with the fact that doing so requires non-
 optimal queries of postmeta.

 Before discussing the merits/downsides of each option you've proposed, I
 think it's helpful to keep in mind a specific use case that the change
 tries to address. Assume someone uploads a file with a name like "large-
 monarch.jpg" but then renames the title of the attachment to something
 like "A Butterfly". Later, someone searches for a photo of a monarch in
 the media library but doesn't find the file because WordPress only
 searched the title and content fields. This is a simplified example, but
 imagine a scenario where an organization uses file name conventions as an
 organizational scheme, where the file name maps to the date, photographer,
 job ID, and photo number (i.e. 20161222_jdm_5555_32.jpg). This is a case
 where you may need to search by parts of file names that have no
 relationship to the post title assigned within the library.

 Now, onto the proposals:

 a) If it's agreed that the cost of this change is not worth the
 performance hit, I have no reservations in reverting. However I would
 strongly prefer we explore other options first.

 b) I think that the current implementation (through a filter) allows large
 sites to turn this off if they so choose. That said, I'm more than happy
 to discuss ways the developer UX could be improved (e.g., moving away from
 the filter approach to some other configuration). In fact, we should
 pursue improvement here regardless.

 c) I don't think exact matches are helpful here for reasons illustrated by
 the use case above. Often, it's not that someone knows the exact name of a
 file, but needs to search by partial information included in a file name.
 In my mind, this is the least applicable option.

 d) Storing the information in another way seems like the best option, as
 your example using GUID demonstrates. I was hesitant in using GUID because
 we've not relied on the GUID for file names since #7622 and I assume some
 plugins modify the filename while ignoring the GUID altogether. Perhaps it
 is worth sacrificing those edge cases for the performance benefits? Here
 it's worth noting that there is a request to also make image `alt`
 attributes searchable from the media library, and alt information is
 similarly stored as postmeta. This cannot as easily be searched from our
 current post schema.

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