no sites are broken

Or so the wordpress post at wordpress.org would have us believe. However, I think there is flaw in both their logic, and their decision making here.

I spotted the problem following an upgrade to wordpress 3.5 on a site I use. One of the plugins on that site objected to the upgrade with the following error message:

“Missing argument 2 for wpdb::prepare(), called in /path/to/some/function.php”

That error message was splattered all over the page which called that function. The page is public.

A quick search brought me to the wordpress announcement above. But crucially, and worryingly, it also threw up nearly 10,000 other references. Almost all the referenced pages I checked showed websites with that error message (with variations on the path/to/function) displayed fairly prominently.

The wordpress article explains that the error occurs because some function written by a developer (probably a developer of a theme or plugin) called the “$wpdb->prepare()” wordpress function with only one argument when it is supposed to be called with two. Worse, the article explains that calling the “$wpdb->prepare()” function in this way is insecure because the SQL query it is passing is not properly prepared (despite what the developer may think).

The article says:

“But here’s where the problem lies:

 

$wpdb->prepare( “SELECT * FROM table WHERE id = $id” );

 

See the problem? That query isn’t secure! You may think you are “preparing” this query, but you’re not — you’re passing $id

directly into the query, unprepared. And this, right here, is why $wpdb->prepare() now issues a warning if it isn’t called with

more than one argument. Because you can’t prepare a query without more than one argument. Here’s a correct example:

 

$wpdb->prepare( “SELECT * FROM table WHERE id = %d”, $id );

 

This wasn’t a decision done lightly. We don’t like shoving PHP warnings into the faces of users and developers. But given

the potential security risks, we wanted everyone to immediately look at how they are running queries. And, of course, always

prepare them properly.

I love that last paragraph (I could argue with the grammar too, but hey). If they “don’t like shoving PHP warnings into the faces of users and developers” why do so? In doing this they have drawn attention to the following:

• the website is running wordpress 3.5 (a rather new version which may have other problems than this).
• the website manager has not turned off php error reporting (and thus may be inexperienced or otherwise lax in his/her security stance).
• the site is running one (or more) plugins which may be vulnerable to SQL injection attacks.
• internal path structures on those websites are now exposed for all to see.

They have also made a lot of websites look bloody awful. Take this as an example:

Thanks guys. Way to go. And despite what you say, lots of sites now look broken.