WordPress.org

Make WordPress Core

Opened 5 months ago

Closed 5 months ago

Last modified 5 months ago

#39007 closed feature request (fixed)

Impossible to access current priority with WP_Hook

Reported by: Rarst Owned by: pento
Milestone: 4.7 Priority: normal
Severity: normal Version: 4.7
Component: Plugins Keywords: has-patch has-unit-tests commit dev-reviewed
Focuses: Cc:

Description

While there was never a public API for it, the specifics of implementation had previously allowed to access current priority within a hook via key( $wp_filter[ current_filter() ] ).

This seems to no longer be a case with 4.7 implementation based on WP_Hook which both changes what this expression returns (string callbacks) and seems to hide priority data in private property.

Given that implementation both breaks existing way to do it and doesn't open a new way to it breaks all code that needs access to current priority state without alternative.

Attachments (2)

39007.diff (793 bytes) - added by pento 5 months ago.
39007.2.diff (2.1 KB) - added by pento 5 months ago.

Download all attachments as: .zip

Change History (12)

#1 follow-up: @dd32
5 months ago

For reference; Do you know of any public projects which have been utilising this?

#2 in reply to: ↑ 1 @Rarst
5 months ago

Replying to dd32:

For reference; Do you know of any public projects which have been utilising this?

My Laps profiler plugin got exploded by this https://github.com/Rarst/laps

#3 @toscho
5 months ago

There are also some often reused snippets on WordPress Stack Exchange, this one for example: How to force function to run as the last one when saving the post?

@pento
5 months ago

#4 @pento
5 months ago

  • Component changed from General to Plugins
  • Keywords has-patch reporter-feedback needs-unit-tests added
  • Milestone changed from Awaiting Review to 4.7
  • Owner set to pento
  • Status changed from new to assigned

While this has never really been supported behaviour (particularly with how broken nested hooks were), I don't think it's unreasonable to explicitly allow access to the currently running priority of the current filter.

@Rarst: How do you feel about 39007.diff? To take your example, you'd use it as: $wp_filter[ current_filter() ]->current_priority().

#5 @Rarst
5 months ago

Not sure about implementation, but API seems to make sense. :)

One question is would current_priority() function make sense to complement current_filter() for procedural access? That would make conditional logic less clunky (if have new function just use it, otherwise do old thing).

#6 @pento
5 months ago

  • Keywords reporter-feedback removed

Adding a current_priority() function seems like it's a bit more than is necessary.

For conditional logic, class_exists( 'WP_Hook' ) is a reasonable test, this is what Batcache uses, for example - it's technically not correct for 4.7 betas that don't have the ::current_priority() method, but I don't think that should be a big issue. :-)

@pento
5 months ago

#7 @pento
5 months ago

  • Keywords has-unit-tests commit added; needs-unit-tests removed

39007.2.diff adds unit tests.

#8 @helen
5 months ago

  • Keywords dev-reviewed added

#9 @pento
5 months ago

  • Resolution set to fixed
  • Status changed from assigned to closed

In 39430:

Plugins: Add a current_priority() method to WP_Hook.

This allows plugins to determine the currently running priority of a filter.

Fixes #39007.

#10 @pento
5 months ago

In 39431:

Plugins: Add a current_priority() method to WP_Hook.

This allows plugins to determine the currently running priority of a filter.

Merges [39430] to the 4.7 branch.

Fixes #39007.

Note: See TracTickets for help on using tickets.