Proposal for removing the version numbers of the JS and CSS files when SCRIPT_DEBUG is set to true

[rajinsharwar]

I am proposing to remove the version numbers of the JS and CSS files when SCRIPT_DEBUG is set to true. As SCRIPT DEBUG is generally used for developers, in development environments, it's evident that the version numbers can make the changes to the files not reflect on the front end. So, I would suggest adding the functionality of removing the version tags of the scripts, and styles as well when using this constant.

[jonsurrell]

I just want to clarify, you propose removing the ?ver=XYZ query string be removed from scripts and styles, correct?

• Current: /wp-includes/js/dist/script-modules/block-library/navigation/view.min.js?ver=61572d447d60c0aa5240
• Proposed: /wp-includes/js/dist/script-modules/block-library/navigation/view.min.js

On the surface that seems like a good idea, but often these resources are cached and —especially for development— it's undesirable to get a cached version that's stale.

I think that's the root of the issue here, that cached resources may be served. The way that WordPress deals with that is to add the version query as a cache-buster.

The way that's often handled right now is to use filemtime as a version, ​like Core does here:

<?php
$version = defined( 'SCRIPT_DEBUG' ) && SCRIPT_DEBUG ? filemtime( $path ) : 'stable-version-number';

The current strategy seems to work well, I don't think that should be changed. Maybe there are opportunities for quality-of-life improvements like automatically setting a filemtime-based version number when in script_debug mode. However, that presents some difficulties because the path to the file on disk is not always easy to determine and could be impossible, perhaps the script/style is remote on not on disk. This type of change would require a compelling proposal that overcomes potentially difficult technical challenges.