[wp-trac] [WordPress Trac] #23259: Allow filtering the $function parameter of add_filter(), has_filter() and remove_filter()

[WordPress Trac]

#23259: Allow filtering the $function parameter of add_filter(), has_filter() and
remove_filter()
------------------------------------+----------------------
 Reporter:  MikeSchinkel            |       Owner:
     Type:  feature request         |      Status:  closed
 Priority:  normal                  |   Milestone:
Component:  Plugins                 |     Version:  3.5
 Severity:  normal                  |  Resolution:  wontfix
 Keywords:  has-patch dev-feedback  |
------------------------------------+----------------------

Comment (by MikeSchinkel):

 Replying to [comment:4 rmccue]:
 > 2. Class methods: `add_action('init', ['MyClass', 'method'])` or
 `add_action('init', 'MyClass::method')`. Again, dead easy to unhook:
 `remove_action('init', array('MyClass', 'method')` and
 `remove_action('init', 'MyClass::method')`
 > 3. Object methods: `add_action('init', [$this, 'method'])`. This is
 where it gets harder and more complicated. I'll break it down into the
 techniques commonly used with this:
 >     1. `$myplugin = new MyPlugin()`: This is pretty easy to unhook,
 since we're almost always in the global scope when loading plugins (by
 design). `global $myplugin; remove_action('init', [$myplugin, 'method'])`
 >     2. `MyPlugin::instance()`: Again, easy since these are global state
 (although they're not in the global scope. `remove_action('init',
 [MyPlugin::instance(), 'method'])`
 >     3. `new MyPlugin()`: This is the main issue, since although the
 object is instantiated, it's never actually assigned to anything. This is
 one case where it would be handy to be able to filter the callback, but
 that's simply a band-aid fix over the real problem, which is that this is
 sloppy coding that doesn't consider other plugins.

 Let's ignore everything else. This is the problem use-case. Why? Because
 there is no standard way that site builders to remove hooks so there are
 forced to dive into the plugin code to figure it out, and many of them
 don't have the necessary skills with PHP to achieve that.

 The purpose of these ticket was to get WordPress to give site builders a
 documented approach to be able to remove hooks no matter how the plugin
 developer chose to implement the hooks, and to give plugin developers a
 method to support the documented approach.

 > To me, this feels like it's getting '''more''' complicated, not less.

 I'm fine with that.  What I'll then ask is how can we alternately address
 this issue?  How can we give site builders a documented approach to be
 able to remove hooks no matter that you build plugins one way and I build
 them another?  If we can identify that then we can create another ticket
 to request it.

 Replying to [comment:5 scribu]:
 > So, there are actually 2 aspects raised in this ticket:

 Sorry, you got it wrong. You identified the two unimportant aspects of
 ''this'' ticket and missed the important one. For the latter see what I
 wrote to [comment:4 rmccue] above.

 > In summary:
 > Yo dawg, I heard you liked filters, so we put an `apply_filters()` in
 your `add_filter()` so you can filter while you filter!

 Is being disrespectful a pathology with you, or is there some other reason
 you can't stop yourself from always chosing to be rude and insulting?

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/23259#comment:7>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software