[PAYH] Sudden ridiculous problem

[#1]

Hi
This might sound stupid and must be something so obvious that i cant see it.
I've moved a copy of my live site to the new platform but for some stupid reason, i cant read the parameters that have been passed on a page call.
This is what appears in the address bar when i have clicked on an appropriate link
www.nightowlwebdesign.co.uk/tameside/playerstats.php?LID=1&UDID=1&LgDivString=Midweek%20~%20Premier%...
But if i do

echo "UDID = ".$UDID;

all i get is UDID =
The same applies to anything that is passed in any of the pages
For reference, The live site is at http://www.jnmbc.co.uk and there you can see how it's supposed to work
Whats causing this?????????????

[#2]

Does this help:
http://uk3.php.net/manual/sl/ini.sect.data-handling.php#ini.register-globals

[#3]

Thanks for that Jelv
Yes i believe that's the problem
If Register Globals = Off then that means I'm going to have to use $_POST and $_GET for all my code which is a real pain because theres a lot of it so whats the best way round it?
If i could edit the PHP.ini file then changing Register Globals = on would compromise security so that's no good either
NEW EDIT
It seems my best option, even though it's a pain to change all the code in my current site, is to use the $_GET[whatever] method from now on.
This is one instance where the switch over to PHP 5 has not been too friendly for me. It maybe that i have bad habits and the method i was using previously was not wise.
Any comments/advice?

[#4]

On some servers you can override the default register globals setting with a line in your .htaccess file

php_flag register_globals on

If this facility is enabled on the PAYH servers you could try this, but from what little I've read about these things it's more secure to have register globals set to off so amending your code would seem to be the better option.

[#5]

In fact come PHP 6 the Register Globals directive will be removed from PHP as advised in the warning notice on the Using Register Globals article in the Security section of the PHP manual (see attached image). Hence it makes sense to convert code now.
The following quote comes from the referenced article and provides background for making the change:

Quote

When on, register_globals will inject your scripts with all sorts of variables, like request variables from HTML forms. This coupled with the fact that PHP doesn't require variable initialization means writing insecure code is that much easier. It was a difficult decision, but the PHP community decided to disable this directive by default (Ed: applies to PHP » 4.2.0). When on, people use variables yet really don't know for sure where they come from and can only assume. Internal variables that are defined in the script itself get mixed up with request data sent by users and disabling register_globals changes this.

It is perhaps worth mentioning that the Magic Quotes feature will also be removed come PHP 6 (second attachment).

[#6]

Thanks for your comments Spraxyt and me
I've read the areas you have mentioned including that about php 6 and about the security issues if you turn register globals to on so i have made the alterations to my code on a couple of pages to satisfy myself that it will work and yes it's does.
It's worth noting for anyone else who is moving from PHP4 to 5 that previously the string www.mydomain.co.uk/somepage.php?id=234
Automatically creates the variable $id
But now in version 5 (4.2 or above)
you have to assign it with
$id = $_GET[id];
Equally, any html form field data that is POSTED used to automatically create a variable like $FieldName but again, you would now have to assign it to the variable using $_POST
$FieldName = $_POST[FieldName];
More coding but more secure

[#7]

Thanks for the feedback. Just a small correction to the examples, I think the form-field names in square brackets need to be enclosed in single or double quotes.
$id  = $_GET['id']; // and
$FieldName = $_POST['FieldName'];

[#8]

hmmmm - I don't know
Mine works perfectly without the quotes? here is a snippet of actual code from my feeback.php page

<?php
		$mode		= $_GET[mode];		
		$txtName		= $_POST[txtName];
		$txteMail		= $_POST[txteMail];
		$txtComments	= $_POST[txtComments];
		if($mode=="submit")
		{
			//do the email bit
			$subject = "JNMBC Website Feedback";
			$from = "From: $txtName [$txteMail]";
			$message = "
			<html>
				<head></head>
				<body>
					<p>$txtComments</p>
				</body>
			</html>";
			
			$headers  = "MIME-Version: 1.0 \r\n";
			$headers .= "Content-type: text/html; charset=iso-8859-1 \r\n";
			$headers .= "From: $txteMail";//this would normally be the email address			
			
			if(mail("webmaster@jnmbc.co.uk",$subject,$message,$headers))
			{
?>

[#9]

Hi,

Quote from: SoulBriski

hmmmm - I don't know Mine works perfectly without the quotes? here is a snippet of actual code from my feeback.php page ...

Whilst it works - it is wrong    from php.net

Quote

Why is $foo[bar] wrong? Always use quotes around a string literal array index. For example, $foo['bar'] is correct, while $foo[bar] is not. But why? It is common to encounter this kind of syntax in old scripts: <?php $foo[bar] = 'enemy'; echo $foo[bar]; // etc ?> This is wrong, but it works. The reason is that this code has an undefined constant (bar) rather than a string ('bar' - notice the quotes). PHP may in future define constants which, unfortunately for such code, have the same name. It works because PHP automatically converts a bare string (an unquoted string which does not correspond to any known symbol) into a string which contains the bare string. For instance, if there is no defined constant named bar, then PHP will substitute in the string 'bar' and use that.

The advice is to use the correct format - because the above (incorrect usage) will not be supported 'forever' according to the PHP folks.
HTH 

[#10]

Thanks very much for the lesson Pod. Well explained and obviously good advice
I will amend my code accordingly