Forum Moderators: coopster
I've checked it out, and it seems that the problem is that any parameters in the url, after the question mark, are simply being ignored. The way the thing is written, a .php file displays a list, and the same .php file is called again after a choice has been made, but this time with parameters in the url to express the choice that's been made. So:
www.example.com/view.php
Displays a list. Clicking on a link in that list calls:
www.example.com/view.php?submit=yes&RecordID=1
And the conditional branching within that file should cause it to act differently the second time, because now $submit == "yes". But it doesn't; the html generated is exactly the same as it was when no parameters were present in the url.
This sort of behavior now happens on any of the pages in the site, including a login page in which the parameters should be passed through a form POST.
I didn't write this thing and am pretty much inexperienced with PHP, but it's fairly simple to follow what should be happening... and again, it did work at one time. So is there some configuration change, perhaps, that could affect it? I realize this is probably hard to follow without seeing the site and code in question, but does anyone have any hints?
$submit=$HTTP_GET_VARS['submit'];
If you can do it like that, it appears that your host might have turned off the automatic variable registering (in the PHP configuration file, register_globals = Off )
If that's the case I don't think you can find a way around it other than manually defining all the variables using $HTTP_GET_VARS or $HTTP_POST_VARS
Just a hunch, but I reckon the host just upgraded their php engine. Try accessing the url vars with the $_GET['value'] array instead of just $value
I don't know whether there actually was an upgrade or if there was another reason for the change, but this did the trick. Thanks Nick, and everyone, for the quick help.
So now I have an excuse to go through every line of this thing to find everywhere else this comes into play.