suggestion: automatic versioning of assets about theme-scaffold HOT 9 CLOSED

gulpfile.js (or gulpfile.babel.js):

gulp.task( 'chronos', () => {
	var filePath = require( 'path' ).resolve( './chronos.txt' ),
		timeStamp = Math.floor( ( new Date() ).getTime() / 1000 );
	require( 'fs' ).writeFile( filePath, timeStamp );
} );

functions.php:

// get timestamp of assets generated by Gulp
$chronos = '';
$timePath = dirname( __FILE__ ) . '/chronos.txt';
if( file_exists( $timePath ) ) {
	$timeFile = fopen( $timePath, 'r' );
	$chronos = preg_replace( '/[^0-9]/', '', fgets( $timeFile, 100 ) );
	fclose( $timeFile );
}
// fallback
if( !$chronos ) {
	$chronos = filemtime( __FILE__ );
}
// guarantee scope
$GLOBALS[ 'chronos' ] = $chronos;

referenced in calls to wp_enqueue_script and wp_enqueue_style (for $ver parameter):

$GLOBALS[ 'chronos' ]

from theme-scaffold.

@krisgale
why don't we just use the

$chronos = filemtime( $timePath );

it will make the code more performance. Since we don't need to open a file, read the content and close it.
And the chronos.txt will get always get updated when compiling.

PS: Sorry to close & repoen the issue, I did press wrong button.

from theme-scaffold.

I'm not against this if we can agree on something

from theme-scaffold.

Here is good info about cache busting. We have been implementing similar idea creating manifest.json file.

from theme-scaffold.

The solution initially proposed here seems to be overly complex.

I think the best way to deal with this would vary on a project basis. For example, any solution that involves reading a file (or obtaining the file descriptor) would not work well on VIP/VIP Go as they don't allow directly access to the file system.

There are indeed, multiple ways to solve this, and ultimately the best way would depend on various factors. As quick alternative for example, we can have DeployBot/Gilab generate a timestamp (or even use something like %DEPLOY_ID%) to replace the theme version constant, or something like that. There's some good discussion here with many solutions we've used: https://internal.10up.com/blog/2018/06/12/automatic-cache-busting-of-css-javascript-assets/.

IMO, instead enforcing something, we should have general guidelines in our best practices around this.

from theme-scaffold.

i do like the notion of updating Version: in styles.css... and this is a thing a gulp task could do (almost) as easily as example implementation i initially proposed.

in either case, having gulp do it ensures that -- 1) a few version is committed to a repository and fellow developers reviewing the work needn't worry about hard-refreshing their web browsers: the version number will cause that to happen automatically -- 2) the same thing happens for all users visiting a site that has been recently updated (via a deploy that runs gulp build during its pipeline).

having a timestamp/version that is site/application-wide makes more sense, to me, than executing filemtime on each and every asset being delivered via wp_enqueue_script/style... and in a clustered environment, filemtime will report radically different timestamps on each brower refresh, causing site visitors' browsers to cache as many versions of a given asset as there are instances in that cluster... this is solved by both methods mentioned herein (a simple text file containing a timestamp, or automatically updating Version: in the descriptor stylesheet).

@nicholasio it's funny, i had studied that internal blog post in trying out my very similar example... i fail to see how it's all that different? ... as for environments that disallow gulp write access -- this is non-issue if the file is created by a deploy bot on a CI server which does allow it, and simply committed and pushed to the destination environment with the rest of the updated files.

a fundamental and useful difference between my example above and what was suggested in the internal blog post is the use of a constant rather than a global variable... this definitely would be preferable:

define( 'ASSETS_TIMESTAMP', $chronos );

with that constant similarly used in subsequent calls to wp_enqueue_script/style.

the rest may seem 'overly complex' but the additions are safety nets... reading only 100 bytes from the generated file as opposed to using file_get_contents prevents a potential out-of-memory pitfall if the file was maliciously overwritten with a very large replacement... and falling back to the modification date of functions.php itself if all else fails (file didn't exist or is empty or contains non-numeric garbage).

from theme-scaffold.

if we prefer git commit hashes over timestamps:

git rev-parse HEAD > commithash.txt

or

git log --pretty=format:'%H' -n 1 > commithash.txt

either could be executed by a deploy script.

from theme-scaffold.

As this is a generic scaffold for all projects, I would be hesitant to commit to any single approach.

Automating asset versioning is a great idea but, as others have said, it can be handled in various ways from something as simple as installing a plugin to the more complicated suggestions made here and on the blog post. There is no single approach that fits all needs and environments.

My concern would be that if we go down any of the paths, there will be users that will need to remove or change the process created by the scaffolding. At that point, the scaffold starts to reduce efficiency instead of increase it.

from theme-scaffold.

Closing this out because it's been stale for a while, we can circle back around if it becomes an issue.

from theme-scaffold.