Opened 12 years ago
Closed 8 years ago
#21504 closed defect (bug) (wontfix)
Not checking if apply_filters exists before calling it in WP_DB
Reported by: | jdkoelsch | Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | 3.4.1 |
Component: | Database | Keywords: | has-patch dev-feedback |
Focuses: | Cc: |
Description
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
Attachments (1)
Change History (13)
#2
@
12 years ago
- Keywords reporter-feedback added
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?
#3
@
12 years ago
My problem was when I tried to load only the wp-db.php file for some quick queries.
#4
@
12 years ago
It seems that now the only query being made before the mu-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).
#5
@
12 years ago
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
#6
@
12 years ago
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.
#7
@
12 years ago
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.
#8
@
12 years ago
- Keywords has-patch added; dev-feedback reporter-feedback removed
Agree with nacin; the fact that it used to work for me was an accident.
PHP has nice OOP MySQL extensions now anyway:
Yeah, I was wondering about that too.