views:

250

answers:

4

I've been trying to debug this problem for many hours, but to no avail. I've been using PHP for many years, and got back into it after long hiatus, so I'm still a bit rusty.

Anyways, my $_SESSION vars are not retaining their value for some reason that I can't figure out. The site worked on localhost perfectly, but uploading it to the server seemed to break it.

First thing I checked was the PHP.ini server settings. Everything seems fine. In fact, my login system is session based and it works perfectly. So now that I know $_SESSIONS are working properly and retaining their value for my login, I'm presuming the server is setup and the problem is in my script.

Here's a stripped version of the code that's causing a problem. $type, $order and $style are not being retained after they are set via a GET variable. The user clicks a link, which sets a variable via GET, and this variable is retained for the remainder of their session.

Is there some problem with my logic that I'm not seeing?

<?php
require_once('includes/top.php'); //first line includes a call to session_start();
require_once('includes/db.php');

$type = filter_input(INPUT_GET, 't', FILTER_VALIDATE_INT);
$order = filter_input(INPUT_GET, 'o', FILTER_VALIDATE_INT);
$style = filter_input(INPUT_GET, 's', FILTER_VALIDATE_INT);

/*
According to documentation, filter_input returns a NULL when variables
are undefined. So, if t, o, or s are not set via URL, $type, $order and $style
will be NULL. 
*/    

print_r($_SESSION);
/* 
All other sessions, such as the login session, etc. are displayed here. After 
the sessions are set below, they are displayed up here to... simply with no value. 
This leads me to believe the problem is with the code below, perhaps?
*/


// If $type is not null (meaning it WAS set via the get method above)
// or it's false because the validation failed for some reason,
// then set the session to the $type. I removed the false check for simplicity.
// This code is being successfully executed, and the data is being stored...
if(!is_null($type))
{
    $_SESSION['type'] = $type;
}
if(!is_null($order))
{
    $_SESSION['order'] = $order;
}
if(!is_null($style))
{
    $_SESSION['style'] = $style;
}


 $smarty->display($template);

?>

If anyone can point me in the right direction, I'd greatly appreciate it. Thanks.

A: 

You need to call the session_start() function . Before accessing the $_SESSION variable.

Then It will retain all SESSION variables to you..

pavun_cool
The session_start() is called in the first required / included file, at the very top. Other session based variables are working, so the session is being created and starting perfectly.
Foo
A: 

I think you pointed out you have made a call to session_start() in the top.php right? And another thing I notice is that you are validating Integer fields through the PHP Filter. Be sure that they are integer values or you are bound to end up with null values. Do a test to see if the TYPE,ORDER and STYLE values are set before validating. Do keep in mind that, using the php filter is to validate for a certain type and not to store. I dont think that $type would store your data, it would rather be a boolean check. Try assigning the $_GET[] variables to the SESSION VARIABLES. Hope this helps.

Joey Ezekiel
Thanks for the suggestions. I tried it out, all the variables are being set. In fact, the $_SESSION['type'] or whatever IS being set using my code. It's just not retaining the value as you continue to browse the site.There is no other place that's unsetting or overwriting it.
Foo
A: 

Unbelievable!

After three hours of debugging, I've figured out the problem

HostGator, my no-longer-beloved host, runs their default ini with register_globals ON

I can't believe this.

So my variables of $type was being overwritten with $_SESSION['type'] and they were being treated as the same. So it was a server issue causing the problem, not my coding. That's great to know, but I want my 5 hours of pulling my hair out back.

I hope this helps someone down the road whose using HostGator and is confused as hell.

Foo
I’ve experienced that once too. It’s just horrible if you don’t expect such odd behavior.
Gumbo
A: 

thanks so much i have my company server and they are stupid and turn it on too i spend same time thing and change the code although it work on my local host and on my server online but the company server sucks

thanks so much for ur advice brother

mos