Closed bob2517 closed 9 months ago
I'm going to check the load-config command and add the option there too if it's appropriate.
It probably won't be "?v=" - I'll make it "_acssCV=" (CV for Config Version) so it shouldn't clash with any other potential parameters on the config file URL - just incase there's one there already, or in the case of config files being generated on-the-fly on the server.
I'll also allow a pre-determined value to be added as a noCache value.
For example, on the docs site I always append the version number of the core onto any config files when going live, but use a timestamp of the config file when developing offline.
However, I don't think it makes a difference because I think caching stops being applied whenever there is any "?blah" on the end of a URL. I dunno - it's in the lap of the browser gods - I just want it to bypass caching in a vaguely sensible way with the limitations there are. So I guess it depends on the implementation of the cache, which has a tendency to change once in a while when someone gets an idea. I'm going to put this in anyway...
The alternative syntax that I'll implement along with "noCache: true" will be:
ActiveCSS.init({
configLocation: "/activecss/config.txt",
noCache: "randomvalue"
});
Actually, I can see someone typing in noCache: "true" and noCache: "false" and then submitting an issue.
So, we will still keep true and "randomstring", as it's the cleanest method. But we'll get "true" and "false" converted to their boolean values internally for people who haven't studied up on objects yet.
Also - with no noCache option, there won't be any caching formula applied. It will just work with what people have already, so this is a backward-compatible upgrade, and makes the most sense to do it that way regardless.
Was thinking whether or not this was even needed. Why not just enforce no caching in the dev area and have caching in the production area.
The reason why it's a better idea to have a manual implementation is that in my experience, it's when clients complain that they can't see changes live that the whole issue turns into something more serious. Then you have to remove caching from the live system from the JS end or do something special in the server setup. Either way, it's a thing when you are pushing up a lot of frequent changes to JS/ACSS config and your file names are staying the same.
So this won't be an "automatic" upgrade. The ability to turn off caching on/off manually for production sites is a needed thing.
Either that, or tell developers that they need to change their config file names every time they make a change to code. And that's not always a particularly practical solution.
Closing - unnecessary unless it's asked for.
When developing in ACSS, it's been reported that browsers tend to cache config files, which we don't want in developing. The only solution is to clear the cache, or get the user to clear the cache. It's not just a problem with ACSS, it can be a problem with any website.
I get this when I develop with ACSS using the JS load method, and I've had a report from elsewhere that this happens.
My solution in the past is to put in "'?v=' + randomString" after each config file, but you shouldn't really have to manually set this up.
So I'm going to add an option of noCache, like:
That will automatically append "?v=" + randomString to any config files in the list.
This at least gives a hard solution to caching nightmares, even if it is a bit severe. If anyone has any better ideas then let me know.