Re: auto 'refresh' question
There is a script that Acorn can supply when he sees this post. You add it to your home page. Acorn will explain how.
Re: auto 'refresh' question
There's a sticky Thread for this in this very Forum.
Acorn
Re: auto 'refresh' question
Quote:
Originally Posted by
Acorn
There's a sticky Thread for this in this very Forum.
Acorn
Thank you Acorn.
Re: auto 'refresh' question
Joned (and others), the main trick is to check and adjust repeatedly locally and then publish when absolutely sure.
Acorn
Re: auto 'refresh' question
I have had the same issue. Even thought it is the server side of cache refresh but it was not. It does take some time to update itself, sometimes too long for the likes of anyone, including the client. I can only assume it is Xara only and not other platforms.
Re: auto 'refresh' question
Quote:
Originally Posted by
behzad
I have had the same issue. Even thought it is the server side of cache refresh but it was not. It does take some time to update itself, sometimes too long for the likes of anyone, including the client. I can only assume it is Xara only and not other platforms.
behzad, I do not follow.
If you publish and republish to the server, there will always be a delay for the server cache to be purged. Some SPs are a matter of minutes. If you use Cloudflare and do not force the server cache to be purged then the propagation out to the edge servers can take hours.
Once that has happened, if your browser has cached anything prior, there is little that can change this other than purging the browser cache (Ctrl+F5), which is not helpful as the onus is then on the end viewer.
Probably the worst thing to do is set the web pages to have a <meta> Tag forcing no cache as ever access download all the page assets from the server every time.
It is effective if you can guarantee all viewers access your site in a given timeframe so you know when to re-enable caching.
It might be what you should be doing during a defined development phase but it has to be caveated to the client as it is naff for performance.
About the only recourse you have is to time expire content through the .htaccess file that you should have in your root directory.
The .htaccess file could have this or similar added:
Quote:
# Set long expire headers for better browser caching
<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType text/css "access plus 30 days"
ExpiresByType text/javascript "access plus 7 days"
ExpiresByType application/x-javascript "access plus 7 days"
ExpiresByType application/javascript "access plus 7 days"
ExpiresByType image/x-icon "access plus 7 days"
ExpiresByType image/vnd.microsoft.icon "access plus 7 days"
ExpiresByType image/png "access plus 30 days"
ExpiresByType image/gif "access plus 30 days"
ExpiresByType image/jpeg "access plus 30 days"
ExpiresByType image/jpg "access plus 30 days"
ExpiresByType application/x-shockwave-flash "access plus 30 days"
</IfModule>
It is up to you, the designer, to establish what are good values during your development cycle and what the equilibrium ones should be.
The other approach might be to ensure the Entity tags are active, using a form like:
Quote:
FileETag MTime Size ExpiresActive on
ExpiresDefault "access plus 1 year"
or FileETag All.
Etags use HTTP to pass a token to the server to see if the required file has the same token. If so no download, otherwise the asset is served overwriting the local cache.
The process repeats for every change.
Using ETags for every asset can slow things down such statements should be wrapped in a <Filesmatched> directive.
Ultimately, the caching is nothing to do with Xara as you are in control of what you have published.
The one change I have asked of Xara is to apply versioned URLs to the assets that do change frequently.
This is probably the best technical guide for a deep dive: https://web.dev/http-cache/.
Way too deep for most, which is why I offer up homespun as they reinforce good habits.
One thing that is fairly simple to add for a development session is a Refresh button with this Link: javascript: location.reload();
All this does the same as Ctrl+F5 but at least it empowers the viewer.
Acorn
Re: auto 'refresh' question
Another thing you could do but might be inconvenient is to use the first page in the design for version/caching control while you're working on the site. So for example name your first page "sitev1" and then have the second page in the design as your index.html. Then when you publish the htm_files folder name will match the filename of your first page so it would be "sitev1_htm_files" and the next time you do a major update change it to "sitev2" which then would create "sitev2_htm_files". You wouldn't want to do it for minor changes but perhaps after a lot of major changes. This would avoid caching issues as all links to file assets would change to the new folder name. Note this wouldn't work with a site navbar set to link to all pages automatically and you would need to manually delete old htm_files folders manually after a while. Normally though I would just get into the habit of telling the customer to Ctrl+F5 to clear cache every time emailing them with significant changes, although if they are previewing on a tablet or mobile it's less straight forward digging around in various browser menus to clear cache.
Re: auto 'refresh' question
Thank you acorn and xtom and others, but when this happened to me years ago. Different browsers gave different results. So what gives?
Re: auto 'refresh' question
Quote:
Originally Posted by
xtom
Another thing you could do but might be inconvenient is to use the first page in the design for version/caching control while you're working on the site. So for example name your first page "sitev1" and then have the second page in the design as your index.html. Then when you publish the htm_files folder name will match the filename of your first page so it would be "sitev1_htm_files" and the next time you do a major update change it to "sitev2" which then would create "sitev2_htm_files". You wouldn't want to do it for minor changes but perhaps after a lot of major changes. This would avoid caching issues as all links to file assets would change to the new folder name. Note this wouldn't work with a site navbar set to link to all pages automatically and you would need to manually delete old htm_files folders manually after a while. Normally though I would just get into the habit of telling the customer to Ctrl+F5 to clear cache every time emailing them with significant changes, although if they are previewing on a tablet or mobile it's less straight forward digging around in various browser menus to clear cache.
Tom, that is a very good approach.
May I refine it a tad?
- Create your website. [Assume first page is index.htm, else change (4.1) to align]
- Create a blank page and drag to the first page position.
- Rename to version100. [Click the Rename button if Xara complains]
- In Web Properties > Page > HTML code (head), add:
- <meta http-equiv="refresh" content="0; url=index.htm" />
- Publish
===============
- Version Update:
- Rename the first page to the next increment. [version101]
- Republish
===============
- Directory Structure:
- Version 100:
- version100.htm ==> index.htm
- index.htm, using
- version100_htm_files/ folder
- Version 101:
- version101.htm ==> index.htm
- version100.htm ==> index.htm
- index.htm, using
- version101_htm_files/ folder
- version100_htm_files/ folder (no longer used)
- ...
All you, as designer, have to do is rename the first page when making important site changes.
As a bonus, you can add any design notes and changes to the version page.
Very clean, easy to implement and maintains a recoverable history.
Do note, index.htm and all other site pages are always overwritten as their referencing URLs need to point to the latest assets folder.
At the end of development, move the first page to the end and republish.
For further development, put last to first and increment.
Acorn