santosj

I know. I’ve fixed the problem and applied a patch to the Trac ticket, but it hasn’t been approved yet. You can apply the patch manually and it fixes the issue in add_filter and remove_filter.

The only issue is that my solution is slower. Whereas serialize is log(O) or consist, mine isn’t. You have to decide whether you want something that is fast or something that works. if you (or whoever) used functions or a registry model for variables, it might be easier.

From my testing, there are a lot of bugs (and/or inconsistencies) in plugin.php. That it works, means it was tested with functions with objects only as an afterthought.

I would have to say that a __sleep() method should be added to those classes to function with serialize. Another option would be to create a function which calls the class.

The issue is that you are serializing an array, an object, and an string. It doesn’t seem to me that it is needed. The purpose is so that it is unique. However, with the object, the properties can change and will change at some point. Therefore, you might end up adding two or more at some later point depending on how it is set up and if you change any properties before hooking to another action or filter.

First Option use __sleep() method:

function __sleep()
{
return get_class($this);
}

What this does, is return the name of the class, which will be serialized. It won’t interfere with the rest of the code, because it is not being serialized.
$wp_filter[$tag][$priority][serialize($function_to_add)][‘function’ ] is called with call_user_func(), it will work like it would normally.

Second Option Use static version:

array(‘class_name’, ‘method_name’)

The only downside is that the method can not use $this, because it will be called statically. So instead of using $this, use self::.

I should make the assumption that you are using PHP 4, since you are referencing the object and that isn’t needed in PHP 5.