[wp-trac] [WordPress Trac] #58433: Improve Etag-based cache busting for styles and scripts
WordPress Trac
noreply at wordpress.org
Fri Apr 5 23:43:58 UTC 2024
#58433: Improve Etag-based cache busting for styles and scripts
-------------------------------------------------+-------------------------
Reporter: dav4 | Owner: (none)
Type: enhancement | Status: new
Priority: normal | Milestone: 6.6
Component: General | Version:
Severity: normal | Resolution:
Keywords: has-patch needs-testing has- | Focuses:
testing-info has-screenshots commit |
-------------------------------------------------+-------------------------
Comment (by azaozz):
Replying to [comment:16 peterwilsoncc]:
> It looks like this only works if running WordPress-Develop from the
`build` directory.
> ...
> Thus the etag doesn't change when the editor packages are updated which
can cause the caching issues I've seen.
Yes, there seems to be an edge case when:
- WP runs from /src.
- `SCRIPT_DEBUG` is (manually) set to `false`.
- Editing scripts or freestyles or updating scripts added from the npm
packages.
Note that if `SCRIPT_DEBUG` is not set, it is set in
`wp_scripts_get_suffix()` in Script Loader:
https://developer.wordpress.org/reference/functions/wp_scripts_get_suffix/.
The default is to have `SCRIPT_DEBUG` set to `true` when running from
/src. That disables concatenation of scripts and stylesheets and ensures
caches are always busted.
Generally testing after editing or updating of any JS or CSS files should
be done with `SCRIPT_DEBUG` enabled to help catch any possible errors.
This of course includes testing after updating scripts from npm packages.
So it seems that setting `SCRIPT_DEBUG` to `false` when running from /src
and then updating npm packages is more like a deliberate action, and the
result should be expected? In any case, seems a better fix for this may be
to add a random string to the URLs when outputting the tags for
concatenated scripts and stylesheets while running from /src. Changing (or
disabling) the etag may not be enough, and generally doesn't work as well.
> It may be worth adding something like this...
Hmm, this will attempt to bust the cache on every page load in wp-admin
when running from /src? I.e. it is pretty much the same as the current
functionality in Script Loader, only the latter is a bit more refined and
can be controlled with constants.
Don't think it is a good idea to change `$wp_version` as that will
duplicate and interfere with the existing functionality in Script Loader.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/58433#comment:23>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list