no sites are broken

Or so the wordpress post at 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.

Permanent link to this article:


    • Peter on 2012/12/26 at 4:05 pm

    I have that problem show up in the output of the Counterize plugin and frankly, I’m toying with switching back to the latest 3.4 release because of it (I don’t code, otherwise I would have dug up myself where the problem lies – I’ll send what you copied in to the developer because that may help him).

    Counterize is the only web statistics package that doesn’t send data of my visitors to some 3rd party that has no business knowing them, so I’m rather fond of it for reasons of visitor privacy.

    Anyway, meanwhile I’d like to wish you the best of those festive days, and maybe ve vil meet again in 2013. I may be in London in Jan (awaiting confirmation), so in the event you happen to have business there too I’d be glad to catch up over a beer :).

    TTFN, P

    • Mick on 2012/12/26 at 5:27 pm


    If you have shell access to the OS with permissions to edit the system wide PHP settings you should change “display_errors = On” to “display_errors = Off” in /etc/php5/cgi/php.ini. If you don’t have those permissions (because you are using a hosted webservice for example) then you should do as Nacin suggests in the wordpress blog post and set display_errors to 0 in wp-config.php. That won’t solve the underlying problem, but at least the errors (and file path exposures) won’t be visible to world + dog. If you can’t even edit the wp-config file, then I’d suggest firstly contacting your hosting provider to sort the problem and secondly (better long term solution) moving to a provider who gives you shell access.

    And a Merry christmas and happy new year to you too. (I’m unlikely to be in town in January so I’ll take a raincheck on the beer).



    • Peter on 2012/12/30 at 2:25 pm

    Mwah, command line access.. I’m in the process of starting up an entire secured platform, and eventually I will probably add a DMZ for a website but even then I would rather not have access to the platform underneath. It would also cause other problems: part of the certification requires that control interfaces are only reachable from networks which are geographically inside the country (no cheating via VPN allowed either). I don’t *need* the certification, but some of the target market is sure to ask for it and it makes sense from a security perspective anyway.

    For now the site is with a sensible hosting company, so I just changed the wp-config.php file. I may even just leave it there – I rather like the total physical separation between the operational platform and the sales website :). Also helps when I’m traveling – I can still change the website :).

    Have a good one, and I’m sure ve vil meet again :)

    Regards, P

Comments have been disabled.