Warning Notice $wpdb->prepare incorrect number of arguments passed

Question

I am receiving this notice when trying to use the $wpdb->prepare function:

Notice: wpdb::prepare was called incorrectly. The query does not contain the correct number of placeholders (7) for the number of arguments passed (4). Please see Debugging in WordPress for more information. (This message was added in version 4.8.3.) in C:\wamp\www\wpml\wp-includes\functions.php on line 4139

I looked at other posts on this topic and I don't see any of the same problems from those threads in my code. When developing this notice greatly slows down my application so I want to find a solution.

function get_meta_range($meta_key) {
    global $wpdb;

    // $meta_key = '_price'
    $include = '7275,7266,7256,7237,7196,7192,7164';

    $min = floor( $wpdb->get_var(
        $wpdb->prepare('
            SELECT min(meta_value + 0)
            FROM %1$s
            LEFT JOIN %2$s ON %1$s.ID = %2$s.post_id
            WHERE ( meta_key =\'%3$s\' OR meta_key =\'%4$s\' )
            AND meta_value != ""
            AND (
                %1$s.ID IN (' . $include . ')
            )'
        , $wpdb->posts, $wpdb->postmeta, $meta_key, '_min_variation' . $meta_key )
    ) );

    // $min = 15
}

Answer 1

Numbered placeholders don't work as you'd expect, and are going to be removed altogether at some point in the future, so should be considered invalid syntax.

So with this in mind, the error describes the problem- your query has 7 placeholders, but you only pass 4 values. For the repeated values, you just need to repeat them where you pass the substitutions.

Answer 2

The wpdb::prepare says that you should not quote placeholders, yet in your code there is:

WHERE ( meta_key =\'%3$s\' OR meta_key =\'%4$s\' )

Also keep in mind that the meta table is designed to be fast when you already know the post ID, and WP already fetches all of the meta when you grab a post.

So it would actually be much faster to use get_post_meta and calculate it in PHP, as the data has already been requested. Doing this query is both unnecessary, and potentially expensive