Make WordPress Core

Opened 18 years ago

Closed 17 years ago

#4235 closed enhancement (wontfix)

Improve did_action to show information on callers.

Reported by: majelbstoat's profile 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)

#1 @foolswisdom
18 years ago

  • Milestone changed from 2.3 to 2.4

#2 @rob1n
18 years ago

Just curious, but how would you go about getting the specific plugins that called the action?

#3 @majelbstoat
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 @majelbstoat
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 @darkdragon
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?

#6 @darkdragon
17 years ago

  • Keywords hunt-irrelevant added

#7 @darkdragon
17 years ago

  • Keywords hunt-irrelevant removed
  • Milestone 2.4 deleted
  • Resolution set to wontfix
  • Status changed from new to closed
  1. With the improvements to the 'all' hook, I don't believe this should be part of the core.
  2. did_actions() is used specifically for how many times an action was called. Breaking this will cause a regression.
  3. 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.

Note: See TracTickets for help on using tickets.