Webpage redirects to my homepage when I click "continue shopping" from Paypal
The product page on my website uses Paypal. Clicking on "Add To Cart" goes to the PayPal order page. If I click on "Continuing Shopping", I go back to my product page but am immediately redirected to my homepage. This occurs in Firefox only. Works fine in Chrome, Safari and Opera. My site is a self-hosted Wordpress site. Home page is : www.ecv13.org. The product page is live but not yet linked to the website. It's url is : www.ecv13.org/the-rub I cannot see anywhere on my product page any code that would cause it to redirect to the homepage although I'm not a web expert. PayPal Support says that since the "Continuing Shopping" goes back to the correct page before redirect, its not a PayPal issue. Thanks, Eric
Alle Antworten (4)
Hi, the W3C.org (World Wide Web Consortium) in charge of standards and practices and future development of web pages and web browsers make the rules on code. Mozilla Firefox follows these rules. W3C.org Who make the rules for web code. HTML https://validator.w3.org/ CSS https://jigsaw.w3.org/css-validator/ and https://validator.w3.org/i18n-checker/ and http://mobile.css-validator.org/
So if clean up your errors it may work right or by cleaning the errors up have narrowed the search down.
This page run only for below : http://ecv13.org/the-rub/ HTML Errors : https://validator.w3.org/nu/?doc=http%3A%2F%2Fecv13.org%2Fthe-rub%2F
Please let us know if this solved your issue or if need further assistance.
Thanks for your time looking at this and the info on the HTML analysis tools. Since all my code is generated by Wordpress (and Paypal for this specific issue), there are some errors I don't have access to change. For example, the <style> tag with "text=" parameter on my product page is not displayed in the text editor provided. The only code shown in the text editor is for the content/formatting I added to a default page. There may be another way to get at it, but not known to me. Also, even if I can correct the <style> issue, Wordpress would probably put it back in when I publish a page. Also consider, if the problem is due to not complying with W3C and since my page works fine in Chrome, Safari and Opera then are those browsers not in compliance with W3C? Or is the problem elsewhere? Again, appreciate your time. I had hoped someone else had a similar issue with a straight-forward fix. Thanks, Eric
Hi, Firefox looks at code a little stricter than other browsers. As to why they show pages with errors I have no idea as that. Just know that when I do pages I do it in HTML5 Responsive using Bluefish as my editor and since I am really bad at CSS I use Templates from https://html5up.net/ which has a link at page bottom and can Subscribe for a year and download everything.
With Wordpress always needing to be update because of security issues i decided for less work after completion.
Can you upload pages to the site ? Then can copy the code and create a new page in like Bluefish and work on it and upload it. As said not a Wordpress person.
Is there not a wordpress help site or something that will parse the code like W3C ? Same goes for the PayPal code.
Though is possible to correct the paypal code I would think if created a html page and just put the PayPal code in.
Answer back so that cor-el or jscher2000 can look at the code.
Are you testing in a private window? When I click the button on that page and Firefox generates the POST to PayPal, there's a big difference in one of the headers:
Regular window:
Referer: http://ecv13.org/the-rub/
Private window:
Referer: http://ecv13.org/
And that's exactly the URL PayPal sends back when I click Continue Shopping in a regular vs. private window.
This probably is an intentional difference, sharing less information from private windows with other websites, and it could explain the extra redirect coming from PayPal, sending the shorter URL to the "opener" window (if that's what it's doing, which is what it looks like).
Perhaps there is an alternate way to send PayPal the source page address that bypasses the REFERER header. Some users may block that header altogether, or set it to the destination site; it's just not reliable.