Opened 18 years ago
Closed 17 years ago
#4235 closed enhancement (wontfix)
Improve did_action to show information on callers.
Reported by: | majelbstoat | Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | trivial | Version: | 2.2 |
Component: | General | Keywords: | did_action caller filters |
Focuses: | Cc: |
Description
I'd like to propose a small extension to did_action. Currently, wp_actions looks like an array full of actions/filters that have been called:
// Equivalent to this $wp_actions = array('locale');
I'd like the internal structure to be changed to something like this:
$wp_actions['locale'] = array('plugin1_internal_name', 'plugin2_internal_name');
This would allow plugins to determine what other plugins had called a filter. Many plugins are incorrectly localised, calling load_plugin_textdomain() before the init hook. Making this change would allow multilingual plugins (including mine, Gengo) to report back which plugins were broken and would significantly lower the support burden. Obtaining the count would be the same, with:
count($wp_actions[$tag]);
So as not to break backwards compat, I propose adding a second argument to did_actions, a passed by reference array, that will be filled with the array of plugins that have called the specified filter. Similar to the $matches argument of preg_match().
did_actions('locale', $callers); function did_actions($tag, & $callers) { ... }
As $wp_actions is an internal variable, with API provided for accessing it, changing the internal structure shouldn't cause any problems. If there are no objections, I'll work up a patch.
Cheers,
Jamie.
Change History (7)
#3
@
18 years ago
That's an excellent question. I kind of had it in my mind that WordPress would 'just know', but of course it won't. I guess it could possibly be done using debug_backtrace() but that kind of sucks. Might be that there's no way to get this done, which is a shame because it would be good... The next time I write a plugin system, I'm going to put a domain argument in the equivalent add_filter() functions.
#4
@
18 years ago
In fact, can't we just add support for a domain argument to add_filter, add_action? Plugins that don't use it would just be added as 'unknown' for backcompat. Plugins that do would be able to specify a string 'mydomain', which could be queried providing a manner of reflection showing which plugins called what filters. Very helpful in debugging I think. Shouldn't take too long to work something up on this - will put up a quick patch to see what people think.
This might also lead to easily localisable plugin strings, as is currently being discussed on the hackers list: http://www.nabble.com/Improvements-to-the-WordPress-l10n-framework-tf3726667.html
#5
@
17 years ago
Perhaps, you should instead use the 'all' hook and use debug_backtrace()
with that code. It should give you all the information you need. The whole point of the 'all' hook is just for this type of debugging.
If this is acceptable, then wouldn't this be invalid?
#7
@
17 years ago
- Keywords hunt-irrelevant removed
- Milestone 2.4 deleted
- Resolution set to wontfix
- Status changed from new to closed
- With the improvements to the 'all' hook, I don't believe this should be part of the core.
did_actions()
is used specifically for how many times an action was called. Breaking this will cause a regression.
- debug_backtrace that would need to be used was added in 4.3.0, so until the requirements of WordPress is increased for PHP, then I don't think this feature can be properly implemented.
Also, it has had no traction for a while.
Just curious, but how would you go about getting the specific plugins that called the action?