iamcallen

The review team is being strict here because of how wpdb::prepare() works. It only sanitizes values that go into the query (things you’d replace with %s, %d, etc.). It does not escape or protect table names or column names. That’s why they don’t allow you to drop variables like $db->tb_posts directly into the SQL string.

For core tables you don’t need your own $db->tb_posts anyway, WordPress already exposes them through $wpdb, e.g. $wpdb->posts and $wpdb->postmeta. Those are safe to use in prepared queries, since WP itself defines them. Example:

global $wpdb; $sql_orders = $wpdb->prepare( "SELECT p.* FROM {$wpdb->posts} p INNER JOIN {$wpdb->postmeta} pm ON p.ID = pm.post_id WHERE pm.meta_key = %s AND (pm.meta_value = %d OR pm.meta_value LIKE %s)", '_user_id', $user_id, $user_id_str ); $order_posts = $wpdb->get_results($sql_orders);

If you’re working with custom tables instead of core WP tables, the best practice is to define the table name as a constant during plugin activation (e.g. define( 'MYPLUGIN_USERS_TABLE', $wpdb->prefix . 'myplugin_users' );) and then reference that constant in your queries. That way, reviewers see it’s not user input, and your code passes review more smoothly.

So in short: keep variables out of the query string, let prepare() handle values only, and use $wpdb->tablename or constants for table names.