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

[WordPress Trac]

#38929: WP_Hook should support filters added manually through `advanced-cache.php`
--------------------------+-----------------
 Reporter:  dd32          |      Owner:
     Type:  defect (bug)  |     Status:  new
 Priority:  normal        |  Milestone:  4.7
Component:  Plugins       |    Version:
 Severity:  normal        |   Keywords:
  Focuses:                |
--------------------------+-----------------
 As noted in [https://wordpress.slack.com/archives/core/p1479936387003877
 Slack], with `WP_Hook` in 4.7, we've seemingly glossed over the impact of
 these changes upon `advanced-cache.php` dropins.
 Prior to `WP_Hook` being committed, we'd attempted to work around filter
 additions from `advanced-cache.php` with some funky code which we
 eventually reverted in [38251] - we didn't *really* need it at the time,
 but with `WP_Hook` additions we're now in the scenario where something
 like that IS needed.

 `WP_Hook` includes the ability to upgrade a non-wp_hook `$wp_filter` array
 to an array of `WP_Hooks` to account for cases where filters are added
 before `plugins.php` / `WP_Hook` loads.

 With the upgrade to 4.7, any user who is running an object cache which
 performs direct `$wp_filter` modifications is likely to cause a fatal
 error, unless they've updated the cache first and done something like
 Batcache: https://github.com/Automattic/batcache/pull/76/files

 However, thanks to the upgrade code, we can simply call it again after any
 non-code files are included - thankfully, the only user file which this
 could apply to is `advanced-cache.php`.

 Attached is a 4 line patch ([attachment:38929.diff]) which upgrades the
 `$wp_filter` modifications so that a older `advanced-cache.php` is
 compatible with 4.7+.

 At this point of the pageload, most WordPress installs will have *zero*
 filters registered, unless something such as WP-CLI is in use, or a filter
 was added before WordPress loaded, so the performance of this is a no-op
 for most people.

 ----

 It's worth noting that there exist some incompatibilities with `WP_Hook`,
 in that any plugin which manually alters `$wp_filter` will at best cause a
 PHP notice, and at worst, cause a PHP fatal error (although it's also
 still possible to manually manipulate `$wp_filter` if you must, by setting
 entire arrays rather than modifying it - see below)

 One of these cases affects `advanced-cache.php` - If something has added a
 hook, and `advanced-cache.php` attempts to also add a hook ''through
 manual `$wp_filter` modification'' it'll cause a PHP notice and the filter
 addition will fail - I feel that this is an edgecase enough not to need to
 support.

 [attachment:test-wp-hook.php] is a stand-alone-ish script to obviously
 show these edge cases, but also shows that the diff in
 [attachment:38929.diff] should work as expected, if you discount the PHP
 notice possibility and the hopefully unlikely fatal.

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