Andrew Nevins
(@anevins)
WCLDN 2018 Contributor | Volunteer support
You don’t need to add a unix stamp to the HTML. Browser caching can be cleared by hard refreshing, if it’s not clearing then you’re not facing browser caching and you don’t need to add a timestamp to the markup or resource file.
Can you clarify the specifics of how you added the script tag?
This isn’t a solution when we push a new tag to the live site… “Hey everyone on the internet who hasn’t visited our site since this new tag was added, clear your cache and cookies beforehand by hard refreshing!” (also hard-refreshing doesn’t clear your cache and cookies, it only forces your browser to re-download the source code).
The problem is users may not get the new tag… we want to ensure they do (remember this is a NEW tag their browser has never seen or downloaded).
Andrew, we added the script tag through a plugin that has a field to input the tag… it merely puts the tag in the head tag. If we didn’t use the plugin, then I would have written source code to enter the tag, but we don’t want to have to edit source code to add/remove/edit that, we want it editable through the plugin.
Andrew Nevins
(@anevins)
WCLDN 2018 Contributor | Volunteer support
That’s not what I intended. If you’re facing a problem where your HTML is being cached then it’s probably not a typical browser caching problem.
Andrew Nevins
(@anevins)
WCLDN 2018 Contributor | Volunteer support
What is in your htaccess file?
Andrew, let me better explain:
1. Typical scenario: A previously-downloaded and utilized HTML script tag with a src attribute (downloaded the very first time a user hits the webpage) runs the src URL JavaScript properly. Then on the server that JavaScript file gets some code changes, the user hits the site again, sees the tag URL is the same and just uses the cache code. Appending a random number or timestamp to the tag’s URL will force the browser to re-download the script and run the updated code.
2. Our scenario: The HTML script tag was never loaded on the user’s browser’s initial page load because it didn’t exist at the time. The user hits the page again, but this time even though the new tag has been added on the server, it’s not fetched or added by the browser.
How would adding a random number or timestamp to the src URL force the browser to refresh something it never downloaded initially? The whole point of adding that number is so the browser sees a different URL than before so it things it’s downloading a new file; but if it never sees the tag to begin with (or on another page hit), and is just loading whatever HTML was in its cache at the time, it will not download the tag the first time.
If I’m not understanding how browsers fetch newly-added tags, please explain how adding a number to the end of the tag’s src URL forces it to do that.
My only solution to them was tell them to hit Ctrl+F5 to force the browser to fetch ALL of the current HTML, including new tags.
-
This reply was modified 6 years, 3 months ago by davecan.