Make WordPress Core

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's profile 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)

21504.diff (2.2 KB) - added by scribu 12 years ago.

Download all attachments as: .zip

Change History (13)

#1 @scribu
12 years ago

  • Keywords dev-feedback added
  • Milestone changed from Awaiting Review to 3.5

Yeah, I was wondering about that too.

#2 @SergeyBiryukov
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 @scribu
12 years ago

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

#4 @SergeyBiryukov
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).

Version 1, edited 12 years ago by SergeyBiryukov (previous) (next) (diff)

#5 @snburkett
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 @snburkett
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 @nacin
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.

@scribu
12 years ago

#8 @scribu
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:

#9 @scribu
12 years ago

  • Summary changed from Not checking if apply_filters exists before calling it to Not checking if apply_filters exists before calling it in WP_DB

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

#10 @ryan
12 years ago

  • Milestone changed from 3.5 to Future Release

#11 @chriscct7
9 years ago

  • Keywords dev-feedback added

#12 @pento
8 years ago

  • Milestone Future Release deleted
  • Resolution set to wontfix
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.