getting back the filter name from inside a plugin function ?

[flux]

Hi,

i'd like to know if there's a way to know the "current" filter name from inside a plugin function.

for example if i declare the same plugin function for several filters like this :

Code Select Expand

$thisplugin->add_filter('thumb_caption_lastcom','bridge_captiontype');
$thisplugin->add_filter('thumb_caption_lastcomby','bridge_captiontype');

can i find out which filter was called from inside "bridge_captiontype()"

if an experience cpg coder is reading this, i'm just trying to bring to my plugin functions the "must_have" array passed to "build_caption()" inside "get_pic_data()"..

thx,

.flux

[Paver]

I haven't thought about your overall goal, but I'll answer your filter question.

Right now, you cannot get the filter name that called a function.  So you have two choices:

• create a wrapper function for each different filter that calls the main function passing the filter name as a parameter
• modify plugin_api.inc.php by adding in the following two lines to the beginning of the filter method and the action method:

Code Select Expand

global $plugin_key;
$plugin_key = $key;

then use $plugin_key in your function (making sure to define it as global in your plugin function of course)

It would be better to put the filter or action name into $thisplugin to keep things organized.  Is there any desire to have this feature in the Plugin API for 1.5?

[flux]

thx paver for the answer

yeah i finally decided to check the plugin api and saw the same thing you described.. that $key is missing from global env.

I guess that it could be interesting to be able to get the whole "current plugin" environment from within plugin functions..

Another thing that caused me a few problems when coding my plugin was that when a plugin filter is called from within a core function you only get in the plugin what's being passed to it by that filter/action call..
And with my short experience of cpg plugin dev, i must say it would have help me many times to get all the parameters passed to that parent function and not only the specific data that was intended to be processed by the plugin and so passed to the plugin..

Now i don't know if it's realistic or if it would cost too much in cpu cycles but it could be also interesting to investigate a way to make all core functions that actually return data, have a plugin filter associated to them..

It could be globalised by replacing the basic "return" function by a cpg_return wrapper that would go thru plugin processing..
That way plugins would have access to any data passed from a function to another in the core code..
Additional parameters passed to the parent function would also be passed to the cpg_return wrapper so the plugin would also have the function call environment and could react accordingly..

just a thought..

.flux