[wp-trac] [WordPress Trac] #7394: Search: order results by relevance

WordPress Trac noreply at wordpress.org
Thu Sep 26 18:42:04 UTC 2013

#7394: Search: order results by relevance
 Reporter:  markjaquith       |       Owner:
     Type:  task (blessed)    |      Status:  assigned
 Priority:  normal            |   Milestone:  3.7
Component:  General           |     Version:  2.6
 Severity:  normal            |  Resolution:
 Keywords:  has-patch commit  |
Changes (by nacin):

 * keywords:  has-patch needs-testing 3.7-early needs-refresh => has-patch


 Okay, I've updated this with [attachment:7394.9.diff].

 When writing documentation for new and existing filters, I struggled to
 explain what the posts_search_orderby_on did. It allowed you to filter
 `array( 'post_title', 'post_content' )`. But, there were a few issues:
  * You couldn't add a new field to search, like post_excerpt or post_name.
  * You couldn't rearrange them by putting post_content first.
  * You could only remove one, or the other, or both.

 It seems like if we're going to do relevance searches, we should use both
 post_title and post_content, as we do now. If we want to add better
 support for changing the searched fields, we can do that, but I don't
 think it should be tied to this, and adding a filter that is less than
 useful is not ideal.

 The primary purpose of the filter was to avoid the relevance-based
 ordering all together by returning an empty array. But we already have the
 posts_search_orderby filter which can be used for that.

 I've chosen to not make our relevance-based ordering directly filterable.
 posts_search_orderby is instead a slightly more generic filter that always
 runs when a search is in play — even when orderby is set to something else
 and our relevance-based ORDER BY is ignored. We now have four new
 protected methods:

  * parse_search(), which is where the 'posts_search' filter ended up.
 Modeled after parse_tax_query(), etc.
  * parse_search_terms(), no filter, used inside parse_search()
  * get_search_stopwords(), with a generic filter on stopwords, used inside
  * parse_search_order(), greatly simplified and without a filter inside of
 it (see note above)

 I've also switched the order of esc_sql() and like_escape(). I'm pretty
 sure (well, very sure) calling like_escape() before esc_sql() just causes
 the escape characters to themselves be escaped, thus causing the wildcards
 to work again. Obviously, not ideal, and core has this problem all over —
 I figured we can just fix it here for now.

 Feedback welcome. Planning to commit this today for Beta 1 tonight.

Ticket URL: <http://core.trac.wordpress.org/ticket/7394#comment:71>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software

More information about the wp-trac mailing list