[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:  trunk
 Severity:  normal                  |  Resolution:  wontfix
 Keywords:  has-patch dev-feedback  |
------------------------------------+----------------------
Changes (by MikeSchinkel):

 * version:  3.5 => trunk


Comment:

 Replying to [comment:10 scribu]:
 > > 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.
 >
 > If they don't have the necessary skills with PHP, why do you assume they
 have enough skills to know which hook controls which aspect of the plugin?

 There are two different archetypes here, not one. The 1st is the plugin
 author with the skills and 2nd is the sitebuilder without.  I was asking
 for a standard way for the plugin author to empower the lesser skilled
 site builder.

 > What about complex features that require multiple hooks? example:
 WP_Query mangling

 I'm not visualizing the use-case you are referring to. I'd need a use-case
 example to understand.

 > Anyway, I think I get what you're looking for:
 >
 > {{{
 > add_plugin_support( 'feature-x' );
 >
 > remove_plugin_support( 'feature-x' );
 > }}}

 That would be interesting and could be very useful.  But I would see it as
 too course-grained to address the hook removal use-case.

 FYI, the reason I posted this ticket was because of
 [http://hardcorewp.com/2012/enabling-action-and-filter-hook-removal-from-
 class-based-wordpress-plugins/#comment-475 this comment thread] where the
 commenter said ''**(emphasis mine)**:''

 >''It’s such a pita to remove actions & filters hooks called from classes.
 **Makes me hate the overzealous use of classes** especially in cases when
 there are **no major benefits to use a class** to start with. ... Well
 your solution is a hell of a lot **better than hunting through the
 wp_filters** global cowboy style. **If this were the standard** for all
 plugin developers that would be a step forward.  The problem also lies in
 the discoverability. **If it’s documented**, at least a user could
 potentially find it. The truth is most plugins aren’t going to have a ton
 of documentation and would a non-savvy user know what to look for? It
 would require more explanation. ... If it’s about pushing core changes, I
 would **rather see them make remove_action & remove_filter smarter** so
 that you don’t have to reference the class instance in the first place.
 That would retroactively **make all relevant plugins easier to customize**
 without requiring plugin authors to implement workarounds (even pretty
 elegant ones like yours). Are there any critical objections to that that
 you could think of? As a self taught dev who’s learning was based mostly
 around WP projects, I am happy that most code I encountered wasn’t object
 oriented in the early days. **I’ve found OO much hard to grasp**
 initially. Now that I’ve got some years under my belt, I’m comfortable
 with it (just wrote a class yesterday because it made the most sense) but
 **I still wish to see less of it in plugins** because I find it gets in
 the way a lot of the time. I imagine lots of new users might feel similar.
 I do think the offical WP docs contribute to that as well (not a ton of
 examples with classes etc).''

 So I'm sensitive to people who want to be empowered by WordPress but who
 are sometimes overwhelmed by it. And that is who I'm ultimately trying to
 help here. But I don't really need this for my own work and I didn't
 expect it to be such an issue so if it is I can fight other battles
 instead.

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