-
-
Save jchristopher/7fe0117f98318e71fcdcd9de116def62 to your computer and use it in GitHub Desktop.
<?php | |
// Give Products extraordinary weight boost to ensure Products show up first. | |
// @link https://searchwp.com/documentation/knowledge-base/post-type-first-top/ | |
add_filter( 'searchwp\query\mods', function( $mods ) { | |
$post_type = 'product'; // Post type name. | |
$source = \SearchWP\Utils::get_post_type_source_name( $post_type ); | |
$mod = new \SearchWP\Mod( $source ); | |
$mod->relevance( function( $runtime ) use ( $source ) { | |
global $wpdb; | |
return $wpdb->prepare( | |
"IF( {$runtime->get_foreign_alias()}.source = %s, '999999999999', '0' )", | |
$source | |
); | |
} ); | |
$mods[] = $mod; | |
return $mods; | |
} ); |
$existing_weight = ??? // how do we get this?
$extra_juice = 30;
$weight = (string) ($existing_weight + $extra_juice);
return $wpdb->prepare(
"IF( {$runtime->get_foreign_alias()}.source = %s, %s, '0' )",
$source,
$weight
);
No, if the source matches it appends 999999999999
else it appends 0
.
oh, cool - so this already is additive, not a replacement? So if you plugged in a smaller number there it would work the same, but just be less of a sledge hammer? If you wanted to nudge a CPT towards the top, but not force them there?
Correct 👍
Ok, I have this working great now with the code below. However, I'm getting this notice using debug mode. Is this expected because of an unusual use case of wpdb or is there some way I can fix it?
Notice: wpdb::prepare was called incorrectly. Unsupported value type (object). (This message was added in version 4.8.2.) in /wp-includes/functions.php on line 5313
// Give some post types extra weight boost to ensure they show up first.
// @link https://searchwp.com/documentation/knowledge-base/post-type-first-top/
// @link https://gist.github.com/jchristopher/7fe0117f98318e71fcdcd9de116def62
add_filter( 'searchwp\query\mods', 'redpoppy_searchwp_boosts' );
function redpoppy_searchwp_boosts( $mods ) {
// how much to boost each post type
$boosts = array(
'works' => 200,
'recordings' => 50,
'events' => -50,
);
foreach ( $boosts as $post_type => $boost ) {
$source = \SearchWP\Utils::get_post_type_source_name( $post_type );
$mod = new \SearchWP\Mod( $source );
$mod->relevance(
function( $runtime ) use ( $source, $boost ) {
global $wpdb;
return $wpdb->prepare(
"IF( {$runtime->get_foreign_alias()}.source = %s, %s, '0' )",
array(
$source,
$boost,
)
);
}
);
$mods[] = $mod;
}
return $mods;
}
I found that sometimes $mods
is not an array, so to avoid fatal errors, I had to implement this at the start of the function:
if ( ! is_array( $mods ) ) {
$mods = array( $mods );
}
If I'm understanding correctly - this snippet takes whatever weight was already assigned to each Product and changes it to 999999999999, correct?
Doesn't this wipe out the relevancy ordering of products themselves? Like if one product has the search term only in the body and another has it in the title, slug, body and meta, that second one should come up at the top, but with this they would both have the same weight so it would be erratic which one comes first.
Is there a way to add some "extra juice" to a particular post type instead - by taking the existing calculated weight and adding a more reasonable number to it like 10, 30, 100, etc?