I've just upgraded to v5.3.1 (not sure previous version) and my videoClickThroughURL goes to a blank white page and never redirects. I'm using Vast and everything worked perfect before the upgrade, so I'm a little perplexed. My Revive Adserver uses http:: and my redirect is http: so there's no mixed ssl. Is there something new I need to do with this latest version?
[http://fakeadserverserver.com]/adserver/www/delivery/cl.php?bannerid=5&zoneid=5&sig=8ddfd06f8ab42ed0d44e0737ab7253b77dbe38ce493cd18da3b52caf62607091&dest=http%3A%2F%2Fwww.website.com
I'm doing this from a mobile app, but I don't think that matters. The page above does load, but it's a blank white page and never redirects. I can see the click registers in Revive, so it appears to be an issue with redirecting.
Related
So I just linked my custom domain with firebase and it shows connected:
image of connected status
which is great. But now when I search website without /index.html, it redirects me to this page. I want to see this page which is accessible only when I append website domain with /index.html. I am new to firebase. How can I make my domain access index.html page without specifically mentioning /index.html?
EDIT: I just noticed that it's working fine on the mobile devices and in the incognito tab on PC. It must be something with my chrome browser I am logged in with. which is weird :/ should I change the title? Cause I think fault could be related to browser. but help me if you can.
So the real issue wasn't the configuration but the browser cache. if you are facing similar issues then try clearing the browser cache or try browsing the website on a different device. Spent literally 1-2 hrs on such a silly problem. Either way, thank you.
I am in the process of building a shop on wordpress using woocommerce. All is well except that at checkout there is an endless spinning wheel blocking the payment processing.
I have checked the error logs - which show no errors
I have disabled all plug ins - which makes no difference
I have reverted to the default woocommerce shopfront theme - which has the same result.
The console shows no errors.
I have also followed the instructions here https://docs.woocommerce.com/document/endless-loadingspinner-on-the-checkout-page/ which assumes its a memory limit issue. This did not work.
So, after a bit of digging I found some reference here https://mikejolley.com/2015/11/12/debugging-unexpected-token-in-woocommerce-2-4/ and here https://www.maxsangster.com/blog/woocommerce-endless-loading-spinner-on-checkout/
Referring to these two pages I have been able to see that the json response from /?wc-ajax=checkout is just returning HTML which I would imagine is where the issue is.
However I am running an Apache server rather than Nginx as has been mentioned in some threads and articles. Assuming there is a server misconfiguration of the server or something that needs changing what might that be? Bearing in mind that I do not have direct access to this, so will need to be asking someone else to sort it out for me.
And finally if there is something else I can try what might that be?
Thank you to #plushyObject for generating the spark for this one.
The issue turned out that I had a legacy static html holding page in place as the site's homepage rather than having one set up with wordpress. Simply removing the .html page and letting wordpress's homepage take over solves the problem.
The moral of the story create your holding page in wordpress.
Go to Google Developer Tools, then Go to the Network tab. Click the button and make the request and let that bad boy spin out.
You mentioned the response is returning HTML. Click on the request that goes out that appears to be taking forever (/?wc-ajax=checkout) and then click on the Preview tab to display that HTML. I bet it shows an error or a clue, anyway.
In my case the checkout was working fine on Desktop but not on Mobile. After many search on internet I read the solution of #UntitledGraphic.
I had set a redirect in ht-access. The redirect was showing a different home page for mobile. When I removed it, the error gone. I checked back & forth and was sure the ht-access redirect was the problem.
If you have set any redirect in the Htaccess then remove it. This will solve your issue in this case.
I also checked the redirect code on function.php instead of htaccess again the problem appeared. So finally removed the redirection.
In my own case the redirection was the issue. So I had to delete the redirect I created via Cpanel.
I'm working on a pretty large booking site, I recently discovered that we got many requests that just didn't go through because of missing parameters error.
I checked out logs and noticed that all browsers running safari (both mobile and desktop, and some older versions of IE) had this problem.
The problem is that when we go from our search step to our booking we switch over to https, this is done via the "always https" option in cloudflare, with a pattern that looks like: http://www.exampel.com/Booking/*
The url for the page I want to access is:
http://www.exampel.com/Booking/Book#!/?Product=1&product=2
Clicking the link will lead me to that page in chrome and firefox, but NOT in safari (and some older versions of IE) that will send me to:
http://www.exampel.com/Booking/Book
I ran into this problem of Cloudflare dropping query strings and got around it by not using the Always uses https option. Instead I created these 3 redirect rules:
http://example.com/* Forwarding to https://www.example.com/$1
http://www.example.com/* Forwarding to https://www.example.com/$1
https://example.com/* Forwarding to https://www.example.com/$1
You can adjust them if you want the non www url to be available and not redirect away from it. In my case I directed everything to the https://www.example.com version.
I'm not sure why you were seeing it only on certain browsers though.
No idea what has caused this, but my Laravel app is outputting a message between page loads, of 'Redirecting to a/url...' between page loads. It's doing it on my local MAMP set-up, and live on the Hostgator server. The routes and redirects otherwise work fine. It's just not a high quality experience for the end-user.
I don't recall changing any configs or anything, and toggling the debug config to true or false didn't seem to matter.
Ideas what might cause this? Thanks.
I've got a web service that, like most others, uses js and css files. I use the old trick of appending a version number to the js and css file like; ?v=123 and that gets changed every time we update the service on production.
Now, this works fine on all browsers, except for Chrome. Chrome seems to prefer it's cached version over getting the new one and therefor seems to ignore the appended variable. In some cases, forcing it to refresh cache (cmd+r / ctrl+f5) wasn't enough so I had to go into options and clear out the cache for it to load up the new content.
Has anyone experienced this issue with Chrome? And if so, what was the resolution to the problem?
Chrome should certainly treat requests with varying query strings as different requests; a cached result for style.css?v=123 should never be used for style.css?v=124. If you're seeing different behavior, please file a bug at http://new.crbug.com/ and post the bug ID here.
That said, I'd first check to see whether the page was cached longer than you expected. If a new version of the page itself wasn't downloaded, then it would still be requesting ?v=123 as the HTML wouldn't have changed. If you're sending long-lived cache headers with the page, it's certainly possible that Chrome is caching it more aggressively than you expected. If that's the behavior you're seeing, please star http://crbug.com/8742 for updates.
I had also same experience
You can user Ctrl + Shift + R for cache free browsing in both Chrome + Mozilla.
I have had this experience as well.
I run a membership site which displays content such as "You must be logged in as a Gold member in order to see this content" if they are not logged in or are trying to view content not allowed by their membership level. But even if the user is logged in, the user would still see "You need to log in", due to Google Chrome's aggressive caching. In Firefox, however, it works fine as I test logging in and out of all 5 levels of membership - each displaying the proper content.
While Chrome's caching problem can be solved by clearing the cache every time the user logs in and out, it would be really annoying to take that approach.