“Notice: Undefined variable”, “Notice: Undefined i

Question

I'm running a PHP script and continue to receive errors like:

Notice: Undefined variable: my_variable_name in C:\wamp\www\mypath\index.php on line 10

Notice: Undefined index: my_index C:\wamp\www\mypath\index.php on line 11

Line 10 and 11 looks like this:

echo "My variable value is: " . $my_variable_name;
echo "My index value is: " . $my_array["my_index"];

What is the meaning of these error messages?

Why do they appear all of a sudden? I used to use this script for years and I've never had any problem.

How do I fix them?

---

_{This is a General Reference question for people to link to as duplicate, instead of having to explain the issue over and over again. I feel this is necessary because most real-world answers on this issue are very specific.}

_{Related Meta discussion:}

• _{What can be done about repetitive questions?}
• _{Do “reference questions” make sense?}

Answer 1

Regarding this part of the question:

Why do they appear all of a sudden? I used to use this script for years and I've never had any problem.

No definite answers but here are a some possible explanations of why settings can 'suddenly' change:

1. You have upgraded PHP to a newer version which can have other defaults for error_reporting, display_errors or other relevant settings.

2. You have removed or introduced some code (possibly in a dependency) that sets relevant settings at runtime using ini_set() or error_reporting() (search for these in the code)

3. You changed the webserver configuration (assuming apache here): .htaccess files and vhost configurations can also manipulate php settings.

4. Usually notices don't get displayed / reported (see PHP manual) so it is possible that when setting up the server, the php.ini file could not be loaded for some reason (file permissions??) and you were on the default settings. Later on, the 'bug' has been solved (by accident) and now it CAN load the correct php.ini file with the error_reporting set to show notices.

Answer 2

In PHP 7.0 it's now possible to use Null coalescing operator:

echo "My index value is: " . ($my_array["my_index"] ?? '');

Equals to:

echo "My index value is: " . (isset($my_array["my_index"]) ? $my_array["my_index"] : '');

PHP manual PHP 7.0

Answer 3

I use all time own useful function exst() which automatically declare variables.

Your code will be -

$greeting = "Hello, ".exst($user_name, 'Visitor')." from ".exst($user_location);


/** 
 * Function exst() - Checks if the variable has been set 
 * (copy/paste it in any place of your code)
 * 
 * If the variable is set and not empty returns the variable (no transformation)
 * If the variable is not set or empty, returns the $default value
 *
 * @param  mixed $var
 * @param  mixed $default
 * 
 * @return mixed 
 */

function exst( & $var, $default = "")
{
    $t = "";
    if ( !isset($var)  || !$var ) {
        if (isset($default) && $default != "") $t = $default;
    }
    else  {  
        $t = $var;
    }
    if (is_string($t)) $t = trim($t);
    return $t;
}

Answer 4

the quick fix is to assign your variable to null at the top of your code

$user_location = null;

Answer 5

If working with classes you need to make sure you reference member variables using $this:

class Person
{
    protected $firstName;
    protected $lastName;

    public function setFullName($first, $last)
    {
        // Correct
        $this->firstName = $first;

        // Incorrect
        $lastName = $last;

        // Incorrect
        $this->$lastName = $last;
    }
}

Answer 6

Error display @ operator

For undesired and redundant notices, one could use the dedicated @ operator to »hide« undefined variable/index messages.

$var = @($_GET["optional_param"]);

• This is usually discouraged. Newcomers tend to way overuse it.
• It's very inappropriate for code deep within the application logic (ignoring undeclared variables where you shouldn't), e.g. for function parameters, or in loops.
• There's one upside over the isset?: or ?? super-supression however. Notices still can get logged. And one may resurrect @-hidden notices with: set_error_handler("var_dump");
  • Additonally you shouldn't habitually use/recommend if (isset($_POST["shubmit"])) in your initial code.
  • Newcomers won't spot such typos. It just deprives you of PHPs Notices for those very cases. Add @ or isset only after verifying functionality.

  • Fix the cause first. Not the notices.

• @ is mainly acceptable for $_GET/$_POST input parameters, specifically if they're optional.

And since this covers the majority of such questions, let's expand on the most common causes:

$_GET / $_POST / $_REQUEST undefined input

• First thing you do when encountering an undefined index/offset, is check for typos:
  $count = $_GET["whatnow?"];

  • Is this an expected key name and present on each page request?
  • Variable names and array indicies are case-sensitive in PHP.

• Secondly, if the notice doesn't have an obvious cause, use var_dump or print_r to verify all input arrays for their curent content:

  var_dump($_GET);
  var_dump($_POST);
  //print_r($_REQUEST);
  

  Both will reveal if your script was invoked with the right or any parameters at all.

• Alternativey or additionally use your browser devtools (F12) and inspect the network tab for requests and parameters:

  

  POST parameters and GET input will be be shown separately.

• For $_GET parameters you can also peek at the QUERY_STRING in

  print_r($_SERVER);
  

  PHP has some rules to coalesce non-standard parameter names into the superglobals. Apache might do some rewriting as well. You can also look at supplied raw $_COOKIES and other HTTP request headers that way.

• More obviously look at your browser address bar for GET parameters:

  http://example.org/script.php?id=5&sort=desc

  The name=value pairs after the ? question mark are your query (GET) parameters. Thus this URL could only possibly yield $_GET["id"] and $_GET["sort"].

• Finally check your <form> and <input> declarations, if you expect a parameter but receive none.

  • Ensure each required input has an <input name=FOO>
  • The id= or title= attribute does not suffice.
  • A method=POST form ought to populate $_POST.
  • Whereas a method=GET (or leaving it out) would yield $_GET variables.
  • It's also possible for a form to supply action=script.php?get=param via $_GET and the remaining method=POST fields in $_POST alongside.
  • With modern PHP configurations (≥ 5.6) it has become feasible (not fashionable) to use $_REQUEST['vars'] again, which mashes GET and POST params.

• If you are employing mod_rewrite, then you should check both the access.log as well as enable the RewriteLog to figure out absent parameters.

$_FILES

• The same sanity checks apply to file uploads and $_FILES["formname"].
• Moreover check for enctype=multipart/form-data
• As well as method=POST in your <form> declaration.
• See also: PHP Undefined index error $_FILES?

$_COOKIE

• The $_COOKIE array is never populated right after setcookie(), but only on any followup HTTP request.
• Additionally their validity times out, they could be constraint to subdomains or individual paths, and user and browser can just reject or delete them.