Hi there,

I have a question for PHP experts on this board.

As most of you might have known, this action can be done with php:


Eg: Let's say I place this code on my index.php file and upload it to my server (public_html):

<?php echo "$nick"; ?>


And then if I type in the following URL:

http://www.mydomain.com/index.php?nick=123

The code on the page will be replaced by the value 123.


Now I have been doing these for many months successfully.


However, since the day I moved to a new server, this doesn't seem to work anymore. The code does not replace itself into anything.

Therefore my question now is:

Are there any part of my server's PHP values that are disabled which cause
this action to stop working?

or

Is it simply because PHP has change the way it behaves that this action will not work anymore anywhere?

Thanks.

Replace $nick with $_GET['nick'] or a similar variable.

The php flag register_globals is turned off on your server for security reasons (this is a good thing, trust me). You can turn it on via a .htaccess file or in your VHost config.

Edit: obviously, inside quotes, it would be {$_GET['nick;']}

Thanks for your reply localhost127,

By the way I don't understand clearly what you mean.

Must I turn on the php flag register_global or can I just use the code
that you gave me below in order to make it work? (even if the register
global is turned off)

$_GET['nick']

Use the superglobal arrays $_GET[], $_POST[], etc, from now on. The way you were doing it poses a real security threat. Believe me, you do not want register_globals turned on. Just replace all of your variables to reflect the change.

$_GET[] is an array of all the values in the URL string. Take your example:
?nick=123
PHP will assign the following variable:
$_GET['nick'] = 123

If you use a form to POST the data, then use the $_POST[] array.

The superglobal arrays can and should always be used no matter what register_globals is, and honestly, if you ever find out that register_globals is turned on, then turn it off yourself using .htaccess if you can.

Should the code looks like this now:

<?php echo "{$_GET['nick;']}"; ?>

I did that and it didn't work. (I hope I'm wrong)

Well the tech guy of my webhosting company gave me the htaccess code and now it's working fine. :-)

Thanks.

i HIGHLY recommend leaving register_globals off, as GamePhreak also suggested.

The correct code would be


<?php echo $_GET['nick']; ?>

//or

<?=$_GET['nick']?>

//or

<? echo "{$_GET['nick']}"; ?>

Well the tech guy of my webhosting company gave me the htaccess code and now it's working fine. :-)

Thanks.
Leaving register_globals on is a huge security issue. Your webhost should not have even told you how to do that, because now they are risking the security of their server based upon the security of your script, and unless you really know what you are doing, PHP is one of the most insecure server-side scripting languages out there.

Thanks everyone for your replies!

I have removed the htaccess file from my server and use the codes given by localhost127.

They work well now.

By the way, I think the tech guy gave me the htaccess code because I'm on my own dedicated server (not shared hosting) and so since I asked for it, most of the risk is on me... :-)

Thanks again for all your help!! :) :) :) :agree: :agree:

Should the code looks like this now:

<?php echo "{$_GET['nick;']}"; ?>

I did that and it didn't work.

you dont want the extra ; it should have been <?php echo "{$_GET['nick']}"; ?>

It's been a few times I saw the use of {} to echo a variable ... what is the real use ?

since you can do anyway <? echo "$variable"; ?>

since you can do anyway <? echo "$variable"; ?>

Even that's excessive...

If you are only echoing a variable, use:


<?= $variable ?>


If you want use a variable, there's no need to wrap it in double quotation marks.


<?php
$abc = '123';
echo $abc;
?>


Lastly, if you want a disjunct variable in a string, then the curly braces serve as separation.


<?php
echo "There was a nice set of {$placevar}s down the road";
?>


Consider that the above is irreplaceable, since you wouldn't be able to write:


<?php
echo "There was a nice set of $placevars down the road";
?>


...given that $placevar is an entirely different variable from $placevars - but we want the s appended to the output!

Note that as of PHP5, you can use $_REQUEST which encompasses $_GET and $_POST. I'll agree with the above however, NEVER USE REGISTER GLOBALS! They are pure evil, and will cause bugs, vulnerabilities, headaches, hair loss, which could result in a hike in blood pressure, and eventually death!

Use $_REQUEST or $_GET/$_POST, and remember to filter input always.

Good luck with your projects!
Alex

So the {} are only used if the variable is sticked with something that is not a space.

I prefer to do <? echo "There was a nice set of " . $placevar . "s down the road"; ?> in my case ;) (cleaner)

Invoking cleaner becomes a matter of taste I suppose. If you use a good IDE, variables will appear in a different color, and so will be cleanly denoted in either format.

I'd add though that you can spare some code again, don't bother putting echo, if all you are doing is echoing a string or variable. Consider if you prefer:

<?= "There was a nice set of " . $placevar . "s down the road" ?>

Use single quotes too if necessary. Your script will run faster, which may not seem like much if it's small but on large scripts that are frequently accessed, this can be crucial!

Use single quotes too if necessary. Your script will run faster, which may not seem like much if it's small but on large scripts that are frequently accessed, this can be crucial!I think this may have been true long ago, but I did read definite benchmarks in php|architect that the difference is at present, incredibly negligible (nanoseconds per run). Quite a few such benchmarks exist, see http://www.php.lt/benchmark/phpbench.php for example.

So the {} are only used if the variable is sticked with something that is not a space.

I prefer to do <? echo "There was a nice set of " . $placevar . "s down the road"; ?> in my case ;) (cleaner)

To clarify in case someone didn't quite catch it, the {}'s inside a string are ALSO necessary if you are accessing an array or a structure or a position at a string, no matter what.

I have not benchmarked efficiency, but i would think that the efficiency would play out as follows:


//fastest
echo $array['val'];

//faster
echo 'this is my ' . $array['val'];

//slowest
echo "{$array['val']}"


It seems like parsing a string for variables would be a slightly costly operation, which is where the single quotes as someone else posted earlier would help, but if you are using double quotes then PHP has to parse the string for variables anyways.

Also, for PHP4/PHP5 compatibility in my scripts, i tend to use the following:


$_REQUEST=array_merge($_GET,$_POST);


This way i do not have to worry about whether or not i just did a GET or a POST, and i do not have to check if i'm running PHP5 or not.

I did my own tests, and no the difference between single and double quotes is not that much, but I'm crazy about that, so I do it. I don't mind if somebody uses double-quotes, though. What really gets at me is when people do this:
$var = "{$_POST['var']}";
1) There's no reason to redeclare
2) What are you thinking!?!... Using quotes there!?!

I did my own tests, and no the difference between single and double quotes is not that much, but I'm crazy about that, so I do it. I don't mind if somebody uses double-quotes, though. What really gets at me is when people do this:
$var = "{$_POST['var']}";
1) There's no reason to redeclare
2) What are you thinking!?!... Using quotes there!?!

I can understand being angry about that in general, however in this specific thread i originally posted that because i assumed he was going to add some static content to the string.

I agree that doing that alone is utterly pointless.

<?= $variable ?>

This is quite bad advice, since the short open tags (which is the feature that enables <?= to work) can be changed from server to server. If you write your script with <?= and it is moved to another machine that has short open tags off, your script will not run.

The recommended way is to use <?php echo to guarantee output.

Go complete the Zend certification - you'll find they recommend its use as well. Not sure why you would call this bad advice, on a setting that is enabled by default. SOTs have to be explicitly disabled, and there's never any reason to do so.

SOTs have to be explicitly disabled, and there's never any reason to do so.

You obviously have not had to do much in terms of migrating PHP apps. Experience counts more than what some book says :)

Experience counts more than what some book saysThat statement is a bit rude, but I'll look past it.

All you have to do, is go into php.ini, short_open_tag = On. Hardly a headache!

Otherwise writ, good job in the other post about PHP being insecure, what a nightmare thread.

That statement is a bit rude, but I'll look past it.

Sorry for that Alex, was not my intention. What you mentioned is easy enough when talked about -- but I have run into many situations where a simple change (as you have mentioned above) puts a break on the whole project.

Therefore, after being burned a few times in terms of time wasted and deadlines extended, I only use <?= on servers that I control, and leave the tired-but-true <?php echo for anyone else.

On a side note, I never see the other syntax being used a lot.

I can respect the precautions taken - but it's a very useful syntax, especially when used in conjunction with PHP alternative syntax to display templates and the like. Once can then easily identify blocks whose purpose are solely that of output, and these can then easily be manipulated by a tertiary means, perhaps a pre-output filter.

Both methods have merit I suppose, but one shouldn't avoid it simply because of a php.ini setting :)

I'll stop here, I think we've come to an agreement :)

Not trying to prolong this argument any further, just wanted to point out that you can toggle short tags in a .htaccess as well


php_flag short_open_tag 1