[wp-hackers] apply_filters, merge_filters and reset()

[Jacob]

You should very well, make the bug report then for 2.3.2. It would at 
least fix some issues with actions that may have been edge cases.

There is no need to test, but you can do so anyway, it has been a while 
and this is one of the little known and documented issues. I've already 
ran a few (including switching over to foreach) while testing the issue 
with <code>next($wp_filter[$tag]) !== false</code>.

I think the problem is that foreach doesn't expect for the array to be 
updated inside of its loop. It only does the reset before it starts. The 
second issue would be that foreach acts upon a copy of the original 
array. Appending values to the original array will not update the array 
referenced in the foreach construct.


Travis Snoozy wrote:
> On Wed, 07 Nov 2007 19:49:57 -0600, Jacob <wordpress at santosj.name>
> wrote:
>
> <snip>
>   
>> I've been following the current Plugin API bugs and enhancements and
>> I would hold off on that if I were you.
>>
>> http://trac.wordpress.org/ticket/5231
>> http://trac.wordpress.org/ticket/5232
>>     
>
> For the record, these concern trunk/2.4, not 2.3.1. The discussion
> about separating filters/actions is interesting, but there still
> may need to be a simpler bugfix applied to 2.3.2 (e.g., always call
> merge_filters, or at least always reset the array). I'll have to re-run
> perf on a 2.4 beta/RC anyway. ;)
>
>   
>> I think there might be a good reason to not use foreach in that
>> function because of the inter references and possible changes. If you
>> add a tag while iterating, you will break the array reference and it
>> would need to be reset anyway.
>>     
> <snip>
>
> I assume you mean "a filter/action adds/removes hooks" when you say
> "add a tag while iterating". That's a valid point; I'd need to test and
> make sure that it still works (I know I have some plugin code somewhere
> that does just this by hooking a high level and de-hooking a
> lower-level callback). I'm not entirely confident that each() really
> behaves any more consistently than foreach in that scenario, though.
>
>
>   
>> And yes, if you read the reports, the do_action and companion should 
>> have checked for the tag in merged_filters before calling
>> merge_filters function.
>>     
>
> Which would indicate that they're all buggy, since they rely on the
> reset side-effect of merged_filters to get the array pointer back to
> the start, and nothing else (as far as I can see) resets that array.
>
>
> --
> Travis 
>
> In Series maintainer
> Random coder & quality guy
> <http://remstate.com/>
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>   


-- 

Jacob Santos

http://www.santosj.name - blog
http://wordpress.svn.dragonu.net/unittest/ - unofficial WP unit test suite.

Also known as darkdragon and santosj on WP trac.