[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