[wp-trac] [WordPress Trac] #7394: Search: order results by relevance
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
* 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