Jump to content

Back 2 pages when page loads


son
 Share

Recommended Posts

um you can put that javascript into an onload function in the body tag so <body onload="javascr..... etcCan I just ask why you want to do that? O.o
Hi Kingy,Thanks for your input. I realise it sounds strange, but this is the only way to have a customer return to same page he/she was before entereing the shopping basket. We use a backend, which also has the shopping cart/checkout while the online shop itself is hosted externally. Unforunately, the backend provides only the facility to give a url to enable the customer to continue shopping. You cannot add any code etc. I thought the customer probably will want to go back to page he/she was before. Hence, in backend a link to a page which only holds JavaScript to direct the user 2 pages back... Hope I make sense.Son
Link to comment
Share on other sites

Kingy is right, but you don't need the java script: protocol in an event-handler (only in URL attributes). Also, assigning the function to window.onload rather than putting it inline in your HTML is the best practice.

Link to comment
Share on other sites

Kingy is right, but you don't need the java script: protocol in an event-handler (only in URL attributes). Also, assigning the function to window.onload rather than putting it inline in your HTML is the best practice.
Use now:
<script type="text/javascript">function histBack () {history.go(-2);}window.onload=histBack();</script>

Thanks for your input.Son

Link to comment
Share on other sites

Kingy is right, but you don't need the java script: protocol in an event-handler (only in URL attributes). Also, assigning the function to window.onload rather than putting it inline in your HTML is the best practice.
Use now:
<script type="text/javascript">function histBack () {history.go(-2);}window.onload=histBack();</script>

Thanks for your input.Son

Link to comment
Share on other sites

Kingy is right, but you don't need the java script: protocol in an event-handler (only in URL attributes). Also, assigning the function to window.onload rather than putting it inline in your HTML is the best practice.
Thanks for correcting me, was in a rush this afternoon. :)Both will work buy why have the extra mess if it isn't neccessary?
Link to comment
Share on other sites

Thanks for correcting me, was in a rush this afternoon. :)
If you look through my posts, you'll see I get corrected too. :)
Both will work buy why have the extra mess if it isn't neccessary?
The full "best practice" is to put the JavaScript in a separate JS file, hiding it from view while the HTML is being read (and the same for CSS). We don't always practice that here because it's a lot easier to put the JavaScript and CSS in the same code block as the HTML, but reading one language at a time is generally easier in the "real world."
Link to comment
Share on other sites

We're only humans. :) Following on from Jes' advice, some may find it easier to code straight into their html headers and when everythings working, saving your JavaScript or CSS externally afterwards to save you switching back and forth.But however you like to work, if your JS and CSS end up as external files it's:1) Much tidier2) If your need the same codes to work for numerous pages (especially CSS), you can just keep linking them up in the header in a couple of lines instead of copying and pasting 100 lines of code.

Link to comment
Share on other sites

We're only humans. :) Following on from Jes' advice, some may find it easier to code straight into their html headers and when everythings working, saving your JavaScript or CSS externally afterwards to save you switching back and forth.But however you like to work, if your JS and CSS end up as external files it's:1) Much tidier2) If your need the same codes to work for numerous pages (especially CSS), you can just keep linking them up in the header in a couple of lines instead of copying and pasting 100 lines of code.
Guys, this was really a lot of input. Have to see if I can digest so much data;-)Anyway, me thinking I was clever did not really work out. Just found that my script does not work when the user updated or deleted quantities from shopping basket. If user has reloaded the page two times he/she has to go back in browser history three time and my script will redirect user back to shopping basket (minus 2 in browser history). Is there a way to amend:
<script type="text/javascript">function histBack () {history.go(-2);}window.onload=histBack();</script>

so it will go back to page before the shopping basket (even when the user reloaded the shopping basket 12 times)? [[Go back to page before http://www.domain.co.uk/shopping.php?]]Son

Link to comment
Share on other sites

I think you need to use a server-side language for this; I will assume that you choose PHP. When the user visits your pre-basket page (the one that redirects to the basket), call session_start and set $_SESSION['back'] to $_SERVER['HTTP_REFERER']. Then on the basket page, call session_start and use this:

<a href="<?php echo (isset($_SESSION['back']) && $_SESSION['back'] != '' ? $_SESSION['back'] : '/index.php'); ?>">Go back</a>

The default case sends them back to your homepage; you might want to modify it.

Link to comment
Share on other sites

I think you need to use a server-side language for this; I will assume that you choose PHP. When the user visits your pre-basket page (the one that redirects to the basket), call session_start and set $_SESSION['back'] to $_SERVER['HTTP_REFERER']. Then on the basket page, call session_start and use this:
<a href="<?php echo (isset($_SESSION['back']) && $_SESSION['back'] != '' ? $_SESSION['back'] : '/index.php'); ?>">Go back</a>

The default case sends them back to your homepage; you might want to modify it.

That is the problem. On shopping basket page we cannot have any php:-( Really a pain in the neck... But the shopping basket let's your specify a url where the user goes when clicking onto 'continue shopping'. Could I use this page to redirect the user? It is 2 pages after the referer if the user did not update/delete and maybe more if he/she did...Son
Link to comment
Share on other sites

OK - do exactly the same thing as above, but on the basket page use AJAX to call a script that outputs $_SESSION['back'] (or the default page if the session variable isn't set).
Sorry, but could explain a bit more in detail? Am a bit lost, especially as I have never used AJAX before...Son
Link to comment
Share on other sites

This is untested. (I'm relying heavily on the AJAX tutorial.)prebasket.php

<?phpsession_start();$_SESSION['back'] = $_SERVER['HTTP_REFERER'];?>

session_back.php

<?php session_start();echo (isset($_SESSION['back']) && $_SESSION['back'] != '' ? $_SESSION['back'] : '/index.php');?>

basket.html

<html>	<body>		<div id="back"></div>		<script src="session_back.js"></script>	</body></html>

session_back.js

function getAjax(){	var ajax;	try{		ajax = new XMLHttpRequest();	}catch (e){		try{			ajax = new ActiveXObject("Msxml2.XMLHTTP");		}catch (e){			try{				ajax = new ActiveXObject("Microsoft.XMLHTTP");			}catch (e){				return false;			}		}	}	return ajax;}var ajax = getAjax();if(ajax){	ajax.onreadystatechange = function (){		if(ajax.readyState == 4){			var link = document.createElement('a');			link.href = ajax.responseText;			link.innerHTML = 'Go back.';			document.getElementById('back').appendChild(link);		}	};	ajax.open('GET', 'session_back.php', true);	ajax.send(null);}else{	//The browser doesn't support AJAX; react here.}

Link to comment
Share on other sites

I used the example, but it complains '413 Request Entity Too Large'. Is there any improvement I could do to given example? Also I was hoping that it could replace value from onclick="return(document.forms['cart'].elements['redirect'].value='webpage'instead of creating a new button as such. It is the button of a shopping cart software and I do not want to keep the wrong url as such...SonForgot one really important point: Shopping cart and website are in two different places. session_back.php is not on same server as shopping basket...

Link to comment
Share on other sites

I used the example, but it complains '413 Request Entity Too Large'. Is there any improvement I could do to given example?
I have no clue how an empty message is too large... Try to solve the cross-domain AJAX problem to make sure this is a real problem.
Also I was hoping that it could replace value from onclick="return(document.forms['cart'].elements['redirect'].value='webpage'instead of creating a new button as such. It is the button of a shopping cart software and I do not want to keep the wrong url as such...
Are you in control of the form's "action"? If so, you might as well not use JavaScript because $_SESSION will be available there as well.
Forgot one really important point: Shopping cart and website are in two different places. session_back.php is not on same server as shopping basket...
Read these:SWFHttpRequest.Cross-domain Ajax via Flash (for links to other implementations and an explanation of crossdomain.xml)Introduction to Cross-Domain Ajax (for a bit of context/history)
Link to comment
Share on other sites

Tried it on one server/domain and it always links to about.php. In included the code below:echo (isset($_SESSION['back']) && $_SESSION['back'] != '' ? $_SESSION['back'] : '/about.php');If I read the statement correct is says that if $_SESSION['back'] is set and it is not null, then it should go to page specified in $_SESSION['back']. This should be the prebasket. Running a var_dump on the basket iteself it shows that $_SERVER['HTTP_REFERER'] is the prebasket page. What is going wrong?In addition, I have no means to influence the JavaScript I showed in my previous post. This is set by shopping cart software...SonReason for edit: Mistake in text, which changed meaning of what I was saying

Link to comment
Share on other sites

What browser are you using? This is important for at least two reasons (JS and headers).How are you redirecting the user on prebasket.php? When I use header('Location:basket.php'); and then do history.back() (with no argument) in Firefox, I get sent back to the page which linked to prebasket.php.Are you linking to prebasket.php from another page or visiting it directly? I ask because you're observing different behavior related to $SERVER['HTTP_REFERER'] than I am.

If I read the statement correct is says that if $_SESSION['back'] is set and it is not null, then it should go to page specified in $_SESSION['back'].
This is correct.
This should be the prebasket.
Actually, it should be the page that links to the prebasket because you set it on the prebasket.
What is going wrong?
First, I need to go over the behavior I expected when I wrote the PHP. HTTP_REFERER is set (if at all) by the browser in the HTTP request headers which it sends to the server; the browser can only set it if a page did actually refer you to the current one (i.e., you didn't just type in the current URL or click a bookmark). Firefox is not sending the header at all for me, but you report that your browser does send the header (because the variable is set on basket.html) but not when requesting the prebasket. Thus I suspect that you're visiting the prebasket by typing its URL in.By the way, how did you put PHP in the basket page? I thought you couldn't do that - or is this just a test page on your server?The only solution I see for my problem is to set a GET or SESSION variable on the page which links to the prebasket and use it instead of HTTP_REFERER. You could do this always or only if you know that the browser doesn't send HTTP_REFERER (which you could easily check).
<a href="prebasket.php?back=<?php echo $_SERVER['PHP_SELF']; ?>">Go to your shopping basket.</a>

or

<?phpsession_start();$_SESSION['back'] = $_SERVER['PHP_SELF'];?><a href="prebasket.php">Go to your shopping basket.</a>

Link to comment
Share on other sites

Now, I understand where I went wrong. I accessed the preBasket page directly. Using:$_SERVER['PHP_SELF'];instead of referrer solves the problem testing on same domain.Trying the same thing in between the two domains I get error:Access to restricted URI denied (NS_ERROR_DOM_BAD_URI)and found that cross-domain AJAX calls are apparently not allowed and JSON shoudl help. JSON? What is the difference (and is the good advice?)?Son

Link to comment
Share on other sites

and found that cross-domain AJAX calls are apparently not allowed and JSON shoudl help.
JSON is just a format for data, like XML is. Here is a Javascript object defined in JSON format:var obj = {var1: "val1",var2: "val2",var3: "val3",vals: [1, 2, 3],popup: function(str) { alert (str); }}JSON isn't going to affect whether or not you can send a request to another domain. If you need to have Javascript send a request to another domain you need to use a proxy, like a PHP proxy. You would have a PHP page on the same domain as the Javascript code that the Javascript sends a request to. The PHP page would send a request to the remote server and receive the response back, and give the response back to Javascript.
Link to comment
Share on other sites

JSG, I considered the PHP proxy option but rejected it because the HTML page which needs to request a remote script is on a server under someone else's control (so he can't upload PHP to it). Indeed, that's the reason he needs to request the remote script in the first place. But, now that I come to think of it, SWFHttpRequest is equally hobbled if an object element cannot request a remote file (and it surely can't because that would defeat the same-domain policy).I think the only remaining solution is to give a static URL to the remote page and, at that static URL, redirect the user based on $_SESSION['back'].

Link to comment
Share on other sites

A Flash movie can make a remote request as long as there is a policy in place to allow it. If there is no policy, then it's disabled. To create a policy, you need to create a file called crossdomain.xml. Here is an example that allows all remote requests, from any server:

<?xml version="1.0"?><!DOCTYPE cross-domain-policy SYSTEM "http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd"><cross-domain-policy>   <allow-access-from domain="*" /></cross-domain-policy>

(that macromedia.com link probably has an update by now)That XML file needs to go in the root of the remote server. If the server that the Flash movie is trying to request from is domain.com, then that file needs to be domain.com/crossdomain.xml. Flash will attempt to look for that file and get the policy before it makes the request. You can also edit that policy to only allow remote requests from the one domain.Now for a couple other questions to the original poster: Why are you developing on a server that you don't have any control over? I've never been asked to do that, ever. If I ever agree to do any job I always get direct access to the server that I'm implementing it on, or at least a test server set up the same way. You should tell your client that you need full access to do this job correctly, if you don't have access to create your own PHP files then the solution will take longer to implement and may not work. If you're not working for a client, if this is just for yourself, then get yourself your own hosting account where you can control whatever you need to. Seriously, that's just the correct way to do it.

Link to comment
Share on other sites

To clarify, I understand cross-domain.xml but doubt that this is legal (coming from, e.g., w3schools.com). (If PHP cannot be uploaded, surely Flash movies can't be either?)

<object id="swfhttprequest" class="hidden" classid="clsid:d27cdb6e-ae6d-11cf-96b8-444553540000" codebase="http://fpdownload.adobe.com/pub/shockwave/cabs/flash/swflash.cab#version=9,0,0,0"> <param name="movie" value="http://www.example.com/swfhttprequest.swf" /> <param name="allowScriptAccess" value="always" /> <embed class="hidden" src="swfhttprequest.swf" allowScriptAccess="always" type="application/x-shockwave-flash" pluginspage="http://www.adobe.com/shockwave/download/index.cgi?P1_Prod_Version=ShockwaveFlash"> </embed></object>
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...