[wp-trac] [WordPress Trac] #55491: Replace `unload` event handlers from core

WordPress Trac noreply at wordpress.org
Thu Aug 24 16:03:48 UTC 2023


#55491: Replace `unload` event handlers from core
-------------------------------------+-------------------------------------
 Reporter:  shawfactor               |       Owner:  westonruter
     Type:  enhancement              |      Status:  accepted
 Priority:  normal                   |   Milestone:  6.4
Component:  Administration           |     Version:
 Severity:  normal                   |  Resolution:
 Keywords:  good-first-bug has-      |     Focuses:  javascript,
  patch                              |  performance
-------------------------------------+-------------------------------------

Comment (by westonruter):

 Note: Even with the elimination of `unload` event handlers, this may still
 not enable the use of bfcache because admin pages are served with `Cache-
 Control: no-store`. The Lighthouse audit notes this as being a "not
 actionable" failure type. The use of `no-store` can be
 [https://github.com/WordPress/wordpress-
 develop/blob/2cdaf29678b2a978b6fb9a730b051237cf40d3b4/src/wp-
 includes/functions.php#L1494-L1497 found] in `wp_get_nocache_headers()`
 and notably `no-store, private` was just added for logged-in users as of
 WordPress 6.3, specifically in r55968 to fix #21938/#57627:

 > The intention behind this change is to prevent sensitive data in
 responses for logged in users being cached and available to others, for
 example via the browser history after the user logs out.

 Therefore, it seems actually that the disabling of bfcache might be
 considered a new security/privacy feature. Eliminating `unload` handlers
 unfortunately will yield no performance improvement, unfortunately.
 However, since `unload` is being deprecated it is still good to remove its
 use and also to remove noise when doing audits.

 Nevertheless, I think we should consider revisiting #21938 to remove `no-
 store` by default because its presence disables bfcache for all logged-in
 page loads, even on the frontend. The introduction of `no-store` didn't
 cause a performance regression in #21938 because bfcache was already
 disabled due to `unload` event handlers being on the page. But with those
 removed, now bfcache is disabled due to `Cache-Control: no-store` instead.
 It could be that for the 80% of users it is better to ''not'' disable
 bfcache and to instead let users opt-in to that via a plugin if they are
 concerned about privacy/security, such as when they are using a shared
 computer.

 Here's plugin code to remove the `no-store` directive from `Cache-Control`
 header:

 {{{#!php
 <?php
 /**
  * Plugin Name: Disable Cache-Control: no-store
  * Author: Weston Ruter
  */

 add_filter(
         'nocache_headers',
         static function ( $headers ) {
                 if (
                         isset( $headers['Cache-Control'] ) &&
                         str_contains( $headers['Cache-Control'], 'no-
 store' )
                 ) {
                         $directives = array_diff(
                                 preg_split( '/\s*,\s*/', $headers['Cache-
 Control'] ),
                                 array( 'no-store' )
                         );
                         $headers['Cache-Control'] = implode( ', ',
 $directives );
                 }
                 return $headers;
         }
 );
 }}}

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


More information about the wp-trac mailing list