Not checking if apply_filters exists before calling it in WP_DB

[jdkoelsch]

Prior to version 3.4, there was a check to verify that apply_filters existed before calling it in wp-includes/wp-db.php.

// some queries are made before the plugins have been loaded, and thus cannot be filtered with this method
if ( function_exists( 'apply_filters' ) )
  $query = apply_filters( 'query', $query );

In version 3.4 and above, that check doesn't exist anymore, and can throw an error. There is still a comment indicating that a check should be made, but the actual code to perform the check is now gone. This is around line 1081

// some queries are made before the plugins have been loaded, and thus cannot be filtered with this method
                 $query = apply_filters( 'query', $query );

Here is the github blame view to show when the code was remove (I'm not sure how to find this same view in your svn):

​https://github.com/WordPress/WordPress/commit/81ed9a7563e5ad4c0edccd059bc4ea7d9c1a4a10

There's no explanation about why the code was removed, so would it be possible to add it back in?

Thanks!

Julia

[scribu]

Yeah, I was wondering about that too.

[SergeyBiryukov]

The changeset in question is [19760].

The check was introduced in [4619] (for #2721). In 2.1, wp-includes/plugin.php (where apply_filters() is defined) was loaded later than wp-db.php, so the check made sense at the time:
​http://core.trac.wordpress.org/browser/tags/2.1/wp-settings.php#L97

This was changed in [15811] (for #15042). plugin.php is now included earlier than wp-db.php:
​http://core.trac.wordpress.org/browser/tags/3.4.1/wp-settings.php#L67

As far as I can see, that function_exists() check would always return true now.

In version 3.4 and above, that check doesn't exist anymore, and can throw an error.

Could you provide the steps to reproduce an error?

[scribu]

My problem was when I tried to load only the wp-db.php file for some quick queries.

[SergeyBiryukov]

It seems that now the only query being made before the plugins have been loaded is for loading all options (via wp_not_installed()):

SELECT option_name, option_value FROM trunk_options WHERE autoload = 'yes'

Perhaps the comment should be updated (or removed, since [15811] made it obsolete).

[snburkett]

I would like to second scribu's comment. We have some standalone helper apps that feed data into the same database that our Wordpress plugin accesses. We have some shared utility functions and it is convenient to use the wpdb object, but we prefer not to load all of Wordpress to do so. So far, we have had good luck just including wp-db.php and this is the only real obstacle to continuing to do so. I know other users are doing similar things so I hope you'll continue to support this mode of use.

Thanks!
Steven

[snburkett]

Let me clarify that last comment... we are actually okay on our standalone scripts, the real problem is that I need to call a function that accesses the database before wordpress loads - which requires apply_filters to be defined. So I can define apply_filters as a no-op. But then once we continue on and allow wordpress to load I get "cannot redefine". It's a weird situation I know, but important for our plugin. The only solution that I can come up with short of reinserting the function_exists check in the wordpress core would be to use runkit to undefine the function after I am done processing - but I am loathe to be dependent on runkit.

[nacin]

apply_filters() isn't the only dependency in wp-db.php that would need to be checked. WP_Error, wp_debug_backtrace_summary(), wp_load_translations_early(), __, WP_DEBUG, wp_die, and then some.

There's a class_exists() check on WP_Error but that's about it.

[scribu]

Agree with nacin; the fact that it used to work for me was an accident.

PHP has nice OOP MySQL extensions now anyway:

• ​http://us2.php.net/manual/en/mysqli.quickstart.dual-interface.php
• ​http://us2.php.net/manual/en/class.pdo.php

[scribu]

The attached patch remove all the superfluous function_exists() and class_exists() calls.