Accessing form variables directly, such as $submit, was recognised as a security risk quite some time back, and is now controlled by a php.ini setting REGISTER_GLOBALS, which is by default turned off. You now need to access the variables from their source, so for POSTed form variables, they are in the $POST associative array, and GETed vars are in $GET. This is why you need to reference $_POST["submit"] instead of $submit.
If you're interested, here's an example of how having REGISTER_GLOBALS turned on could be a problem unless you are careful with your code:
<?php
//This script is called with a suername and password. The username and password
//are checked, and if valid some secret info is displayed.
//call a function to check if the username and password are valid
if (validUser($username, $password)){
$loggedin=TRUE;
}
if ($loggedin){
//only logged in users should get this
displaySecretInfo();
}
If this looks ok to you, what happens if I call the script with a parameter called loggedin with a value of TRUE, in addition to username and password? I don't know a valid username and password, so the validuser function fails. But that doesn't matter because when we get to the if statement, the value of loggedin is pulled from whatever I passed in, so I get to see the secret info.
With REGISTER_GLOBALS turned off, the version below is perfectly safe, because we never access the injected value for loggedin.
<?php
//This script is called with a suername and password. The username and password
//are checked, and if valid some secret info is displayed.
//call a function to check if the username and password are valid
if (validUser($_POST['username'], $_POST['password'])){
$loggedin=TRUE;
}
if ($loggedin){
//only logged in users should get this
displaySecretInfo();
}
Of course, it would be much better to explicitly set $loggedin to false if the authentication fails. 😉