simple scripting not working after update

[smallcompany]

In WHM I used EasyApache 3 to upgrade PHP from 5.4 to 5.5. After that URL variable passing from URL to a cookie and then to an outgoing URL stopped working. The scripting itself is simple and going from 5.4 to 5.5 should not mess it up as it worked from long time ago in older PHP versions.
The principle is that a visitor gets via a referring URL from which certain variables are picked. Those variables are then written into a cookie. As a visitor clicks onto an outgoing link, variables are called from the cookie and appended to an outgoing link. End.

I tested to see if a cookie is written, and it worked fine (saw cookies in Firefox). But as I browse through the website cookies disappear. This was not the case in the past. The script that writes a cookie is called from .htaccess so it runs every time you access something on the website.

What could cause this to stop working? Where should I look first? I don't mind changing it. Here is what I have now:

Script 1 (on access to write cookies):

$v1 = $_GET['var1'];
$v2 = $_GET['var2'];
//set cookie time
$time_w = time()+(60*60*24*30);
//set cookies
setcookie("var1",$v1,$time_w,"/");
setcookie("var2",$v2,$time_w,"/");
// work around to get above set cookies value in corresponding variables
// without requiring a refresh/reload of the page.
$var1 = $v1;
$var2 = $v2;

A click onto an outgoing link causes this:

HTML file as a redirect so I can use GA for conversions (go.php):

<?php
$v3 = $_GET['var3'];
?>
<meta http-equiv="refresh" content="0;url=<?php print htmlentities("go-out.php?var3=$v3"); ?>" />

(here the outgoing link is like /gooutlinks/go.php?var3=something. A redirect does the job for GA, and passes the var3 variable from go.php to go-out.php)

go-out.php:

include "script2.php";
if ($v3 == "something") {$link = "http://www.example.com";}
header("Location: $link$all");

Finally, the script2.php which is called by include in go-out.php is this:

$t1 = $_COOKIE['var1'];
$t2 = $_COOKIE['var2'];
$v3 = $_GET['v3'];
$all = "$t1^$v3^$t2";

At the end, only v3 gets passed.

Thanks

[whitespace]

But as I browse through the website cookies disappear.

That's presumably when you don't click on an outgoing link? So, "go.php", "go-out.php" and "script2.php" are not processed at this point?

Do the cookies literally "disappear", or are they set to an empty string?

How are you calling script1 from .htaccess? Are you adding var1 and var2 to every internal link? If var1 and var2 are not present on the URL when script1 gets called then you'll get an E_NOTICE and the cookies will be "emptied".

I'm wondering if a few bugs have crept in when exemplifying the code for this forum thread? Since there would seem to be a few bugs, such as in script2.php:

$v3 = $_GET['v3'];

This should presumably be $_GET['var3'] ....?

What does $link get set to if $v != "something"? In your code it's an empty string. You also seem to be missing a slash prefix to your URL-path?

You should enable full error_reporting, at least whilst debugging this:

error_reporting(E_ALL);
ini_set('display_errors','1'); // Unless you have alternative error logging

[Andy Langton]

Script 1 (on access to write cookies):

Does this script check to see if the cookies are already set? It doesn't seem to in your example.

[smallcompany]

Thanks for reply.

That's presumably when you don't click on an outgoing link? So, "go.php", "go-out.php" and "script2.php" are not processed at this point?

True.

Do the cookies literally "disappear", or are they set to an empty string?

After a simple page refresh, cookies are not on the list anymore.

How are you calling script1 from .htaccess?

php_value auto_prepend_file /path/script1.php

After enabling all errors to be written into the error log, I see notices like this:

PHP Notice: Undefined index for the two cookie based variables. (corrected here)

Out of the three variables I only get one from within the site (v3). The two that come via a referring link are not showing up.

To underline, this all happened after an upgrade from 5.4 to 5.5 via WHM by using EasyApache 3. I kept comparing the configs but could not find anything that could ring a bell. I do have a bit more modules installed now, but things like PHAR and SQLITE3 should not affect such simple scripting which should work the same in any PHP 5.x version I believe.
Then I thought if something got corrupted, but no PHP errors happens, site is working fine, PHP redirects are fine, and finally I still get one of the three variables. The two that are cookie based are gone...

Thanks

[edited by: smallcompany at 7:20 pm (utc) on Feb 23, 2016]

[smallcompany]

Does this script check to see if the cookies are already set? It doesn't seem to in your example.

It does not. I guess it would be nice if it does...

[smallcompany]

I keep testing. Because of those notices, I did this:

if (isset($_GET['var1'])) {
$v1 = $_GET['var1'];
}
if (isset($_GET['var2'])) {
$v2 = $_GET['var2'];
}

$time_w = time()+(60*60*24*30);

setcookie("vv1",$v1,$time_w,"/");
setcookie("vv2",$v2,$time_w,"/");
$vv1 = $v1;
$vv2 = $v2;

and I still get notices "PHP Notice: Undefined variable:" for the last four lines. The notices refer to v1 and v2. Shouldn't IF and ISSET prevent it?

Thanks

[whitespace]

The notices refer to v1 and v2. Shouldn't IF and ISSET prevent it?

The IF and ISSET prevent the E_NOTCE for the "undefined index" $_GET[] variable. But if they are not set then neither will $v1 and $v2 be set. So you'll get an "undefined variable" E_NOTICE when these are referenced. Incidentally, these notices are very important as it means you are inadvertently resetting your cookies.

As Andy_Langton suggests, you should be checking whether the cookie is set already, particularly since it's not clear from your code how these URL params are being passed. (From what you've posted, these are not being re-passed?!)

Something like:

// Check that cookie is set first
$v1 = isset($_COOKIE['vv1']) ? $_COOKIE['vv1'] : null;
$v2 = isset($_COOKIE['vv2']) ? $_COOKIE['vv2'] : null;

// But allow value passed in URL to override cookie (?)
$v1 = isset($_GET['var1']) ? $_GET['var1'] : $v1;
$v2 = isset($_GET['var2']) ? $_GET['var2'] : $v2;

// Only set cookie if we have something to set, or proceed anyway?
if ($v1 && $v2) {
  // Set cookies....
  $time_w = time()+(60*60*24*30);
  setcookie('vv1',$v1,$time_w,'/','.example.com');
  setcookie('vv2',$v2,$time_w,'/','.example.com');
}

$vv1 = $v1;
$vv2 = $v2;

It's probably a good idea to be explicit about the cookie domain - this could also explain the cookie disappearance.

[smallcompany]

Thank you very much for this!

I tested it first hand, and found that cookie is there and it stays there after I go to another page or I do a page refresh. I also see that previous notices are not being posted anymore.

I only see notices from another file which works in the conjunction with the initial script, when a variable is called from the cookie. Obviously, since not every visitor comes the same channel, so variables are normally missing in some cases, I would have to rewrite that part as well. The simple call now is:

$t1 = $_COOKIE['vv1'];
$t4 = $_COOKIE['vv4'];

How can I make this to become some sort of IF exists?

For the most important result - tracking variables - I'll have to wait for an hour or two to see new sales in reporting.

Thank you

[Andy Langton]

You want to check that you would be setting the variable to a valid value (i.e. the cookie exists)

if (isset($_COOKIE['vv1'])) {
 $t1 = $_COOKIE['vv1'];
}

You might optionally want a "default" value:

if (isset($_COOKIE['vv1'])) {
 $t1 = $_COOKIE['vv1'];
}
else {
 $t1 = "(Not Provided)";
}

You can also use if shorthand, as per our esteemed colleague whitespace above:

$t1 = isset($_COOKIE['vv1']) ? $_COOKIE['vv1'] : "(Not Provided)";

Note that it looks like you might be needlessly duplicating code - that's something to watch out for as it makes both errors more likely and maintenance more difficult.

[whitespace]

Yes, as Andy says. :)

Just a minor coding style preference... in situations like this (when the variable being checked might not be set) I would nearly always default the value to NULL. It will then evaluate to (bool)false, but you can also still check whether it isset() (a variable that is defined but is NULL is not "set"). It will also convert to an empty string if output.

[Andy Langton]

@whitespace - agreed. However, I was thinking that in this instance it might be tracking the original visitor source:

For the most important result - tracking variables - I'll have to wait for an hour or two to see new sales in reporting.

If so, it might be better to track an actual value (e.g. "no campaign" is better information than "don't know if there's a campaign").

[smallcompany]

I'll just show :) and thank a lot to both. Tracking is back...

I'm still puzzled why it did stop working at the first place.

Finally, this also helped to resolve issues (notices) that have been there for years.

Thank you

[whitespace]

I'm still puzzled why it did stop working at the first place.

I'm guessing that "something else" broke. (!?)

Ordinarily, the changes we've made probably wouldn't have made much of a difference to the original functionality (most of the time). However, your original code seemed to be dependent on the "var1" and "var2" URL parameters being present on all internal requests (how this is achieved is not shown here). If this wasn't happening then you could get the problem you were experiencing, and the changes we made to the code (by checking for an existing cookie) would fix this.

I just rechecked the docs... simply setting the cookie to an empty string will indeed "delete" the cookie it seems. (Even when explicitly setting an expiry date in the future?!)

If the value argument is an empty string, or FALSE, and all other arguments match a previous call to setcookie, then the cookie with the specified name will be deleted from the remote client. This is internally achieved by setting value to 'deleted' and expiration time to one year in past.

Reference: PHP Manual: setcookie() [php.net]

[smallcompany]

This is crazy...

In short, the script worked after some alterations (based on the help through this forum), except I could not get variables from Bing ads. Google worked fine.

Earlier today, I decided to move further and go from PHP 5.5 to 5.6. After doing an update by using EasyApache, all variables stopped coming in.

No errors, no warnings...

Why would server update and reboot do this?

[smallcompany]

Well, there were some warnings (looked into a wrong file), so I'm working on it and will likely post more questions once I nail it down so I don't pull people in here to guess too much.
I apologize for rushing out...

[Andy Langton]

One quick thought - are you both setting and detecting cookies in the same script? Cookies won't be available until the next pageview. E.g.

setcookie("TestCookie", "Hello world");
echo $_COOKIE["TestCookie"];
// result = undefined

This might explain some of the unpredictable behaviour.

[smallcompany]

Thanks very much. I do have a workaround so I get the variable right away without page refresh.

It turned that, after the upgrade to PHP 5.6, split had to be replaced by explode (that was what I found and tried). Now, all gets passed as it should from Google, but Bing still does not work. Now I have someone looking into it as this is beyond my knowledge.