# is_literal() + WordPress

- Thread: https://externals.io/message/109216
- Original archive: https://news-web.php.net/php.internals/109216
- Started by Craig Francis on 2020-03-22T23:14:30+00:00
- Messages: 2
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #109216 — Craig Francis — 2020-03-22T23:14:30+00:00

URL: https://externals.io/message/109216#109216

> 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







> 
> 
> > […]
> 
> +1
> 
> > […]
> 
> Yes.  That is all too common.
> 
> > […]
> 
> 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.

---

## #109219 — Mike Schinkel — 2020-03-23T00:08:37+00:00

URL: https://externals.io/message/109216#109219 · In reply to: #109216

> 
> 
> 
> > […]
> 
> 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);
>    }

True....

> 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 :-)

...but I will let you be the one to champion that cause given how much effort not being a core developer and getting anything added to WordPress it is.  :-)

-Mike