[wp-trac] [WordPress Trac] #58433: WP version in Etag header in load-styles.php file
WordPress Trac
noreply at wordpress.org
Fri Jun 16 07:28:51 UTC 2023
#58433: WP version in Etag header in load-styles.php file
-------------------------------------------------+-------------------------
Reporter: dav4 | Owner: (none)
Type: enhancement | Status: new
Priority: normal | Milestone: Awaiting
| Review
Component: General | Version:
Severity: normal | Resolution:
Keywords: has-patch needs-testing has- | Focuses:
testing-info has-screenshots |
-------------------------------------------------+-------------------------
Comment (by azaozz):
> It might be worth changing how the ETAG header is generated, not to hide
the WordPress version but in order to better calculate a value that
changes with the scripts' versions rather than the WordPress version.
The way this has been working in alpha/beta (for WP development) is by
appending a timestamp to `$wp_version` every time WP is built, see
https://core.trac.wordpress.org/browser/tags/6.2.2/Gruntfile.js#L414.
> a 304 HTTP response may be returned despite the scripts' version
changing
As far as I see the only way the current ETAG (the `$wp_version` that
includes the last built timestamp) can become outdated is if some core
scripts or stylesheets were updated but WP was not build. Not sure if
that's possible?
The patch in [https://github.com/WordPress/wordpress-develop/pull/4618 PR
#4618] looks good however I'm not sure if it will fix the problem (edge
case) of updating WP scripts and not building WP if that is the actual
problem here. `$wp_version` is used to bust caching for many WP scripts
and stylesheets, so the same problem will happen when not concatenating
them.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/58433#comment:15>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list