WordPress.org

1. Alexander Gieg
   Member
   Posted 1 year ago #
   

   I've discovered an additional bug. It happens so:

   a) If fuzzy search is set to only happen when no exact match is found; and that exact term is indeed indexed, but is present only in non-published posts; then when one searches for that term, this results in a "nothing found" page, even though a fuzzy search would have resulted in posts found due to the term being part of another, big term.

   For example: if I have a published post with the word "shirts", and an unpublished post with the word "shirt", then searching for "shirt" will result in "nothing found", even though one'd expect the fuzzy search to trigger and show the post containing the word "shirts".

   b) However, if the fuzzy method is changed to "always", that search for "shirt" works, and the post with the word "shirts" appear.

   This means, I guess, that the place in the code that searches for exact terms isn't checking whether those posts it found are "displayable" before concluding a fuzzy search isn't needed, because if it where, it'd know that none of those posts it found are visible, hence that the search for the exact term failed, and that's necessary to trigger a fuzzy search.

   I've tried to find where in the code this is happening to see if it was something easy to fix, but couldn't find it. So, I went to the workaround of setting fuzzy searches to "always".

   I'll try again next week, unless the fix comes before that. It's a fun exercise. :)

2. Mikko Saari
   Member
   Plugin Author
   Posted 12 months ago #
   

   Thanks, I'll add this to my to-do list. This is going to be tricky to fix, though... Well, I do have the AND to OR fallback implemented correctly, so I suppose this can be done in a similar way as well.

3. Alexander Gieg
   Member
   Posted 12 months ago #
   

   Nice! Thanks!

   By the way, here's an idea: once this is fixed you could expand it into an additional feature, I'll call it "Flexible Search". It might be exclusive to the Premium version, or perhaps with a fixed rule set in Free and the possibility of customizing it in Premium. It'd work somewhat along these lines: first show all "exact AND" matches, then append all the (additional) "fuzzy AND" matches, then append all the (additional) "exact OR" matches, then finally append all the (additional) "fuzzy OR" matches. As this would be computationally expensive on large sites, an additional difference between the Free and Premium versions (if this were to be available in Free) might be that in Free it would all be done at once, while in Premium the next "search block" would only be triggered when the user opened the last page of the current block.

   For smaller sites it'd offer a wider range of results, while for larger, paying ones it'd be a nice way to make search both lighter and deeper.

   What do you think?

4. Mikko Saari
   Member
   Plugin Author
   Posted 12 months ago #
   

   Sounds good, but also fairly complicated.

5. Alexander Gieg
   Member
   Posted 12 months ago #
   

   Maybe an easy(ier) way would be to store the first set of results in a transient identifier, perhaps named after a salted SHA1 of the query string:

   $query_sha1 = sha1( 'relevanssi' . $query_string );
   set_transient( $query_sha1, $hits_array_with_metadata, 60*60 );

   Then use the transient to load results on pages 2+:

   $hits_array_with_metadata = get_transient( $query_sha1 );
   if ( $hits_array_with_metadata['metadata']['something'] ) . . .

   Then later use an array_intersect/diff/merge combo to deal with additional blocks:

   if ( $no_more_results && $is_flexible_search && $hits_array_with_metadata['metadata']['something_else'] ) {
   	$new_hits = search_with_new_parameters( . . . );
   	$hits_to_show = array_diff( $new_hits, array_intersect( $new_hits, $hits_array_with_metadata['hits'] ) );
   	. . .
   	$hits_array_with_metadata['hits'] = array_merge( $hits_array_with_metadata['hits'], $new_hits );
   	$hits_array_with_metadata['metadata'] = . . . ;
   	set_transient( $query_sha1, $hits_array_with_metadata, 60*60 );
   	. . .
   }

   Although this is clearly more complex than what I'm used with my small edits here and there, and I might be underestimating the effort quite a bit. :)

6. Mikko Saari
   Member
   Plugin Author
   Posted 11 months ago #
   

   For your information: I figured out a simple way to fix this problem. I'm not yet ready to tackle your Flexible Search idea, but moving the post_ok search earlier in the process wasn't a big problem.

   I'm working on Premium 1.8 first, then next is free 2.9.15 which will include this fix.

7. Alexander Gieg
   Member
   Posted 11 months ago #
   

   Nice, I'm looking forward for it. Thanks!

Topic Closed

This topic has been closed to new replies.