Hey Gang,

I've got yet another PHP question for you all. I am thinking this should be possible, but I have no clue how to implement it.

Let's say you have a dynamic page that stores/passes user selections on the page via variables through the address bar: (to be used in GETS later)

page.php?sortby=iid&sorder=0

What if I want to add another user selection option like a drop down box that allows further customization of the page display:

page.php?sortby=iid&sorder=0&rpp=10

When I'm building the links for the drop down box, I don't wish to have to hard code all the previous selections in the address bar just to add another one on. I would like to simply build the link to say put &rpp=10 on the end of whatever is already on the address bar, so it doesn't matter if the selection is made at this point:


page.php?sortby=iid&sorder=0 + &rpp=10

or this point

page.php?sortby=iid&sorder=0&cpn=3 + &rpp=10


As it is right now I'm saying http://?sortby=$sortby&sorder=$sorder&rpp=$rpp
but if i wanted to say: http://sortby=$sortby&sorder=$sorder&cpn=$cpn&rpp=$rpp
I would have to go in and physically change each link, and that sucks.

Is there anyway to say something like: http://?-all previous after ? stuff-&rpp=$rpp
(Without knowing specifically each time how much previous stuff there will be)

I hope I phrased this clearly enough.

Thanks for any assistance on this, I know i'm really limiting myself hard coding these links each time, when I simply wish to append to an existing string.

-Karl

Just use a $_SESSION variable to store this string and append whatever options are there to the existing string.

A session variable does seem like a much better alternative to trying to pass this information via the address bar and $_GETS. I am very new to sessions. Is there any danger of session variables I create interfering with existing session variables of coincidentally the same name in other unrelated scripts running on the same server?

Example: say my script stores the current page number for a thread in a session called:

$_SESSION['pgnum'] = 1


and another programmer does the same thing with his own unrelated script, $_SESSION['pgnum'] = 3

I guess I am unsure of the scope and protection of session variables as they are being stored on the server.

Thanks.

No. Sessions in PHP are safe and session vars apply only for *that* particular user for that particular session. Especially in the later versions of PHP 4 (4.4+) and PHP 5. Safer than query strings which can be easily read because they're unencrypted. It also depends on PHP.ini settings, but generally using sessions is a fairly safe bet.

Don't forget to call session_start() in the beginning of every PHP file using sessions in your app though or it won't work.

Sessions definitely seem like a great tool, and a safer alternative. As far as internal protections though, I don't need to worry about my Session variables writing over another programmers Session variables on another project. I guess I'm still kind of viewing them like "Global" variables. Your're saying the there is no way my session variables could over-write another programmer's session variables, as the server will create a unique name for each one?

For instance my script runs and says:

<?php
session_start();
$_SESSION['views'] = 1; // store session data
echo "Pageviews = ". $_SESSION['views']; //retrieve data
?>

and programmer 2 unrelated script says

<?php
session_start();
$_SESSION['views'] = 2; // store session data
echo "Pageviews = ". $_SESSION['views']; //retrieve data
?>

We are in no danger of over-writing each other's session variables on the server?

Also, how long does Session data stay on the server if it's not explicitly destroyed with: session_destroy();

Read the comments here: http://in.php.net/session_destroy

I think I understand the scope of a session variable now. It is very temporary, it only exists for a single visit to the page, unlike a traditional cookie which would be used to retrieve data from previous visits. A session is a server side way to move accumulated data from a single visit, (to the checkout) so to speak. However once the script finishes (the user leaves the site/closes the browser/logs out) the session variables are destroyed. Therefore, it is not like other developers have a bunch of session variables just hanging out waiting to be over-written, as they are quickly and uniquely created and destroyed with each new user visit.

it's not like each user gets session[views] and if 2 users were on at the same time their alternating session[views] the temp unique id cookie takes care of this so to speak.

This site really helped me to understand how this whole thing works:

http://devzone.zend.com/node/view/id/646

Note that sessions can be as temporary as the session cookie set at the user end. The difference between session cookie and normal cookies is that traditionally normal cookies contain all the cookie variables while session cookie contains only the session ID and the actual variables are stored in the server end.

Also sessions can exist without cookies by passing the session ID in the URL but that's generally not a very ideal way and is used only when the user has disabled storage of cookies at the client end.

Also note that session behaviour can be controlled using PHP.ini