Best solution to browser css cache problem - lastModified?

[cottagestuff]

Having a serious problem with clients’ browsers showing them cached copies of old css files so they don’t see the updated design, and them telling me it is a nightmare to try to empty their cache (on phones mostly nowadays), and not being happy. So what is the best way to force the visitor’s browser to fetch an updated copy of the css file without manually changing the name of the css file?

Found the LastModified package, installed it, but the snippet call below does nothing (no css file is found and returned, so the page is displayed unstyled):

<link rel="stylesheet"  type="text/css" href="[[!lastModified? &path=`css/` &file=`main.css`]]">

Capitalising the L does not make it work. The css file is in place at css/main.css. The result is:

<link rel="stylesheet"  type="text/css" href="">

The idea behind the package seemed perfect. Is it a good solution? If so, how to get it to work? (The documentation gives zero instruction on the correct snippet call.)

[bruno17]

where did you find that package?
I only can find a plugin with that name, which does something different

[cottagestuff]

https://extras.modx.com/package/lastmodified

I found that after finding the answer from Daemon.Devin to this question:

How to manage CSS in ModX, changes to css in filesystem have no effect, clearing cache doesn't work

[cottagestuff]

I am assuming the opening backticks shown in the documentation are wrong:

Specify a path &path=css/ and the file &file=style.

[cottagestuff]

Found MinifyX. Is that a good way to solve the browser cache problem?

Have the following in the template:

[[!MinifyX?  &minifyCss=`1` &cssFilename=`style` &cssPlaceholder=`MinifyX.css` &cssSources=`css/main.css`]]
[[!+MinifyX.css]]

The documentation doesn’t say anything about the browser cache issue. When the style file is updated, does MinifyX change the filename?

[dejaya]

I usually set things up like this, no Extras required:

Create a new System Setting called _version

Save it and give your new System Setting a value, say 9999:

Then in you head Chunk, add ?ver=[[!++_version]] to any CSS / JS file you want to be able to force updates to the client:

<link rel="stylesheet" href="assets/css/custom.css?ver=[[!++_version]]">

Now, any time you want to force an update to the group of files you added the ?ver=[[!++_version]] to … just change the _version number in your new System Setting.

I’ve been doing it this way for years and it works well for me.

Only downside might be that if you’ve got several files set up to get forced updates, but you’ve only changed one of them, it’ll still force the update to all of them. Not the end of the world IMHO unless you’re updating stuff constantly.

[cottagestuff]

That seems to my uneducated and aching brain to be a good solution. You need to manually update the version number each time, whereas the LastModified solution seemed to promise an automation of that. Have you tried the LastModified snippet/package? And do you know if MinifyX is irrelevant (because it doesn’t alter the style filename after update)?

[dejaya]

I haven’t used either, sorry.

The benefit of manually updating the System Setting is that you are in control of when the updates are being pushed out to the users.

You don’t want every client to be loading all your CSS / JS files every time they move between pages of your site.

Changing the System Setting means that the files will get pushed to each user once, until the number changes again or the cache expires.

I’m sure others out there might have other great solutions as it’s a problem we’ll all have faced.

[inside-creative]

You could always create your own snippet for this using filemtime. Something like:

<?php

$filePath = $modx->getOption('file', $scriptProperties);

if(!is_null($filePath) && file_exists($filePath)) {
    return $filePath . '?v=' . filemtime($filePath);
}

Then use it like:

<link rel="stylesheet" href="[[!cacheBust? &file=`path/to/style.css`]]">
<script src="[[!cacheBust? &file=`path/to/script.js`]]"></script>

(NOTE: Now tested)

[cottagestuff]

Neat. If I understand that, the cache at the visitor’s end is busted every time the page is loaded or every time MODX chooses to refresh its own cache. Perhaps that’s more busting than is really needed.

Provisionally, going to go with dejaya’s suggestion, relying on a single manual update of a system setting whenever clients with caches appear on the horizon, keeping the busting to a minimum.

[inside-creative]

The cache will be busted every time the file is modified. It’s just called uncached to allow it to check the file modified time on each page load. The parse time for this snippet is about 0.0034781 seconds, so doesn’t really affect page load times.

The Modx Manager uses a similar function to check a files last modified time.

[bruno17]

the result shouldn’t be any different to what lastModified does, since that is also working with filemtime

[cottagestuff]

You persuaded me. Will use that technique.

If it doesn’t already exist, it would help if there were a page in the MODX documentation somewhere summing up what the hive mind has decided is the best solution to this problem. Wordpress seems to have a version numerating system out of the box, and it would be nice to at least see some semi-official statement of what the MODX equivalent is. Or maybe it is there and I just couldn’t find it.

[bobray]

It seems to me that lastModified might be overkill if all you want to do is bust the cache by changing the query part of the URL, since it has a number of options and properties that it parses on every execution.

[bruno17]

There are two Extras, called lastModified.
One is a simple snippet, which the OP is talking about.
The other one is a more complex plugin. Not sure what that one really does.

[bobray]

Thanks, I only found the plugin. I’m not sure what it does either.