Take the 2-minute tour ×
WordPress Development Stack Exchange is a question and answer site for WordPress developers and administrators. It's 100% free, no registration required.

There are reports that remove_filter does not work under some circumstances, and that we should provide alternatives. However, the article does not really make it clear under which circumstances this happens.

I am looking for code examples that will break remove_filter, with WordPress and PHP version, and eventually other relevant info, provided. I think the following snippet should be a useable template:

<?php
include('wp-load.php');

function filtertest_function($value)
{
    return 'Filtered';
}

var_dump(apply_filters('filtertest', 'Original value'));
add_filter('filtertest', 'filtertest_function');
var_dump(apply_filters('filtertest', 'Original value'));
remove_filter('filtertest', 'filtertest_function');
var_dump(apply_filters('filtertest', 'Original value'));

This will return the expected:

string(14) "Original value"
string(8) "Filtered"
string(14) "Original value"

I believe the error comes up in some cases where the filter is part of a class, or multiple filters are used. I understand _wp_filter_build_unique_id is involved. Please point out where in that code the source of the error is.

share|improve this question
    
Hi @Jan: What's your goal here? Are you experiencing the error, want to write code that avoids the error, or other? In reviewing @hakre's post[1] and the related trac ticket[2] it seems this is a pretty esoteric bug and there's even debate as to whether what @hakre wrote is fully legitimate (see the comments.) [1]: hakre.wordpress.com/2010/08/09/… [2]: core.trac.wordpress.org/ticket/10535 –  MikeSchinkel Sep 5 '10 at 19:49
    
@Mike: I want to know when I could experience the error, so I know whether it is worth coding around it. Indeed, I read the comments and the trac tickets, but we could use a single, updatable place where this issue is explained. This site seemed a perfect fit. –  Jan Fabry Sep 5 '10 at 20:04
    
@Jan: FWIW I've done an awful lot of coding and never come across the error. I also have only rarely found the need to use remove_filter() making me think that people may be using it when a more proper coding approach could/should be used (so maybe that's why I've not run into the problem?) I'd be curious to know when it is really needed besides to actually remove a filter added by core or another plugin that you need to have not run. –  MikeSchinkel Sep 5 '10 at 21:14
    
Nice question, and from my point of view truly valid. But as Mike already pointed out, it's not something that all devs will have to deal with (when did you last used remove_filter()?). Next to the articel in trac ticket and comments code already shows problematic areas. But keep in mind that this is a development discussion and Mike posed the right counter-question: What are you after? I just suggest in the article to not rely on remove_filter(), to be on the safe side. –  hakre Sep 6 '10 at 20:51
    
@hakre: Your article indeed shows workarounds, but they are non-standard, so I would like to know whether it is needed to use them for the filters I create. The trac tickets show examples, but it is hard to know to which versions of WordPress they apply. If we post the non-working examples here, they can be updated with new answers if the limitations change. I want to create plugins that are nice to each other, so all filters should be removable. –  Jan Fabry Sep 6 '10 at 21:09

2 Answers 2

Well this is somehow a very specific topic that is bound to a Wordpress development issue. I strongly suggest you to keep track of the trac ticket if you liked my article. That is the best thing you can do I assume for finding out when the problems come into play as well how to circumvent them technically (if you don't like the don't use remove_filter()-answer).

Take it from a theoretic standpoint: It's just that the used datatypes are not strictly dealt with to ensure the same functionality on all possible values (f(n) != f(n)). In short: a broken design.

Does this mean it will always break in practise? - No! It's just that it can happen sometimes. And then you're trapped when you need to rely on remove_filter().

A better suggestion might be this one: If you develop plugins that make use of hooks as class methods, ensure that the plugin get executed on installations with PHP 5.2 / 5.3.

Please keep the technical discussion in the trac ticket. And if you're seriously interested, please help to fix the shortcomings of the current design.

share|improve this answer
    
I understand that this is a technical issue, and that the best discussion can be found on the trac and mailing lists, but maybe spread over different tickets and threads. Since this internal issue can have consequences for plugin developers, of which many don't follow the trac or the mailing lists, I think a clear example on this site would not hurt. If you think this question is not in the scope of this site, we could discuss it on the meta site. –  Jan Fabry Sep 7 '10 at 8:33
    
@Jan Fabry sure, good point. but for me a technical discussion makes sense if it results in a fix. has_filter() might be broken as well. I now started to refactor the plugin.php file: core.trac.wordpress.org/ticket/14789 but I will not touch the uniq_id routine for the moment. –  hakre Sep 7 '10 at 12:52

As Denis commented on Hakre's blog, this is a very basic example of the issue.

function run_me_once() {
    remove_action( 'foobar', 'run_me_once' );
    echo 'test....';
}
add_action( 'foobar', 'run_me_once' );

function run_me2() {
    echo 'test2....';
}
add_action( 'foobar', 'run_me2', 11 );

echo '';
do_action( 'foobar' ); // test....
echo '';
echo '';
do_action( 'foobar' ); // test2....
echo '';

Before running that code though, ask yourself, what would you expect the result to be. Once you've decided what the result should be, run it and see what happens.

share|improve this answer
    
This one is a separate defect - which got closed in trac as wontfix - from the one highlighted by hakre. It's one of the most colorful quirks that one needs to get used to when doing WP development. :-) –  Denis de Bernardy Dec 19 '10 at 18:46
    
You chaps know more than i.. it read as being of the same problem(guess i know less than i thought).. hehe.. :) Every program/app has quirks though..(it's to be expected to some extent i guess).. –  t31os Dec 19 '10 at 19:07
    
@Denis: care to link to that wontfix-ed ticket? I couldn't find it. –  scribu Dec 20 '10 at 1:04
    
@scribu: sorry. All I remember is it got closed and it really pissed me when it did. One of those many, many, many, many days when I promised myself to no longer contribute patches to WP... (Which I no longer do, for some reason...) –  Denis de Bernardy Dec 20 '10 at 4:11
    
Nevermind, I found it: core.trac.wordpress.org/ticket/9968 –  scribu Dec 20 '10 at 14:26

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.