is_literal() + WordPress View as Markdown

IMO getting that in WordPress core is highly unlikely

Good point, like all systems, WordPress will need to consider older versions of PHP.

But, because this is a new function, they can avoid that issue by using function_exists(), as in...

if (function_exists('is_literal') && !is_literal($sql)) {
    trigger_error('This is an unsafe $query, please use $wpdb->prepare()', E_USER_NOTICE);
}

This would be a pretty easy way for WordPress to show they take security seriously, and helping developers to avoid these "all too common" mistakes.

But I do appreciate how much effort it can be to introduce anything in to WordPress :-)

Craig

A large number of PHP users have no control over the platform they run on, so the option to use PECL modules is a non-starter for them.

Thanks Mike,

Personally I agree, I would say PECL modules are not preferable for "useful features"; simply because I try to keep my systems only using core PHP features where possible (makes server admin easier).

+1

As you mention working with WordPress, I've seen a couple of developers who have taken examples like:

$posts = $wpdb->get_results("SELECT ... WHERE post_type='post'");

Then edited it to something dangerous like:

$posts = $wpdb->get_results("SELECT ... WHERE post_type='" . $_GET['type'] . "'");

Yes. That is all too common.

To guard against this, do you think that WordPress could update their get_results() function to do something like:

public function get_results( $query = null, $output = OBJECT ) {
if (!is_literal($sql)) {
trigger_error('This is an unsafe $query, please use $wpdb->prepare()', E_USER_NOTICE);
}

Perhaps with a better message; then, over the years, increase the warning level?

I think that would be a very useful way of getting developers aware of these dangers.

Well...

IMO getting that in WordPress core is highly unlikely for two (2) reasons:

---

1. Getting the WordPress team to adopt new features is about as difficult as getting the PHP community to agree on and add a new feature. IOW, it is a huge uphill battle.

I have many, many unfulfilled feature requests in WordPress' trac that are up to 8 years old or more even though on many of the tickets there appears to be universal interest. What I have found is that the WordPress team does not address anything unless they need it to implement the features that Matt has dictated should be in the next version of WordPress. Because of that, many very useful ticketsl sit there for years and years and do not get addressed.

Of course if a core team member with commit access has a pet feature they want to add, it typically gets slipped it with no fanfare and then we are stuck with it (cough Customizer cough)

I did recently get one ticket addressed about 11 months ago that was a subset of a ticket that is 9 years old (and sadly the OP on the older ticket has since died of cancer.)

But I think I invested probably 80 hours over that duration constantly bringing it up on Slack publicly and via DMs and on the ticket. My guess is they were just tired of hearing from me. And ALL my ticket was asking for was a damn hook that many plugins had already added because WordPress core had not:

https://core.trac.wordpress.org/ticket/47056

---

2. More importantly — and a much higher bar — WordPress core supports PHP 5.6 and so core cannot contain any features that are in a later version of PHP.

https://wptavern.com/wordpress-ends-support-for-php-5-2-5-5-bumps-minimum-required-php-version-to-5-6

And don't expect that to change any time soon. WordPress' minimum PHP requirements was notoriously 5.2.4 until March 2019 so it is unlikely they will bump the PHP requirement before March 2029.

(just kidding, but only a bit.)

Of course WordPress currently recommends PHP 7.3 and most (all?) managed hosts support that so userland developers are free to use newer version of WordPress on our own projects and in our plugins and themes.

https://wordpress.org/about/requirements/

But again, WordPress core cannot use any features anytime soon that are not in PHP 5.6.