sending php vars to a diferent php page

Anon

Hello

Im working on a big form spreading over 5 pages. On every page i get an array. what i want to do, is to send these arrays along to the next pages. on the last page i want to display what's in the arrays.

how can i send these arrays from page to page.....??

thanx jesper

van__

Here's 2 functions to help you with that.
The first func: makeHiddenField() will simply take whatever array is passed an generate 2 $GLOBAL strings.
$GLOBALS['PASS_DATA_STRING']
and
$GLOBALS['PASS_DATA']

Why 2?
Well.. I fig'd it'd be handy to have a reusable version of the data we pass,
I'm greedy for data and don't toss anything that I may want to use at some point in time.

$GLOBALS['PASS_DATA'] contains the HTML output for the page...
<? echo $GLOBALS['PASS_DATA']; ?>

use the function passHiddenField() to just recreate the PASS_DATA post value without touching it.

so here they are:

function makeHiddenField($dataArray) {
// build callable string of hidden form fields for output //
if (is_array($dataArray)) {
$hiddenStr = "<input type='hidden' name='PASS_DATA' ";
$GLOBALS['PASS_DATA_STRING'] = '';

   foreach($dataArray as $key=>$val) { 
	 /*
		we preg_match for x and y in the event
		that the form used an image for a submit..
	 */
    if (!preg_match('/^(x|y)$/i', $key)) {
      $GLOBALS['PASS_DATA_STRING'] .= ($key . ":" . $val . ";");
    }
   }

	$hiddenStr .= ("value='" . $GLOBALS['PASS_DATA_STRING'] . "'>");
	$GLOBALS['PASS_DATA']=$hiddenStr;
	return true;

}

return false;
}

function passHiddenField() {
if (isset($GLOBALS['HTTP_POST_VARS']['PASS_DATA'])) {
$GLOBALS['PASS_DATA'] = "<input type='hidden' name='PASS_DATA' " .
"value='" . $GLOBALS['HTTP_POST_VARS']['PASS_DATA'] .
"'>";
}
}

Anon

The best way to do this would probably be to use session variables.

On each page of the form, start the script with

session_start();

Then register each array you want to carry across

session_register('array1', 'array2', etc.);

Note: for reliability and safety these lines should be effectively the first things on the pages; no outputting anything to the browser ahead of them, and avoid processing the form data from the previous page, too.

Once you've registered your session variables, depending on how your server is configured, you may need to do this:

$array1=&$HTTP_SESSION_VARS['array1'];
$array2=&$HTTP_SESSION_VARS['array2'];
etc.

So you can use $array1, $array2, etc. as aliases for the longer names. Like I said, this depends on how your server is set up; you may be able to get away without this. If you have to use $HTTP_POST_VARS and $HTTP_GET_VARS to get your form values, then you'll have to do this aliasing trick.

And that's it.

When session_start() is reached. PHP will look to see if a session with this browser is already running (using a cookie it stored on the browser, if the browser let it). If there isn't one, it starts one.

Then, for each variable you use session_register() on, PHP will look in its stored data for that session to see if the variable is in there. If it is, PHP uses the value it finds there (carried across from the previous page).

While PHP is processing the page script, it keeps track of each variable (of course!) and when finished, writes the current values of your session variables back into its stored session data, ready to be used again on the next page.

van__

Yes sessions are the best way to go.

But in the event that we don't want to assign a session such as in the case of a new user registration, I say use hidden fields.

And thus the reason why I built functions such as the ones I posted.

Anon

Why wouldn't we want to assign a session in the such a case as a new user registration?

van__

Well, I don't assign sessions to a page before a sucessful login is recieved due to the fact that if the client does not have the capability to send/recieve cookies, the ?PHPSESSID=sdaa9sdas90dasda will display in the URL at each and every page request after the initial page has displayed.

This to me is a MAJOR deal.
Especially when I have gone so far out of my way to mimic a static .html website with PHP so that spiders who do not get cookies will not get the telltale "?var=blah? syntax revealing that the site is truly dynamic in nature and thus causing the page not to be indexed as well as I had intentioned.
While pages that contain query strings do get indexed, you will notice the performance of an index.html file with no query string will get better listings overall.

And that to me is worth passing a hidden field with some minor data to retain while I create the user in the database. Normally, I never have to pass 1 or 2 values across the registration process, namely just the UID generated to identify the users records across tables.

So hardly a deal at all.

Anon

Good points, especially the spider issue, though I'd've thought that killing sessions following failed login attempts would kill the PHPSESSID as well (I must admit, I've never tested this - it justs sounds like the Right Thing). Then spiders won't have any trouble either, since the only pages they'd refuse to index would be the login pages themselves - and since when has a spider needed to log in?

For jesper's situation (five entire arrays), I'm not too keen on hidden form fields (with serialised data?). That could be a fair bit of hidden stuff to keep shuffling back and forth.

DIY session handling with a db table to carry session stuff, and a hidden form field containing a table UID is the method I used in PHP3; if you don't want to use PHP4 sessions, it's certainly a valid fallback position.

van__

Grumbler wrote:

DIY session handling with a db table to carry session stuff, and a hidden form field containing a table UID is the method I used in PHP3; if you don't want to use PHP4 sessions, it's certainly a valid fallback position.

Same here.
Had my PHP3 sessions in a MySQL database.

But my codebase has drastically changed since then and I haven't quite had time to getting around to writting a custom sessions object for my current codebase (my codebase requires all scripts to be an extension of the mother object)

And part of my plan is to include a trans-sid feature in my template parser for this as well, since I can actually have it write in the $SID as a directory path like so: /sid_122334/index.html as well as ?sid=122334 for sites that would rather use the query string approach (my software is portalware that can handle multiple sites simultaneously so the more flex, the better)

And besides, it's just better security to not be promiscuous with your sessions.

As far as that guys 5 pages go...
I was going with the cheerfull optimism that he'd find a way to pass the sheer minimum of values required (like just the UID and maybe a page to redirect to when done) from page to page lest he wind up with 10k of data in that hidden field 🙂