WordPress.DB.PreparedSQL.InterpolatedNotPrepared flagging $this->table_name but not $wpdb->table_name

[smileBeda]

There is no way we should use a placeholder for a tablename.
Yet WPDB flags this approach as false and suggests using placeholders (which is potentially not only wrong but even more unsafe).

$existing = $wpdb->get_var( $wpdb->prepare( "SELECT COUNT(*) FROM {$this->table_name} WHERE bla = %s", $bla ) ); => Fails sniff.
This way forces to rewrite the database table name hardcoded potentially countless times instead of setting it to the object.

I can't believe this is how we have to do it.
It seems to have $wpdb whitelisted, however you still would have to hardcode the table_name every time you do a get_var or get_row query.

[jrfnl]

There is no way we should use a placeholder for a tablename.

Your information is outdated. You can use the %i placeholder for tablenames since WP 6.2. Also see: https://make.wordpress.org/core/2022/10/08/escaping-table-and-field-names-with-wpdbprepare-in-wordpress-6-1/

I suggest closing this ticket.

[smileBeda]

Ok, thanks.
This is very new to me. Table and Column names can not be replaced by parameters in PDO, afaik, and that is what I used most in terms of DB Interactions (of course, outside WP)
And as until now this was not an issue, nor a requirement in WP, I did not even think (nor now) about a change like 6.2.
It is also almost not findable when googling for it, all that pops up is the WP DOC that mentions nothing about tablename requiring or being available for preparation... Sorry it ended up here.

---

I guess I will write for "only" 67% of the WP Users then. Not really a big issue in this particular project.

However this remains a problem if one wants to support older versions.
Hardcoding would be the only valid solution to also support users on older than 6.2?
(I do not want to go into version checks. Either it works or not. If this is the only thing I can do, I will just not support older WP versions, I think, in future)

[dingo-d]

Just out of curiosity, why would you want to support older versions?

Besides doing major version updates which can be scary and include some BC breaks, the majority of time the updates in the minor versions are seamless and only affect things like the core editor (which is magically allowed to do BC breaks on minor updates 🙃).

[smileBeda]

Because there are 33% of all WordPress websites (currently) not on 6.2
That is a third of over 800 million websites if we believe stats.
That is the reason why "backwards compatibility" is even a thing, right?

Me personally I try to keep the things up to date, unfortunately that is not always the case/possible/the real world.

[craigfrancis]

Hi @smileBeda, I'm the one who added %i to wpdb, and I'm looking to make further changes (e.g. supporting WHERE id IN (%...d), and specifying the first argument to wpdb::prepare() as a literal-string)... I appreciate where your coming from, especially with backwards compatibility... if you wanted to chat about any of these points, feel free to contact me off-list (allows for more of a conversation, then we can feed back any key points); the intention is to (very) slowly move towards an environment where it's not possible to have injection vulnerabilities (yes, I know, sounds unlikely, but there is a way).

[smileBeda]

Sorry the delay here - happy to talk @craigfrancis
I assume with if you wanted to chat about any of these points, feel free to contact me off-list you meant slack, so I have pinged you there.