Leaderboard

As @mac_gyver stated, the problem is that line to check if the 't' value was sent. The way it is constructed, that condition will return true if the value is not set OR if the value is interpreted as false (which a zero value will be). You state that this was working for over 12 years and no changes were made to the code. I find that unlikely as PHP would have always interpreted a 0 as false in that condition (as far as I am aware). Perhaps that condition was previously written in a more explicit manner to account for a team ID of zero. E.g. if(!isset($_GET['t']) || ($_GET['t']===false) And someone looked at it and thought the code was more complicated than it needed to be and "fixed" it to be simpler. So, your issue turned out to be exactly what I had hypothesized. You can either find all instances where teamID may be used in your code to ensure that a zero value will always work (poor fix) or (the right solution) change the primary key for that team to another value and then change the foreign key references to that ID.

this is the problem. a zero is a false value and the code is performing the header redirect. as to why it 'worked' before, something was probably preventing the header() from working (output being sent, which would have been producing a php error, should you have been able to display/log it) but since there's no exit/die statement after the redirect, the rest of the code on the page still ran in this case, so, you got the expected output for a zero value. something probably changed in the server configuration, such as php's output_buffing setting getting turned on, which would now buffer whatever the output is, allowing the header() to work. i wonder if your login access check code has exit/die statements after redirects to stop the rest of the code on the page from being executed? you should also not put any external data directly into sql queries, where any sql special characters can break the sql query syntax, which is how sql injection is accomplished.