The code you found modifies the main query on pre_get_posts and unsets the search terms so WP_Query doesn’t run a real search query. What you want is
// Filter the search SQL that is used in the WHERE clause of WP_Query.
apply_filters_ref_array( 'posts_search', array( $search, &$this ) );
which runs previously in WP_Query::get_posts(). This later on adds to the WHERE clause:
$where .= $search . $whichauthor . $whichmimetype;
where the author part is:
" AND ($wpdb->posts.post_author = " . absint($q['author']) . ')';
and the MIME-Type part uses wp_post_mime_type_where() and is
$whichmimetype = wp_post_mime_type_where( $q['post_mime_type'], $wpdb->posts );
If the s query var is set, you can use orderby as well and modify it from a filter:
$search_orderby = apply_filters( 'posts_search_orderby', $search_orderby, $this );
The result of this will be the first ORDER BY SQL argument followed by whatever was specified as default ORDER BY argument. If there was no default, it will fall back to the search argument.
$orderby = $orderby ? $search_orderby . ', ' . $orderby : $search_orderby;
Of course you still can then use the posts_clauses and the related filters. You do an early hands on inspection of your results to check if you managed to get a working query by hooking in on
do_action( 'posts_selection', $where . $groupby . $orderby . $limits . $join );
This will give you the complete final SQL string.
Keep in mind that other plugins might as well jump in on the pre_get_posts, posts_request or posts_clauses, posts_* filters and that you won’t really be able to work around such conflicts in a generic way.