I am using PhantomJS for testing purposes. I need PhantomJS to remove all the information related to the previous session after the following command,
phantom.exit()
Actually, it does that and it removes all the cookies, cache and the history in fact. But, It does not remove the saved information for localStorage command automatically. I need to go to the default path for saving this information and remove the file manually. I am wondering if there is any automatic way for removing this file. I tested following ways but none of them worked for me.
first of all, I used the following command to set the new path for this information, but PhantomJS did not care about it and just used its previous saved information again.
--local-storage-path = path
second, I used the page.open part of PhantomJS to clear the path using following command which did not work either for me.
localStorage.clear();
It's always good to clear localStorage after you're done with testing. You have to keep in mind that you can have multiple pages open in PhantomJS at the same time, but localStorage is only bound to a specific domain.
The localStorage.clear(); has to be executed on the page and not in phantom context:
page.evaluate(function(){
localStorage.clear();
});
So every time before you exit the script, you should clear the localStorage (maybe multiple times depending on how many domains you visited). Alternatively, you can try to do this at the beginning of your script/page load, but it will be hard to do it well. A page must already have a target URL, but the page cannot be yet loaded. Otherwise, the clear may come at a time when the page javascript already executed. Then this should probably be done only once per domain. Otherwise, navigation over different pages of a site will be broken.
Another simple solution would be to use the fs module to delete all localStorage files in the Ofi labs directory at the beginning of the script, but this might delete the localStorage of pages that you didn't want deleted.
If you're using phantomJS 1.9.8 on linux x64 you can test this binary which has the localStoragePath fix included: https://github.com/PatrickHuetter/phantomjs/releases/tag/1.9.8-fixedStoragePath
If you're using phantomjs on another operating system you could checkout my fork and compile it on your plattform. https://github.com/PatrickHuetter/phantomjs/tree/localStoragePathFix
PhantomJS 2.0 already has this fix included, so you can go with the official binary if you're using the 2.0 version or newer.
Related
This is the logout logic, here the key logoutoverlay, is set in the local storage.
<div className="logout">
<NavLink href={propsData.userDataTopNavLinkList.logout} onClick={() => {
localStorage.removeItem("manage");
localStorage.removeItem("token");
localStorage.removeItem("auth");
localStorage.removeItem("AccountInfo");
localStorage.removeItem("successfullySet");
localStorage.removeItem("userImpression");
localStorage.removeItem("cartCnt");
localStorage.removeItem("callDuration");
localStorage.removeItem("customGeoIPInfo");
localStorage.removeItem("geoipInfo");
localStorage.setItem("logoutoverlay","form overlay")
}}> {dictionary.t("Logout", "LOGOUT")}</NavLink>
</div>
Here inside Main.js the local localStorage is checked for the key logoutoverlay
if(localStorage.getItem("logoutoverlay"))
{
logoutDataLayer(localStorage.getItem("logoutoverlay"));
localStorage.removeItem("logoutoverlay");
}
and inside dataLayerAnalytics.js the item is being pushed to the data layer
export const logoutDataLayer = (logoutplace) => {
let logoutDatalayer = {
"event": "loyaltyLogout",
"logoutContext": logoutplace
}
window.dataLayer.push(logoutDatalayer);
}
All of this is working fine on my local machine. But after I deployed it to the production environment the localStorage.removeItem("logoutPlace") inside the Main.js is not getting executed and the code can't reach localStorage.removeItem("logoutPlace") as well. That's why the item "logoutoverlay" doesn't get removed from the local storage.
And since I am unable to replicate this issue on my local system, I can't even debug the code.
Introduction
Your problem statement is that
localStorage.removeItem("logoutoverlay");
is not executed on prod, but it is successfully executed on your dev env. Since we do not have your source-code we cannot tell you for sure what the problem is, but we can tell you how you can find out what the problem is. This answer focuses on the method of finding out what the issue is.
How to debug the client-side of prod
If your source-code is available on prod, then you can debug your client-side code, written in Javascript via the Sources tab of your browser's dev tools. You can reach it via:
right-click anywhere on the page -> click on inspect/inspect element (the text varies accross browsers) -> dev tools appear, usually with the Elements tab being shown by default -> click on Sources -> find Main.js and click on that
Now, in your Main.js you can click on the left-most edge of the source-code's lines to put in breakpoints and from there on you can debug.
If the client-side code is minified on prod, then you have several options to proceed. You could download the minified script into your dev env and temporarily use that to debug. Or, you can implement a testing mode on prod, which would allow you to load and use the original, not minified js code, which would allow you to debug your prod's client-side code in the browser.
Make sure you compare apples with apples
It is certainly possible that your server has a different version of your client-side code, which behaves differently. Make sure that you have equivalent source-code on the server as in your dev env, since, if these are different, then it is unsurprising that they behave differently. To do so, you need to:
clear your browser cache or open the page in incognito mode in order to avoid being misled by old file versions being loaded into your browser either on server or client-side
clear your server cache if you have one, since that prevents new code from being used for a while
download Main.js from the server and study it, possibly comparing it to the Main.js you have on the dev environment
if you don't use a version controller, then it is high time you start using one. If you have a version controller, then, using it look at the commit hash of the latest commit and the branch being in use at both, maybe pulling/pushing in order to ensure that the versions are the same
Check user state on client-side and server-side
This is the problematic section of your code:
if(localStorage.getItem("logoutoverlay"))
{
logoutDataLayer(localStorage.getItem("logoutoverlay"));
localStorage.removeItem("logoutoverlay");
}
Maybe on your server's localStorage you do not have logoutoverlay. Maybe you have logged in to your server before that value was tracked and never logged in since. If it's just a matter of user state, then basically the problem is just coping with differences of versions.
Be careful about user states when you deploy session logic changes
You implement some logout logic which assumes some values inside localStorage. What if that value is not inside localStorage, because the user logged in before the change that creates it was deployed. The last thing you want is to have some broken user sessions, so make sure that your work covers the case when users logged in before your deploy and their session still exists. If during deployment all sessions are destroyed, then this is not an actual concern.
Afternoon All,
A bit of background - I'm building a custom calendar for a company where jobs can be scheduled and engineers can access it from their mobile to know when and where they're going. They previously used Google calendar but now want something bespoke.
All is fine until somebody loses phone signal and gets a horrible offline page in Chrome and can't access any information. What I'm wanting to do is have it save an offline version of the calendar but also update it when they re-visit it with a better connection - as job times often change.
I've tried saving the page and enabling offline mode in Chrome but the page doesn't update until you manually clear the cache so no good.
I've tried adding some javascript to hard refresh the page in the hope it clears the browser cache but again it doesn't update the page.
<script>location.reload(true);</script>
I read about cache manifests and have tried that too but although it feels like it wants to work it also doesn't update the page until I go to chrome://appcache-internals and remove the file.
CACHE MANIFEST
/calendar.php
/css/style.css
Neither PHP or Javascript headers work either as they either don't update the file on re-visit or simply don't save any files in the first place.
header("Cache-Control: no-cache, must-revalidate");
<meta http-equiv="Cache-Control" content="no-store" />
As far as I can tell there's no way to manually delete a user's website cache and re-download it and once the cache has been saved there's no way to force it to update. If you set it to expire then it's not there to access and you don't know when they will next have a connection to update so I'm going round in circles.
I've been trying for several hours now to find something that works and can't believe it's not a simple thing to do and therefore I'm now throwing myself on the mercy of you fine coders to point me in the right direction before my boss hangs me from the first floor window.
Many Thanks
UPDATE
Using what Clarence said as a starting point I came up with the following code in my appcache file:
CACHE MANIFEST
CACHE:
/css/bootstrap.css
/css/style.css
/calendar.php
NETWORK:
/calendar.php
# UPDATED: 03-04-2018 15:55:57
What this does is caches the calendar.php file BUT if there is a connection then it has another look at those files under the NETWORK heading so I also put it in there. If the appcache files hasn't changed then the browser doesn't bother looking so I've used the following code to write to the file when a job has been altered:
$manifest = file_get_contents(__DIR__ . '/cache.appcache');
$newFile = substr($manifest, 0, (strpos($manifest, '# UPDATED: ') + 11));
$newFile = $newFile . date('d-m-Y H:i:s');
file_put_contents('cache.appcache', $newFile);
Basically just searches the file for "UPDATED" and inserts a new time thus updating the file and requiring a re-check from returning users.
Somebody might point out this isn't the right way to do it but it seems to work from my tests so would like to thank those that contributed.
Have you tried changing the contents of your cache manifest whenever you change one of the files? The APPCACHE is a bit finicky when it comes to changes in the files and can be troublesome to handle. I usually include a comment with a timestamp and version number just to force it to update in the browser, like so:
CACHE MANIFEST
# 01-01-2001 v1.0 (Change whenever you need to force an update of the cache)
CACHE:
/css/file.css
/js/file.js
NETWORK:
*
FALLBACK:
well the best option would be creating a PWA. This should include the manifest files and Service workers as well. It enables you to cache the content of the websites and update it once the connection has been reestablished. However it is very new and would require a decent amount of research into service workers. If you need any help regarding the development of PWA would be happy to help to an extent
The only way without HTTP-Header is to rename files continuously.
And the depending HTML tag file-name.
So the files are loaded afresh.
With HTTP-Header look here.
How to control web page caching, across all browsers?
You can do this whenever a new change in the calendar was made.
I have been sitting here for almost an hour here to test the website I'm building. Since I wanted to see the new changes from my code I reloaded, but it was reloading old one. I opened the devetools to hard reload and empy cache hard reload, they both load my old code. I went to incognito mode and it did the same thing. I went to devtools again to disable the cache from the settings and checked the disable cache in the network tab; it still cache my old code. Add-ons to clear the cache didn't work as well. Man, I haven't had this problem before and it only happened last night and it's worst today.
I'm so lost now since chrome doesn't load my new changes from my javascript file. Is there a solution for this?
One solution for this problem is to force reloading the resource in order to avoid the cache. You can get this modifying the url with http get parameters:
Change:
<script src="myscripts.js"></script>
to:
<script src="myscripts.js?newversion"></script>
Where newversion can be any string as it will be ignored. A useful option is to use the date, or version, of your code.
I found this workaround particularly useful when I came across this same problem and wanted to ensure that all clients (not just my own browser!) would run the new version of the code.
I think there's an even better way:
You can use PHP to add the last modification date of your JavaScript file to the URI of that file.
<script src="js/my-script.js?<?php echo filemtime('js/my-script.js'); ?>">
</script>
The browser will receive:
<script src="js/my-script.js?1524155368"></script>
The URI of the file will automatically change if the file is updated.
This way the browser can still cache unchanged files while recognizing changes instantly.
Are you using any type of compilation tools (like gulp or grunt)? It's possible that there is an error in your code, and the tool is not compiling the updated code.
Otherwise, the solution #airos suggested should work. Appending any unique query string to the reference of your JS will always serve a fresh copy on first reload (since the browser will be caching a new URL).
I'm using the MEAN stack (mongo, express, angular and node). I'm deploying relatively frequently to production...every couple of days. My concern is that I'm changing the client side code and the API at times and I would rather not have to ensure backwards compatibility of the API with previous versions of the client code.
In such a scenario, what is the most effective way of ensuring that all clients reload when I push to production? I have seen that Evernote for example has a pop-up that says something along the lines of please reload your browser for the latest version of Evernote. I would like to do something similiar...do I need to go down the path of socket.io or sock.js or am I missing something simple and there is a simpler way to achieve this?
Update:
AppCache was deprecated summer 2015 so the below is no longer the best solution. The new recommendation is to use Service Workers instead. However, Service Workers are currently still experimental with sketchy (read: probably no) support in IE and Safari.
Alternatively, many build tools now seamlessly incorporate cache-busting and file "versioning" techniques to address OPs question. WebPack is arguably the current leader in this space.
This might be a good use case for using HTML5's AppCache
You'd probably want to automate some of these steps into your deployment scripts, but here is some code you might find useful to get you started.
First, create your appcache manifest file. This will also allow you to cache resources in the client's browser until you explicitly modify the appcache manifest file's date.
/app.appcache:
CACHE MANIFEST
#v20150327.114142
CACHE:
/appcache.js
/an/image.jpg
/a/javascript/file.js
http://some.resource.com/a/css/file.css
NETWORK:
*
/
In app.appcache, the comment on line #v20150327.114142 is how we indicate to the browser that the manifest has changed and resources should be reloaded. It can be anything, really, as long as the file will look different to the browser from the previous version. During deployment of new code in your application, this line should be modified. Could also use a build ID instead.
Second, on any pages you want to use the appcache, modify the header tag as such:
<html manifest="/app.appcache"></html>
Finally, you'll need to add some Javascript to check the appcache for any changes, and if there are, do something about it. Here's an Angular module. For this answer, here's a vanilla example:
appcache.js:
window.applicationCache.addEventListener('updateready', function(e) {
if (window.applicationCache.status == window.applicationCache.UPDATEREADY) {
// Browser downloaded a new app cache.
// Swap it in and reload the page to get the latest hotness.
window.applicationCache.swapCache();
if (confirm('A new version of the application is available. Would you like to load it?')) {
window.location.reload();
}
}
else {
// Manifest didn't changed. Don't do anything.
}
}, false);
Alternatively, if AppCache won't work for your situation, a more ghetto solution would be to create a simple API endpoint that returns the current build ID or last deployment date-time. Your Angular application occasionally hits this endpoint and compares the result to it's internal version, and if different, reloads itself.
Or, you may consider a live-reload script (example), but, while very helpful in development, I'm not sure how good of an idea it is to use live/in-place-reloading of assets in production.
I will tell you my problem first then I will recommend a tentative solution. I wanted to force my user to log out and then log in when a production build is been deployed. At any point in time, there will be two versions of software deployed on production. A version which software which FE knows and a version which Backend knows. Most of the time they would be the same. At any point in time if they go out of sync then we need to reload the client to let the client know that a new production build has been pushed.
I am assuming 99.99% of the time the backend would have the knowledge of the latest version of the deployed software on production.
following are the two approaches which I would love to recommend:-
The backend API should always return the latest version of the software in the response header. On the frontend, we should have a common piece of code that would check if the versions returned by the API and that present on the FE are the same. if not then reload.
Whenever a user logs in. the BE should encode the latest software version in the JWT. And the FE should keep sending this as a bearer token along with every API request. The BE should also write a common interceptor for every API request. which would compare the software version in the JWT received from the API request and the
Maybe you can add hash to your client code file name. eg app-abcd23.js.
So the browser will reload the file instead of get it from cache. or you can just add the hash to url.eg app.js?hash=abcd23 but some browser may still use the cached version.
i know rails has assets-pipline to handle it, but i am not familiar with MEAN stack. there should be some package in npm for that purpose.
And i dont think it is really necessary to use socket.io if you want to notify the user their client code is out of date. you can define your version in both html meta tag and js file,if mismatch, show a popup and tell the user to refresh.
Try to limit your js/files to expire within smaller periodic time, ie: 1 days.
But in case you want something that pop-out and tell your user to reload (ctrl+f5) their browser, then simply make a script that popup that news if you just changed some of your files, mark the ip/session who have just reload/told to reload, so they will not be annoyed with multiple popup.
I was facing the same problem recently. I fixed this by appending my app's build number with my js/css files. All my script and style tags were included by a script in a common include files so it was trivial to add a 'build number' at the end of the js/css file path like this
/foo/bar/main.js?123
This 123 is a number that I keep track of in my same header file. I increment it whenever I want the client to force download all the js files of the app. This gives me control over when new versions are downloaded but still allows the browser to leverage cache for every request after the first one. That is until I push another update by increment the build number.
This also means I can have a cache expiry header of however long I want.
Set a unique key to local storage during the build process
I am using react static and loading up my own data file, in there i set the ID each time my content changes
Then the frontend client reads the key with from local storage
(if the key does not exist it must be the first visit of the browser)
if the key from local storage does not match it means the content has changed
fire line below to force reload
window.replace(window.location.href + '?' + key)
in my case i had to run this same line again a second latter
like
setTimeout( (window.replace(window.location.href + '?' + key))=> {} , 1000)
full code below:
const reloadIfFilesChanged = (cnt: number = 0, manifest: IManifest) => {
try {
// will fail if window does not exist
if (cnt > 10) {
return;
}
const id = localStorage.getItem('id');
if (!id) {
localStorage.setItem('id', manifest.id);
} else {
if (id !== manifest.id) {
// manifest has changed fire reload
// and set new id
localStorage.setItem('id', manifest.id);
location.replace(window.location.href + '?' + manifest.id);
setTimeout(() => {
location.replace(window.location.href + '?' + manifest.id + '1');
}, 1000);
}
}
} catch (e) {
// tslint:disable-next-line:no-parameter-reassignment
cnt++;
setTimeout(() => reloadIfFilesChanged(cnt, manifest), 1000);
}
};
I'm trying to debug a Javascript written in the Mootools framework. Right now I am developing a web application on top of Rails and my webserver is the rails s that boots WEBrick.
When I modify a particular tree.js file thats called with in one a mootools init script,
require: {
css: [MUI.path.plugins + 'tree/css/style.css'],
js: [MUI.path.plugins + 'tree/scripts/tree.js'],
onload: function(){
if (buildTree) buildTree('tree1');
}
},
the changes are not loaded as the headers being sent to the client are Last Modified: 10 July, 2010..... which is obviously not true since I just modified the file.
How do I get rid of this annoying caching. If I go directly to the script in my browser (Chrome) it doesn't show the changes until I hit refresh, but this doesn't fix my problem when I go back to my application and hit refresh, it still loads the pre-modified script.
This has happen to me also in FF, I think it is a cache header sent by the server or the browser itself.
Anyway a simple way to avoid this problem while in development is adding a random param to the file name of the script.
instead of calling 'tree/scripts/tree.js' use 'tree/scripts/tree.js?'+random that should invalidate all caches.
As frisco says, adding a random number in development does the trick but you will likely find that the problem still affects you production. You want to push new JavaScript changes to your users but can't until their browsers stop caching the file. In order to do this, just get the files mtime and add that as the random string. This will only change when the file is modified and so the JavaScript will be loaded from cache if it has not been changed or it will be loaded from the server, if it has.
PHP has the function filemtime but as I'm not familiar with Ruby, I'm afraid I can't help you further in that direction (sorry!). However, this answer seems to accomplish what you want.
Try the Ctrl+F5 trick. To avoid hitting browser cache.
More info here:
What requests do browsers' "F5" and "Ctrl + F5" refreshes generate?