Updating asset files after launch, a forum discussion on Jojo CMS. Join us for more discussions on Updating asset files after launch on our Administration (backend and configuration) forum.
You must be logged in to post a reply
| |
Hi guys,
How do you push updates to the asset files (CSS/JS) after launching a site? Eg once everyone has cached copies of these files with distant expire headers.
Does Jojo have a native way to do this that I've simply overlooked?
How do you push updates to the asset files (CSS/JS) after launching a site? Eg once everyone has cached copies of these files with distant expire headers.
Does Jojo have a native way to do this that I've simply overlooked?
The full proof way Harvey showed me was to put a local copy of the head.tpl into the theme and then add a get variable after it.
i.e. style.css?v=1
Then each time you push a change you can up the number. The new URL means that the old cache is ignored.
Also there is a cache figure in the options that you can make a really low number for a few days.
To be honest, most of the time I just educate the client about Crtl+F5.
Hope that helps.
p.s. one of these days I want to set up a way to make Jojo up the number automatically
i.e. style.css?v=1
Then each time you push a change you can up the number. The new URL means that the old cache is ignored.
Also there is a cache figure in the options that you can make a really low number for a few days.
To be honest, most of the time I just educate the client about Crtl+F5.
Hope that helps.
p.s. one of these days I want to set up a way to make Jojo up the number automatically
If you not living on the edge you taking up too much space.
Thanks Jai,
During production using CTRL+F5 is fine but once it goes public it's not an option.
I thought about the "?v" variable and making it semi automated. Eg when a file (eg styles.css) is built the most recent modified time from the source files is applied to the cached file. Then when displaying the links in head.tpl I thought about using hooks or whatever (I'll have to add support for additional vars to template hooks) to add the "?v=" then the modified timestamp for each asset file but only if it's more recent than the current date minus cache length.
This would let us make changes, hit CTRL+F5 and everyone would get the updates. The path would be changed to include "?v=" but would eventually drop back to just the clean file path.
Argh, when I have time.
On a side note, with Smarty you could run a hook from within a template and assign more stuff to Smarty then use it after the hook. You can't seem to do that with Dwoo. This was handy for putting the code to fetch sidebar content inside a hook so it was only fetched/assigned if the template triggered it.
During production using CTRL+F5 is fine but once it goes public it's not an option.
I thought about the "?v" variable and making it semi automated. Eg when a file (eg styles.css) is built the most recent modified time from the source files is applied to the cached file. Then when displaying the links in head.tpl I thought about using hooks or whatever (I'll have to add support for additional vars to template hooks) to add the "?v=" then the modified timestamp for each asset file but only if it's more recent than the current date minus cache length.
This would let us make changes, hit CTRL+F5 and everyone would get the updates. The path would be changed to include "?v=" but would eventually drop back to just the clean file path.
Argh, when I have time.
On a side note, with Smarty you could run a hook from within a template and assign more stuff to Smarty then use it after the hook. You can't seem to do that with Dwoo. This was handy for putting the code to fetch sidebar content inside a hook so it was only fetched/assigned if the template triggered it.
I messed round for a couple of hours and came up with this. It's a little messy because of the various caching methods in Jojo, but it's functional.
Files (CSS in particular) are cached to cache/public/<md5hash>.css instead of cache/css/styles.css. I'm not sure why this is, but the patch makes CSS files cache to the main directory like most other files. It still caches to the public cache dir for now, just like the JS one.
The plugin wraps a small hook around asset urls in head.tpl
<link rel="stylesheet" type="text/css" href="{cycle values=$NEXTASSET}{jojoAsset file="css/styles.css"}" />
this hook...
I've also made the stitcher try and apply a modified time when it generates cache files based on the most recently modified source file.
Notes
After updating an asset file you need to CTRL+F5 to generate a new cache file. After that all other visitors should get the new file, regardless of their expires headers.
You can CTRL+F5 as much as you please, the "version number" won't update until the file is actually changed.
You don't actually need the "file=" in there, but it's there to be consistent with jojoHook.
I haven't taken into account the database cache yet.
I run almost entirely in Linux, so haven't tested this on a Windows server. "touch" should work, but like I said, I haven't tested it on Windows.
I thought about doing more thorough checks in the hook to do away with the need to CTRL+F5. This would be useful for updating plugin/core assets and not having to refresh caches on lots of sites. But this would happen very rarely and isn't worth the overhead of checking modified times on every source file for the stitched assets. It'd also mean duplicating the list/looping of asset source files and it could break if something new (just like the modenizer files) were added to one but not the other. Since (in my use-cases at least) it's usually site specific files that are updated after launch, CTRL+F5 seems reasonable for triggering the updates.
Anyway...
I'm going to test this more thoroughly and see how it runs. If I'm heading off in the opposite direction to everyone else, let me know. Suggestions are most welcome.
Files (CSS in particular) are cached to cache/public/<md5hash>.css instead of cache/css/styles.css. I'm not sure why this is, but the patch makes CSS files cache to the main directory like most other files. It still caches to the public cache dir for now, just like the JS one.
The plugin wraps a small hook around asset urls in head.tpl
<link rel="stylesheet" type="text/css" href="{cycle values=$NEXTASSET}{jojoAsset file="css/styles.css"}" />
this hook...
- finds the cached file
- gets its modified time
- compares the modified time to the cache length setting and 28800 (default hardcoded content expiry for the asset files)
- adds "?v=timestamp" to the path if the file has been modified more recently than the cache length
- or adds "?r=randomnumber" to the path if _DEBUG is on
I've also made the stitcher try and apply a modified time when it generates cache files based on the most recently modified source file.
Notes
After updating an asset file you need to CTRL+F5 to generate a new cache file. After that all other visitors should get the new file, regardless of their expires headers.
You can CTRL+F5 as much as you please, the "version number" won't update until the file is actually changed.
You don't actually need the "file=" in there, but it's there to be consistent with jojoHook.
I haven't taken into account the database cache yet.
I run almost entirely in Linux, so haven't tested this on a Windows server. "touch" should work, but like I said, I haven't tested it on Windows.
I thought about doing more thorough checks in the hook to do away with the need to CTRL+F5. This would be useful for updating plugin/core assets and not having to refresh caches on lots of sites. But this would happen very rarely and isn't worth the overhead of checking modified times on every source file for the stitched assets. It'd also mean duplicating the list/looping of asset source files and it could break if something new (just like the modenizer files) were added to one but not the other. Since (in my use-cases at least) it's usually site specific files that are updated after launch, CTRL+F5 seems reasonable for triggering the updates.
Anyway...
I'm going to test this more thoroughly and see how it runs. If I'm heading off in the opposite direction to everyone else, let me know. Suggestions are most welcome.
Attached Files
I've been hammering it all weekend with nothing but excellent results, but still would like to clean up the issue with CSS files being cached differently to JS files before I put this in the repo.
Is it intentional? Or a lapse? I can clean it all up but I don't want to go backwards on someone elses code.
Edit: FYI I've been testing it on a few sites but mainly over here along with Gravatar support.
Is it intentional? Or a lapse? I can clean it all up but I don't want to go backwards on someone elses code.
Edit: FYI I've been testing it on a few sites but mainly over here along with Gravatar support.
| Back to Forum Index : Back to Administration (backend and configuration) |
|
