[wp-trac] [WordPress Trac] #23259: Allow filtering the $function parameter of add_filter(), has_filter() and remove_filter()
WordPress Trac
noreply at wordpress.org
Tue Jan 22 05:00:38 UTC 2013
#23259: Allow filtering the $function parameter of add_filter(), has_filter() and
remove_filter()
------------------------------------+------------------------------
Reporter: MikeSchinkel | Owner:
Type: feature request | Status: new
Priority: normal | Milestone: Awaiting Review
Component: Plugins | Version: 3.5
Severity: normal | Resolution:
Keywords: has-patch dev-feedback |
------------------------------------+------------------------------
Changes (by MikeSchinkel):
* cc: mike@… (added)
Comment:
Replying to [comment:2 nacin]:
> This sounds clever, but:
>
> * It proposes a solution at the onset, rather than the problem.
I thought that's what trac was for, to post code which is a solution by
nature?
I sometimes feel I'm damned if I do, damned if I don't...
> * If the plugin author would need to do something special to support
it, what is the benefit to this, over better education of developers to
ensure they expose object references (when not just using static methods
, which is even easier)?
Did you read the commenter's comments? His issue wasn't with developers
who expose, it was that when they expose it's complicated for someone who
is not a full time developer to grok how to work with it.
The problem I'm trying to solve here is one of complexity for the site
builder, not the need for plugin developers to do a better job ''(I myself
can already do what's needed to expose those object references, I just
blogged about it after all.)''
I want to be able to build plugins that are very easy for site builders to
use, and this commenter pointed out that if we use classes ''(he thinks,
and currently he's right)'' that means it's going to be harder for him to
work with.
> * This masks the simple callback nature of the second argument,
potentially making it more difficult to read a plugin, especially if one
is less familiar with WP.
True. But then people who are not familiar with WP won't know what
`add_filter()`, `has_filter()` and `remove_filter()` actually do before
they read the code for those functions.
Maybe alternate solution would be to have anything prefixed with '@' to a
special case, or something like that.
> * How would you avoid obvious recursion issues in core? And in the
plugins themselves?
Good point.
When I started writing this up I was only trying to fix the
`remove_filter()` use case and for that I considered the recursion issue
but when I expanded to include more than`remove_filter()` I forgot to
consider it.
Assuming this would be considered in general then the solution is to
disable applying filters for this one hook.
> * This would potentially slow down an API that needs to be very fast
because it is called so often. Worse, performance would degrade further as
more plugins opt into these filters.
True. Well if the we only considered a string and first character were an
indicator it would be a very fast check before running the filter. I've
uploaded another patch for consideration.
And if not would you consider it if we limit the scope to
`remove_filter()` then, as that's where the issue arose?
Better yet, could you read the comments on that post and see if you can
come up with a better solution to empower plugin developers to address the
commenter's concerns?
--
Ticket URL: <http://core.trac.wordpress.org/ticket/23259#comment:3>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software
More information about the wp-trac
mailing list