Does filemtime(custom.css) in functions.php return timestamp if OPcache is ON ?

  • Question 1: Is there a mechanism which reliably invalidates the OPcache if the corresponding PHP file gets updated?

    • On my webhost I have PHP OPcache ON with a timeout of 300 seconds.
    • When I perform changes in the functions.php of my block theme (a modified TT3 theme) and save the file (via SSH or SFTP), these do not reflect.
    • For now my workaround is that during performing changes in functions.php I destroy the current OPcache and disable it henceforth. Then my changes in functions.php always are reflected when reloading. After that session I re-enable it for performance gains.

    Question 2: If you have OPcache ON and in wp_enqueue_styles() you want to set the version tag to be the return value of filemtime(/path/to/custom.css) are CSS file changes noticed/refreshed for all new requests thereafter if the PHP file performing those filesystem calls itself is OPcached? Or is filemtime() run once and then the result of this is kept for the next 300secs? And at earliest filemtime() runs on the next request after that 300secs timeout?

    • I use W3 Total Cache for Page Caching (HTML) and also have set up cache busting for my asset files (CSS, JS, fonts). Meaning for them max-age is set to half a year without any re-validation. So only when the version tag changes the browser re-fetches them.
    • I use wp_enqueue_styles() to enqueue my own global.css file and I see basically 3 possibilities:
    <?php
function mytheme_enqueue_styles(){
	// 1) No verstion tag at all
	wp_enqueue_style( 'extra-style', get_stylesheet_directory_uri() . '/assets/css/global.css');
	// 2) Manually: Set version tag myself to a version number or date whenever I have done meaningful changes to global.css which all users shall get.
	wp_enqueue_style( 'extra-style', get_stylesheet_directory_uri() . '/assets/css/global.css', NULL, "2023-06-08--204400");
	// 3) Automated: Set the version tag from global.css the file modification date
	wp_enqueue_style( 'child-style', get_stylesheet_directory_uri() . '/assets/css/global.css', date( DATE_ATOM, filemtime(get_theme_file_path() . '/assets/css/global.css')));	
	
}
add_action( 'wp_enqueue_scripts', 'mytheme_enqueue_styles' );
>

    During development I use variant °1 and in the web browser simply perform a hard-reload to enforce getting the up to date assets.

    Now for production: Can I rely upon °3 automated tag from CSS timestamp or must I set °2 a manual version tag in functions.php each time something significant changes in my CSS file?

Viewing 1 replies (of 1 total)
  • Thread Starter abitofmind

    (@abitofmind)

    Ad question 2 I came to this conclusions:

    I tested approach 2 manually set version tags. If you change the static tag in functions.php and then request a page as a logged-in user, you bypass page-caching (via .htaccess) and indeed go through WordPress index.php routing and in consequence to functions.php and I can tell you now: Its OPcache representation still has the old static version tag!

    So you need to invalidate the OPcache. Then your logged-in users will get the updated CSS file. As the functions.php rendered the HTML differently: Now contains references to custom.css?v=2 instead of custom.css?v=1. As the web browser only has the old custom.css?v=1 cached, it is forced to load custom.css?v=2 (that’s called “cache busting”).

    But the HTML page-cache still contains only custom.css?v=1 references. So you need to invalidate the entire page-cache too then.

    Ad approach 3 automatic from timestamp:

    1. My code to get the filemtime() seems not to work, falls back to ver=6.2.2 (WP version number). With a child theme it had worked. I seem to have done something wrong with my adaptation to a standalone theme.
    2. But back on topic: If a statically set variable value is cached, I suspect a more performance-expensive filesystem call is cached too.

    So unless someone answers me Question 1 (how to destroy a corresponding Opcode Cache if its PHP file gets updated) this requires anyhow some manual procedure (destroy Opcode cache). Then the extra effort of setting a manual version tag in functions.php prior to resetting Opcode cache, is a conscious act and gives me the possibility to only “ship this for all anonymous users too” if “significant enough”. Ofc users who hard-reload could get the new CSS “ahead of time” still.

Viewing 1 replies (of 1 total)
  • The topic ‘Does filemtime(custom.css) in functions.php return timestamp if OPcache is ON ?’ is closed to new replies.