Justtechjobs.com Find a programming school near you






Online Campus Both


php-install | 2004032

Re: [PHP-INSTALL] Undefined constant errors - possible global variable problem? From: Chris Hewitt (g0pae <email protected>)
Date: 03/27/04

michaelrflora <email protected> wrote:

>Chris Hewitt <g0pae <email protected>> wrote:
>
>>>>Warning: undefined constant 'general_user_attrs' used as general_user_attrs in /var/www/html/dialup_admin/htdocs/user_new.php3 line 12
>>>>
>>>>The constant general_user_attrs is a user-defined parameter defined in the .conf file for the application. The .conf file is read in by a php function that stores all parameters in an array called $config. This array is referenced in php files throughout the application tree.
>>>>
>>>>It *appears* that $config is not being passed by php to all the separate files. Do I have to manually configure php to do this? Or is the problem something else altogether? This application (dialup_admin) is not a beta, rather is in general use. I am using Red Hat 7.2, PHP 4.0.6, Apache 1.3.20.
>>>>
>
>>How are you passing $config from file to file? (You do not show us what
>>is in line 12 or the first occurance of $config in the file). It either
>>needs to be in a $_SESSION variable or you application needs
>>register_globals turned on in php.ini.
>>
>>HTH
>>Chris
>>
>Thanks for your reply. I didn't write dialup_admin and I know little about php, so I am only assuming the app is written correctly.
>
>Yes, register_globals is turned on in php.ini by default. I don't know how $config is passed from file to file; that is part of my problem. I am assuming it is a global and that php recognizes it as such. The .conf file gives me the option of using sessions; I think I have tried it both ways with no good results.
>
>The file user_new.php3 contains the following lines:
>
>require('../conf/config.php3'); #This is the file that reads admin.conf and puts its parameters into the $config array
>require('../lib/defaults.php3'); #This file references $config
>
>The file ../lib/defaults.php3 looks like this:
>
><?php
>$ARR=file("$config[general_default_file]");
>.
>.
>.
>if (is_file("../lib/$config[general_lib_type]/defaults.php3"))
> include("../lib/$config[general_lib_type]defaults.php3"));
>
>Php doesn't like general_lib_type in these lines, referring to it as an undefined constant even though it is set in the .conf file. BTW, this code works if I replace $config[general_lib_type] with the actual subdirectory where defaults.php3 lives. Doing this, however, just causes me to have more warnings further down the application tree.
>
>Any thoughts or ideas would be helpful.
>
>Regards,
>Michael Flora
>
>"Life is infinitely stranger than anything which the mind of man could invent." -- Sherlock Holmes in "A Case of Identity"
>
Michael,

I should have spotted this earlier and now kick myself for not doing so;
being busy at the time I was just not looking hard enough. If you use an
array that is not within double-quotes then the syntax is correct, that is:
$foo = $config[general_lib_type];
will produce the correct result. If within double-quotes, as you are
using it, then you need to put the whole array reference within
curly-braces "{}" so that:
echo "The value is {$config[general_lib_type]}";
will again produce the correct result. The alternative is to remove the
array from the double-quotes and use a syntax like:
echo "The value is ".$config[general_lib_type];

When outside double-quotes it is easier for the PHP parser to tell what
should be done, when within double-quotes then it also has to try to
tell whether the characters should be treated as text. Using a syntax
involving wrapping an array in delimiters makes the parser's job totally
unambiguous.

As I presently see it, I feel this is unnecessary and resuts in
"unexpected" behaviour. I don't see the ambiguity. The parser goes along
the line and comes to the $ sign. If within double-quotes finding this $
sign is the signal to stop treating characters as literals as there is
now a variable to interpret. Continuing along the line, the parser would
now be looking for a delimiter to indicate the end of the name of the
variable (white space, equals sign etc.) but instead encounters the
opening square bracket. This is the end of the variable but indicates it
is an array. Looking further along the line it would find the closing
square bracket so what is inbetween is the index to the array. If the
index begins with a $ sign then the index is another variable so it
substitutes the value of this second variable to use as the array index.
If the index is in single-quotes then the index is clearly a literal. It
is the case where it is neither that the behaviour between the whole
array being in double-quotes or not differs.

If the index is not a number then (with the array outside of
double-quotes) it checks to see if it is a defined constant (done with
the define() function). If not it treats as though it were a
single-quoted literal. When the array is within double-quotes the first
stage (checking defined constants) is omitted.

Perhaps someone on this list with more knowledge would please let me
know why this is omission is needed, I admit I do not see it.

All this does not help your particular problem. Presumably (as your file
names end in ".php3") the code you have did operate correctly under a
version of PHP3? I wonder which version? In looking at this today, I
downloaded and compiled PHP 3.0.18 (the only V3 version on
http://www.php.net) and (using the command-line version due to
apxs/apxs2 differences with my Apache httpd 2 on my Fedora Core test
system) got the same results. I then downloaded and compiled the latest
CVS snapshot (from 3.30 this afternoon) and also got the same result. I
conclude that this is the intended behaviour but feel it is not the
expected behaviour. All I can suggest is that you will need to use one
of the two workarounds shown in my first paragraph above.

Regards

Chris
P.S. The "require('config.php3')" in your default.php3 loads the code
from config.php3 as though it were part of default.php3 so the
register_globals configuration setting is not relevant to your problem.