-
-
Notifications
You must be signed in to change notification settings - Fork 477
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
301 redirection doesn't update browser url #510
Comments
Hi @lucasflorian, Interesting case: I will look into it soonly. |
Hi @lucasflorian, I can confirmed it's a bug, mostly an unsupported feature I mean 😄 ! Page is well prefetched/displayed, even with For now, you can manually update the history in your code using: barba.history.add('sub/suburl/');
|
I've had the same issue ( just that in my case its a 302 as the page is only accessible to authenticated users ). Is there any way I can get the response status code and the location header inside the barba hooks (or from anywhere else) so that I can check if there is a redirect, and then change the url to the Location header using the history api? |
Hello Xavier, I presume that you are referring to requestError in that link? We are having the same problem as @arun07as: some of our pages trigger a 302 redirect. Barba follows the redirect but does not update the url which is a problem for us. On pages which require authentification, we have started returning a 401 error instead of a 302 redirection. This gets picked up by requestError so we can access the url that the user was trying to open, and forward some_parameters to a 401 page using something like barba.go('/401?some_parameters'). This is perfect because our 401 page can then use those parameters to redirect the user back to the original page upon sign-in. If we were not able to update the URL, this would not work. On some other pages, we have genuine innocent 302 redirects and returning an 4xx does not make sense. For those pages, requestError does not trigger so we are stuck and cannot update the url. This is a problem as the user sometimes ends up with a url which is not valid. Would the only way around this is to be able to access the status code, even when there was no error? |
Hi @goyavo, Probably accessing the code will help developers deal with this kind of issue. We are all a little busy right now, sorry for the delay. |
Thought I'd dig in on this and see if I could throw something together quickly but it looks like this would require a much bigger restructuring of the code to support 301/302 redirects than I expected. I'll write up an outline of what I think needs to be done then maybe either @xavierfoucrier or @thierrymichel could review it. I maintain a custom Express framework with which my team and I are building many sites (we've got 19 done and 30 or so lined up.) While I'd love to build our sites on something newer like Gatsby or Next.js that would be a huge migration for us, so Barba is a perfect solution for now to get a more modern single-page-app experience. We've already launched one site with Barba and we're looking to bake it into all future sites. |
Any update on this? Working with Barba on a WP install I'm stuck if my 301's don't update the URL. |
If others fall on that problem, here is a (very) dirty fix. I put the supposed page URL in the code, and check if both URLs match before showing the page. If the supposed URL is not the same as the JS readable URL (I've put that it only checks the last chunk, it should do) force a redirect of the page. barba.init({
transitions: [
{
name: "default-transition",
leave(data) {
return gsap.to(data.current.container, {
opacity: 0,
});
},
enter(data) {
var supposedURL = jQuery(data.next.container).find('.js-variables-mule').attr('data-url');
supposedURL = stripTrailingSlash(supposedURL).split('/');
supposedURL = supposedURL[supposedURL.length - 1];
var currURL = window.location + '';
var currURLNoHash = currURL.split('#');
currURLNoHash = currURLNoHash[0];
currURLNoHash = stripTrailingSlash(currURLNoHash).split('/');
currURLNoHash = currURLNoHash[currURLNoHash.length - 1];
console.log(supposedURL +' '+ currURLNoHash);
if(supposedURL != currURLNoHash){
console.log('redirect');
jQuery('#swup').css('display','none');
jQuery('body,#swup').css('display','none');
jQuery('body,#swup').css('opacity','0');
window.location.href=currURL;
return;
}
return gsap.to(data.next.container, {
opacity: 1,
});
},
},
],
})
function stripTrailingSlash(str) {
if(str.substr(-1) === '/') {
return str.substr(0, str.length - 1);
}
return str;
} Like I said: its a VERY dirty fix, but it does work for now. It is also slower, because the page has to load first, check if its allright, and if it isn't do the reload. |
Any progress on this? Still causing issues for me. |
Hi everyone, unfortunately not. Thanks again for your patience. |
Any update on this? I'm having the same issue :( |
Both I've tried monkeypatching barba's |
Hi everyone 👋 |
Hi,
Using version 2.9.7
When receiving a 301 HTTP code from the server, the next page has the right content, but the browser URL is the requested url, not the response location header
I have a link that leads to :
https://domain.com/url
Server response is a HTTP 301 with location header :
https://domain.com/url/suburl
The content displayed by barba is the one from https://domain.com/url/suburl but the browser url is still https://domain.com/url
Thanks
The text was updated successfully, but these errors were encountered: