Forum Moderators: coopster
if (!isset($_COOKIE['referral'])) {
setcookie(referral, $_GET['ref'], 2592000 + time());
}
But I am getting this error alot
8: Undefined index: ref
This is the link used
http://www.example.com/index.php?ref=blah
Advice please, lol Im really tired :).
Thanks
[edited by: coopster at 2:15 am (utc) on April 1, 2007]
[edit reason] exemplified url [/edit]
http://www.example.com/index.php
First, you need to know that the $_GET superglobal is going to contain only those variables (name/value pairs) that are passed in the QUERY STRING (that stuff after the? in your URL). So you could use isset() [php.net] to check if the variable exists first.
In my own code, I like to do things like coopster showed you. Just good practice.
As we've mentioned, it's a good practice to eliminate warnings.
However, if you don't want them displayed (I tend to turn them off for "live" servers, and on for "sandbox" servers), you do this:
ini_set('display_errors', 1);
ini_set('error_reporting', E_ERROR); Warnings will not be shown. If you do this:
ini_set('display_errors', 1);
ini_set('error_reporting', E_ALL); or this:
ini_set('display_errors', 1);
ini_set('error_reporting', E_ERROR ¦ E_WARNING); they will.
Talks about it here [us.php.net].
One thing about PHP is that it is an interpreted language. That basically means that it won't register an error or warning until it comes upon that error. The exception is for structural errors, like improperly closed brackets.
This is different from compiled languages, like C++, where everything needs to resolve before the code is deployed.
In an interpreted language, if you never encounter a code path during runtime, you never get to see any problems with that code. In C++, we have a concept called "code coverage," which indicates which parts of the code are being called when. If we look at a code coverage map, and see that a subroutine is not being called, then it may indicate a bug, or an appendix that can be removed. It may also indicate some badly-written or untested code that could blow up as soon as we use it.
What does this have to do with this type of issue?
In PHP, you can prevent execution of an entire path that would otherwise generate warnings and/or errors. It will not generate these warnings. You can't really do that in C++.
This is both good and bad. It can give us great power, and really nasty bugs.
For example, say that you have a series of parameters that all work together:
index.php?verbose_output=1&show_values=1&show_names=1 Now,
show_values and show_names only make sense if verbose_output is set. In your PHP, you may have this:
$verbose = $_GET['verbose_output'];
$values = $_GET['show_values'];
$names = $_GET['show_names']; These will generate a number of warnings if they are declared in this fashion.
What we would do to stop that would be:
if(isset($_GET['verbose_output'])){
$verbose = $_GET['verbose_output'];
$values = $_GET['show_values'];
$names = $_GET['show_names'];
} There's one problem with this, however. If
verbose_output is set, but neither of the other two options are set, then you will still get warnings when you use verbose_output. You can remedy that in two ways:
if(isset($_GET['verbose_output'])){
$verbose = $_GET['verbose_output'];
if(isset($_GET['show_values'])){
$values = $_GET['show_values'];
}
if(isset($_GET['show_names'])){
$names = $_GET['show_names'];
}
} or
if(isset($_GET['verbose_output'])){
$verbose = $_GET['verbose_output'];
}
if(isset($_GET['show_values'])){
$values = $_GET['show_values'];
}
if(isset($_GET['show_names'])){
$names = $_GET['show_names'];
}
It looks like you are setting a cookie, and don't want to set it if it already exists. There are a couple of variables involved, and one of them is a parameter that is provided on the URI calling the page. If this is not provided, then you can't set the cookie anyway.
In the example you give, I assume that "$ref" is the same as "$_GET['ref']". Note also that you don't have a dollar sign in front of "referral." If the idea is to call the cookie "referral", then this is fine, as PHP will assume that this is a string value. However, just as a best practice, I would still surround it in quotes to make it clear that it's a string value.