wpdb: Exclude invalid identifier names.

[dmsnell]

Trac ticket: Core-63734
See Core-52506.

Rejects schema object names (column names, table names, etc…) provided to wpdb::prepare() if they are expected to be rejected by MySQL, because not all possible strings can be escaped.

This change short-circuits a call to the database which would fail anyway, thus failing faster and reducing database traffic. It adds a _doing_it_wrong() message to notify developers of improper use.

[github-actions]

Test using WordPress Playground

The changes in this pull request can previewed and tested using a WordPress Playground instance.

WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser.

Some things to be aware of

• The Plugin and Theme Directories cannot be accessed within Playground.
• All changes will be lost when closing a tab with a Playground instance.
• All changes will be lost when refreshing the page.
• A fresh instance is created each time the link below is clicked.
• Every time this pull request is updated, a new ZIP file containing all changes is created. If changes are not reflected in the Playground instance,
  it's possible that the most recent build failed, or has not completed. Check the list of workflow runs to be sure.

For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation.

Test this pull request with WordPress Playground.

[johnbillion]

Is this a common problem? Is there a performance impact with these new checks?

[dmsnell]

Is this a common problem? Is there a performance impact with these new checks?

I’m not sure @johnbillion, and it might be hard getting this data because I would expect it mostly to impact a small percentage of plugins, but I was coming to this from an unrelated bug and in the vein of wanting to close any parsing gaps we might have. Every gap is an opportunity for corruption; or worse.

Performance-wise I don’t know how to measure it. The string-parsing should add a negligible overhead (which we can measure to confirm it’s not above the threshold of detectability), but the very first time it catches an invalid schema object name it should more than make up for that performance hit because of skipping a network round-trip to MySQL.

From the original code and unit tests added in Core-52506 we can see that the intent was to more-properly recognize the SQL syntax, but we stoped short at escaping backticks. This work follows that start in applying the rules set by MySQL itself.