[wp-trac] [WordPress Trac] #38929: WP_Hook should support filters added manually through `advanced-cache.php`

WordPress Trac noreply at wordpress.org
Tue Nov 29 02:16:51 UTC 2016


#38929: WP_Hook should support filters added manually through `advanced-cache.php`
-------------------------------------------+-----------------------
 Reporter:  dd32                           |       Owner:  dd32
     Type:  defect (bug)                   |      Status:  accepted
 Priority:  normal                         |   Milestone:  4.7
Component:  Plugins                        |     Version:  trunk
 Severity:  normal                         |  Resolution:
 Keywords:  commit has-patch dev-reviewed  |     Focuses:
-------------------------------------------+-----------------------
Changes (by dd32):

 * status:  assigned => accepted


Comment:

 Replying to [comment:8 rmccue]:
 > Replying to [comment:3 azaozz]:
 > > Replying to [comment:1 dd32]:
 > > > ...anyone modifying `$wp_filter` directly shouldn't probably be
 doing so anyway after WordPress loads.
 > >
 > > Don't think anybody should be modifying `$wp_filter` directly in any
 case. Do you think it is a good idea to add "Doing it wrong..." somewhere?
 Perhaps in `WP_Hook::build_preinitialized_hooks()` as it exists to fix
 that "bad behavior".
 >
 > Marking it with deprecation for cache drop-ins would be a good idea,
 IMO. I don't think it should trigger that for hooks declared before WP is
 loaded though, since there's no alternative to setting `$wp_filter` if WP
 hasn't yet loaded.

 I believe the correct way is for the code to include `plugin.php` before
 WordPress to get access to the methods.
 I don't think it's worth putting a deprecation warning in here, especially
 as it's unlikely to really be seen by developers when it's triggered this
 early in the bootstrap.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/38929#comment:9>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list