| Undefined variable [message #181235] |
Wed, 24 April 2013 02:16  |
Question Boy
Messages: 8
Registered: April 2011
Karma: 0
|
Junior Member |
|
|
I have an simple MySQL/PHP app and it appears to be functional but the
webmaster has informed me that it is throwing lots of errors. So he
showed me the log file and I am trying to remedy the issues, but have
a question.
For instance, I have a block of code, such as:
if ($iBookedBy=="Other") {
echo '<option selected value="Other">Other</option>';
} else {
echo '<option value="Other">Other</option>';
}
which the log file reports as:
PHP Notice: Undefined variable: iBookedBy
Now I thought of trying:
if (isset($iBookedBy)==TRUE && $iBookedBy=="Other") {
echo '<option selected value="Other">Other</option>';
} else {
echo '<option value="Other">Other</option>';
}
but am not sure if the server will break because the variable isn't
set or if it will still throw an error because of the second,
original, part of the if statement? Is this a good way to handle the
problem, or am I going about this the wrong way and there is a better
method?
Thank you for your help.
QuestionBoy
|
|
|
|
|
|
| Re: Undefined variable [message #181237 is a reply to message #181235] |
Wed, 24 April 2013 03:08  |
Richard Yates
Messages: 86
Registered: September 2013
Karma: 0
|
Member |
|
|
On Tue, 23 Apr 2013 19:16:54 -0700 (PDT), Question Boy
<question(dot)boy(at)hotmail(dot)com> wrote:
> I have an simple MySQL/PHP app and it appears to be functional but the
> webmaster has informed me that it is throwing lots of errors. So he
> showed me the log file and I am trying to remedy the issues, but have
> a question.
>
> For instance, I have a block of code, such as:
>
> if ($iBookedBy=="Other") {
> echo '<option selected value="Other">Other</option>';
> } else {
> echo '<option value="Other">Other</option>';
> }
>
> which the log file reports as:
>
> PHP Notice: Undefined variable: iBookedBy
>
>
>
>
> Now I thought of trying:
>
> if (isset($iBookedBy)==TRUE && $iBookedBy=="Other") {
> echo '<option selected value="Other">Other</option>';
> } else {
> echo '<option value="Other">Other</option>';
> }
>
>
> but am not sure if the server will break because the variable isn't
> set or if it will still throw an error because of the second,
> original, part of the if statement? Is this a good way to handle the
> problem, or am I going about this the wrong way and there is a better
> method?
>
> Thank you for your help.
>
> QuestionBoy
1. Yes, it will prevent the error notice.
2. You do not need the ==TRUE. isset($iBookedBy) means the same
isset($iBookedBy)==TRUE.
3. Your asking the question suggests that you are trying to write code
and run it directly on a production server rather than testing on a
local server. The webmaster will be happier, and you will be much more
productive, if you set up a local server like WAMP.
|
|
|
|
| Re: Undefined variable [message #181238 is a reply to message #181237] |
Wed, 24 April 2013 03:27 |
Question Boy
Messages: 8
Registered: April 2011
Karma: 0
|
Junior Member |
|
|
On Apr 23, 11:08 pm, Richard Yates <rich...@yatesguitar.com> wrote:
> On Tue, 23 Apr 2013 19:16:54 -0700 (PDT), Question Boy
>
>
>
>
>
>
>
>
>
> <question....@hotmail.com> wrote:
>> I have an simple MySQL/PHP app and it appears to be functional but the
>> webmaster has informed me that it is throwing lots of errors. So he
>> showed me the log file and I am trying to remedy the issues, but have
>> a question.
>
>> For instance, I have a block of code, such as:
>
>> if ($iBookedBy=="Other") {
>> echo '<option selected value="Other">Other</option>';
>> } else {
>> echo '<option value="Other">Other</option>';
>> }
>
>> which the log file reports as:
>
>> PHP Notice: Undefined variable: iBookedBy
>
>> Now I thought of trying:
>
>> if (isset($iBookedBy)==TRUE && $iBookedBy=="Other") {
>> echo '<option selected value="Other">Other</option>';
>> } else {
>> echo '<option value="Other">Other</option>';
>> }
>
>> but am not sure if the server will break because the variable isn't
>> set or if it will still throw an error because of the second,
>> original, part of the if statement? Is this a good way to handle the
>> problem, or am I going about this the wrong way and there is a better
>> method?
>
>> Thank you for your help.
>
>> QuestionBoy
>
> 1. Yes, it will prevent the error notice.
>
> 2. You do not need the ==TRUE. isset($iBookedBy) means the same
> isset($iBookedBy)==TRUE.
>
> 3. Your asking the question suggests that you are trying to write code
> and run it directly on a production server rather than testing on a
> local server. The webmaster will be happier, and you will be much more
> productive, if you set up a local server like WAMP.
Thank you for the reply.
I was always under the impression that it was always beneficial to
explicitly put ==TRUE to avoid any arbitrary interpretations. I won't
waste my time anymore.
My test server was not reporting any errors. I will look into which
setting has to be changed.
Thank you once again.
|
|
|
|
| Re: Undefined variable [message #181239 is a reply to message #181238] |
Wed, 24 April 2013 03:49 |
Question Boy
Messages: 8
Registered: April 2011
Karma: 0
|
Junior Member |
|
|
On Apr 23, 11:27 pm, Question Boy <question....@hotmail.com> wrote:
> On Apr 23, 11:08 pm, Richard Yates <rich...@yatesguitar.com> wrote:
>
>
>
>
>
>
>
>
>
>> On Tue, 23 Apr 2013 19:16:54 -0700 (PDT), Question Boy
>
>> <question....@hotmail.com> wrote:
>>> I have an simple MySQL/PHP app and it appears to be functional but the
>>> webmaster has informed me that it is throwing lots of errors. So he
>>> showed me the log file and I am trying to remedy the issues, but have
>>> a question.
>
>>> For instance, I have a block of code, such as:
>
>>> if ($iBookedBy=="Other") {
>>> echo '<option selected value="Other">Other</option>';
>>> } else {
>>> echo '<option value="Other">Other</option>';
>>> }
>
>>> which the log file reports as:
>
>>> PHP Notice: Undefined variable: iBookedBy
>
>>> Now I thought of trying:
>
>>> if (isset($iBookedBy)==TRUE && $iBookedBy=="Other") {
>>> echo '<option selected value="Other">Other</option>';
>>> } else {
>>> echo '<option value="Other">Other</option>';
>>> }
>
>>> but am not sure if the server will break because the variable isn't
>>> set or if it will still throw an error because of the second,
>>> original, part of the if statement? Is this a good way to handle the
>>> problem, or am I going about this the wrong way and there is a better
>>> method?
>
>>> Thank you for your help.
>
>>> QuestionBoy
>
>> 1. Yes, it will prevent the error notice.
>
>> 2. You do not need the ==TRUE. isset($iBookedBy) means the same
>> isset($iBookedBy)==TRUE.
>
>> 3. Your asking the question suggests that you are trying to write code
>> and run it directly on a production server rather than testing on a
>> local server. The webmaster will be happier, and you will be much more
>> productive, if you set up a local server like WAMP.
>
> Thank you for the reply.
>
> I was always under the impression that it was always beneficial to
> explicitly put ==TRUE to avoid any arbitrary interpretations. I won't
> waste my time anymore.
>
> My test server was not reporting any errors. I will look into which
> setting has to be changed.
>
> Thank you once again.
Even setting my test server to debug mode, I don't seem to get the
errors reported on the production server?
|
|
|
|
| Re: Undefined variable [message #181240 is a reply to message #181239] |
Wed, 24 April 2013 08:04 |
David Robley
Messages: 23
Registered: March 2013
Karma: 0
|
Junior Member |
|
|
Question Boy wrote:
> On Apr 23, 11:27 pm, Question Boy <question....@hotmail.com> wrote:
>> On Apr 23, 11:08 pm, Richard Yates <rich...@yatesguitar.com> wrote:
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>> On Tue, 23 Apr 2013 19:16:54 -0700 (PDT), Question Boy
>>
>>> <question....@hotmail.com> wrote:
>>>> I have an simple MySQL/PHP app and it appears to be functional but the
>>>> webmaster has informed me that it is throwing lots of errors. So he
>>>> showed me the log file and I am trying to remedy the issues, but have
>>>> a question.
>>
>>>> For instance, I have a block of code, such as:
>>
>>>> if ($iBookedBy=="Other") {
>>>> echo '<option selected value="Other">Other</option>';
>>>> } else {
>>>> echo '<option value="Other">Other</option>';
>>>> }
>>
>>>> which the log file reports as:
>>
>>>> PHP Notice: Undefined variable: iBookedBy
>>
>>>> Now I thought of trying:
>>
>>>> if (isset($iBookedBy)==TRUE && $iBookedBy=="Other") {
>>>> echo '<option selected value="Other">Other</option>';
>>>> } else {
>>>> echo '<option value="Other">Other</option>';
>>>> }
>>
>>>> but am not sure if the server will break because the variable isn't
>>>> set or if it will still throw an error because of the second,
>>>> original, part of the if statement? Is this a good way to handle the
>>>> problem, or am I going about this the wrong way and there is a better
>>>> method?
>>
>>>> Thank you for your help.
>>
>>>> QuestionBoy
>>
>>> 1. Yes, it will prevent the error notice.
>>
>>> 2. You do not need the ==TRUE. isset($iBookedBy) means the same
>>> isset($iBookedBy)==TRUE.
>>
>>> 3. Your asking the question suggests that you are trying to write code
>>> and run it directly on a production server rather than testing on a
>>> local server. The webmaster will be happier, and you will be much more
>>> productive, if you set up a local server like WAMP.
>>
>> Thank you for the reply.
>>
>> I was always under the impression that it was always beneficial to
>> explicitly put ==TRUE to avoid any arbitrary interpretations. I won't
>> waste my time anymore.
>>
>> My test server was not reporting any errors. I will look into which
>> setting has to be changed.
>>
>> Thank you once again.
>
> Even setting my test server to debug mode, I don't seem to get the
> errors reported on the production server?
Check the php.ini settings for error_reporting
--
Cheers
David Robley
"I think someone electrified the corridor," Tom said haltingly.
|
|
|
|
| Re: Undefined variable [message #181241 is a reply to message #181238] |
Wed, 24 April 2013 09:24 |
The Natural Philosoph
Messages: 993
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 24/04/13 04:27, Question Boy wrote:
> On Apr 23, 11:08 pm, Richard Yates <rich...@yatesguitar.com> wrote:
>> On Tue, 23 Apr 2013 19:16:54 -0700 (PDT), Question Boy
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> <question....@hotmail.com> wrote:
>>> I have an simple MySQL/PHP app and it appears to be functional but the
>>> webmaster has informed me that it is throwing lots of errors. So he
>>> showed me the log file and I am trying to remedy the issues, but have
>>> a question.
>>> For instance, I have a block of code, such as:
>>> if ($iBookedBy=="Other") {
>>> echo '<option selected value="Other">Other</option>';
>>> } else {
>>> echo '<option value="Other">Other</option>';
>>> }
>>> which the log file reports as:
>>> PHP Notice: Undefined variable: iBookedBy
>>> Now I thought of trying:
>>> if (isset($iBookedBy)==TRUE && $iBookedBy=="Other") {
>>> echo '<option selected value="Other">Other</option>';
>>> } else {
>>> echo '<option value="Other">Other</option>';
>>> }
>>> but am not sure if the server will break because the variable isn't
>>> set or if it will still throw an error because of the second,
>>> original, part of the if statement? Is this a good way to handle the
>>> problem, or am I going about this the wrong way and there is a better
>>> method?
>>> Thank you for your help.
>>> QuestionBoy
>> 1. Yes, it will prevent the error notice.
>>
>> 2. You do not need the ==TRUE. isset($iBookedBy) means the same
>> isset($iBookedBy)==TRUE.
>>
>> 3. Your asking the question suggests that you are trying to write code
>> and run it directly on a production server rather than testing on a
>> local server. The webmaster will be happier, and you will be much more
>> productive, if you set up a local server like WAMP.
>
> Thank you for the reply.
>
> I was always under the impression that it was always beneficial to
> explicitly put ==TRUE to avoid any arbitrary interpretations. I won't
> waste my time anymore.
if you are writing code for others of arbitrary moronicity to debug, its
no bad thing: However the shorthand of if(x) instead of if(x==TRUE) is
so widely used its unlikely anyone else will bat an eyelid.
>
> My test server was not reporting any errors. I will look into which
> setting has to be changed.
you may be suppressing warnings on it.
my server is full of such errors from the first app I wrote in PHP, but
they are dwarfed by errors ffrom apache of hackers trying to find
framework administration files that don't exist, things called
apple-touch-preconfigured blah blah.
> Thank you once again.
--
Ineptocracy
(in-ep-toc’-ra-cy) – a system of government where the least capable to lead are elected by the least capable of producing, and where the members of society least likely to sustain themselves or succeed, are rewarded with goods and services paid for by the confiscated wealth of a diminishing number of producers.
|
|
|
|
| Re: Undefined variable [message #181242 is a reply to message #181239] |
Wed, 24 April 2013 09:53 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 4/23/2013 11:49 PM, Question Boy wrote:
> On Apr 23, 11:27 pm, Question Boy <question....@hotmail.com> wrote:
>> On Apr 23, 11:08 pm, Richard Yates <rich...@yatesguitar.com> wrote:
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>> On Tue, 23 Apr 2013 19:16:54 -0700 (PDT), Question Boy
>>
>>> <question....@hotmail.com> wrote:
>>>> I have an simple MySQL/PHP app and it appears to be functional but the
>>>> webmaster has informed me that it is throwing lots of errors. So he
>>>> showed me the log file and I am trying to remedy the issues, but have
>>>> a question.
>>
>>>> For instance, I have a block of code, such as:
>>
>>>> if ($iBookedBy=="Other") {
>>>> echo '<option selected value="Other">Other</option>';
>>>> } else {
>>>> echo '<option value="Other">Other</option>';
>>>> }
>>
>>>> which the log file reports as:
>>
>>>> PHP Notice: Undefined variable: iBookedBy
>>
>>>> Now I thought of trying:
>>
>>>> if (isset($iBookedBy)==TRUE && $iBookedBy=="Other") {
>>>> echo '<option selected value="Other">Other</option>';
>>>> } else {
>>>> echo '<option value="Other">Other</option>';
>>>> }
>>
>>>> but am not sure if the server will break because the variable isn't
>>>> set or if it will still throw an error because of the second,
>>>> original, part of the if statement? Is this a good way to handle the
>>>> problem, or am I going about this the wrong way and there is a better
>>>> method?
>>
>>>> Thank you for your help.
>>
>>>> QuestionBoy
>>
>>> 1. Yes, it will prevent the error notice.
>>
>>> 2. You do not need the ==TRUE. isset($iBookedBy) means the same
>>> isset($iBookedBy)==TRUE.
>>
>>> 3. Your asking the question suggests that you are trying to write code
>>> and run it directly on a production server rather than testing on a
>>> local server. The webmaster will be happier, and you will be much more
>>> productive, if you set up a local server like WAMP.
>>
>> Thank you for the reply.
>>
>> I was always under the impression that it was always beneficial to
>> explicitly put ==TRUE to avoid any arbitrary interpretations. I won't
>> waste my time anymore.
>>
>> My test server was not reporting any errors. I will look into which
>> setting has to be changed.
>>
>> Thank you once again.
>
> Even setting my test server to debug mode, I don't seem to get the
> errors reported on the production server?
>
Ensure your php.ini file on your development system has the following:
error_reporting = E_ALL // or E_ALL | E_STRICT
display_errors = on
The default for error_reporting is E_ALL & ~E_NOTICE, which will not
catch such problems (actually I'm surprised the production server has
E_NOTICE on - most don't).
display_errors will show the errors when they occur so you don't have to
go digging in the log file (it should definitely be off in a production
system).
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: Undefined variable [message #181243 is a reply to message #181241] |
Wed, 24 April 2013 09:55 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 4/24/2013 5:24 AM, The Natural Philosopher wrote:
> On 24/04/13 04:27, Question Boy wrote:
>> On Apr 23, 11:08 pm, Richard Yates <rich...@yatesguitar.com> wrote:
>>> On Tue, 23 Apr 2013 19:16:54 -0700 (PDT), Question Boy
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> <question....@hotmail.com> wrote:
>>>> I have an simple MySQL/PHP app and it appears to be functional but the
>>>> webmaster has informed me that it is throwing lots of errors. So he
>>>> showed me the log file and I am trying to remedy the issues, but have
>>>> a question.
>>>> For instance, I have a block of code, such as:
>>>> if ($iBookedBy=="Other") {
>>>> echo '<option selected value="Other">Other</option>';
>>>> } else {
>>>> echo '<option value="Other">Other</option>';
>>>> }
>>>> which the log file reports as:
>>>> PHP Notice: Undefined variable: iBookedBy
>>>> Now I thought of trying:
>>>> if (isset($iBookedBy)==TRUE && $iBookedBy=="Other") {
>>>> echo '<option selected value="Other">Other</option>';
>>>> } else {
>>>> echo '<option value="Other">Other</option>';
>>>> }
>>>> but am not sure if the server will break because the variable isn't
>>>> set or if it will still throw an error because of the second,
>>>> original, part of the if statement? Is this a good way to handle the
>>>> problem, or am I going about this the wrong way and there is a better
>>>> method?
>>>> Thank you for your help.
>>>> QuestionBoy
>>> 1. Yes, it will prevent the error notice.
>>>
>>> 2. You do not need the ==TRUE. isset($iBookedBy) means the same
>>> isset($iBookedBy)==TRUE.
>>>
>>> 3. Your asking the question suggests that you are trying to write code
>>> and run it directly on a production server rather than testing on a
>>> local server. The webmaster will be happier, and you will be much more
>>> productive, if you set up a local server like WAMP.
>>
>> Thank you for the reply.
>>
>> I was always under the impression that it was always beneficial to
>> explicitly put ==TRUE to avoid any arbitrary interpretations. I won't
>> waste my time anymore.
> if you are writing code for others of arbitrary moronicity to debug, its
> no bad thing: However the shorthand of if(x) instead of if(x==TRUE) is
> so widely used its unlikely anyone else will bat an eyelid.
>
>>
>> My test server was not reporting any errors. I will look into which
>> setting has to be changed.
>
> you may be suppressing warnings on it.
>
> my server is full of such errors from the first app I wrote in PHP, but
> they are dwarfed by errors ffrom apache of hackers trying to find
> framework administration files that don't exist, things called
> apple-touch-preconfigured blah blah.
>> Thank you once again.
>
>
Good programmers care about such things. They indicate problems just
waiting to crop up. That's why PHP throws notices when they occur.
Crap programmers make excuses.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: Undefined variable [message #181244 is a reply to message #181235] |
Wed, 24 April 2013 10:20 |
Christoph Becker
Messages: 91
Registered: June 2012
Karma: 0
|
Member |
|
|
Question Boy wrote:
> For instance, I have a block of code, such as:
>
> if ($iBookedBy=="Other") {
> echo '<option selected value="Other">Other</option>';
> } else {
> echo '<option value="Other">Other</option>';
> }
>
> which the log file reports as:
>
> PHP Notice: Undefined variable: iBookedBy
You should investigate, why $iBookeyBy is undefined. It is always
preferable to initialize a variable explicitely before you use it. This
is particularly important for PHP due to the dangerous register_globals
option (which was fortunately removed since PHP 5.4). If this is
enabled (what should never be), the code may be vulnerable. Checking
for isset($iBookeyBy) won't help in this case.
--
Christoph M. Becker
|
|
|
|
| Re: Undefined variable [message #181245 is a reply to message #181244] |
Wed, 24 April 2013 13:51 |
Question Boy
Messages: 8
Registered: April 2011
Karma: 0
|
Junior Member |
|
|
On Apr 24, 6:20 am, Christoph Becker <cmbecke...@gmx.de> wrote:
> Question Boy wrote:
>> For instance, I have a block of code, such as:
>
>> if ($iBookedBy=="Other") {
>> echo '<option selected value="Other">Other</option>';
>> } else {
>> echo '<option value="Other">Other</option>';
>> }
>
>> which the log file reports as:
>
>> PHP Notice: Undefined variable: iBookedBy
>
> You should investigate, why $iBookeyBy is undefined. It is always
> preferable to initialize a variable explicitely before you use it. This
> is particularly important for PHP due to the dangerous register_globals
> option (which was fortunately removed since PHP 5.4). If this is
> enabled (what should never be), the code may be vulnerable. Checking
> for isset($iBookeyBy) won't help in this case.
>
> --
> Christoph M. Becker
Thank you all for all the information! I have a lot of work ahead of
me to clean thing up.
|
|
|
|
| Re: Undefined variable [message #181246 is a reply to message #181239] |
Wed, 24 April 2013 20:02 |
Chuck Anderson
Messages: 63
Registered: September 2010
Karma: 0
|
Member |
|
|
Question Boy wrote:
> On Apr 23, 11:27 pm, Question Boy <question....@hotmail.com> wrote:
>
>> On Apr 23, 11:08 pm, Richard Yates <rich...@yatesguitar.com> wrote:
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>> On Tue, 23 Apr 2013 19:16:54 -0700 (PDT), Question Boy
>>>
>>> <question....@hotmail.com> wrote:
>>>
>>>> I have an simple MySQL/PHP app and it appears to be functional but the
>>>> webmaster has informed me that it is throwing lots of errors. So he
>>>> showed me the log file and I am trying to remedy the issues, but have
>>>> a question.
>>>>
>>>> For instance, I have a block of code, such as:
>>>>
>>>> if ($iBookedBy=="Other") {
>>>> echo '<option selected value="Other">Other</option>';
>>>> } else {
>>>> echo '<option value="Other">Other</option>';
>>>> }
>>>>
>>>> which the log file reports as:
>>>>
>>>> PHP Notice: Undefined variable: iBookedBy
>>>>
>>>> Now I thought of trying:
>>>>
>>>> if (isset($iBookedBy)==TRUE && $iBookedBy=="Other") {
>>>> echo '<option selected value="Other">Other</option>';
>>>> } else {
>>>> echo '<option value="Other">Other</option>';
>>>> }
>>>>
>>>> but am not sure if the server will break because the variable isn't
>>>> set or if it will still throw an error because of the second,
>>>> original, part of the if statement? Is this a good way to handle the
>>>> problem, or am I going about this the wrong way and there is a better
>>>> method?
>>>>
>>>> Thank you for your help.
>>>>
>>>> QuestionBoy
>>>>
>>> 1. Yes, it will prevent the error notice.
>>>
>>> 2. You do not need the ==TRUE. isset($iBookedBy) means the same
>>> isset($iBookedBy)==TRUE.
>>>
>>> 3. Your asking the question suggests that you are trying to write code
>>> and run it directly on a production server rather than testing on a
>>> local server. The webmaster will be happier, and you will be much more
>>> productive, if you set up a local server like WAMP.
>>>
>> Thank you for the reply.
>>
>> I was always under the impression that it was always beneficial to
>> explicitly put ==TRUE to avoid any arbitrary interpretations. I won't
>> waste my time anymore.
>>
>> My test server was not reporting any errors. I will look into which
>> setting has to be changed.
>>
>> Thank you once again.
>>
>
> Even setting my test server to debug mode, I don't seem to get the
> errors reported on the production server?
>
My guess is that you are running Php < 5.3 on your development machine,
and the production server is running 5.3+. That is why your test system
does not produce the errors and the production machine does. When I
upgraded to Php 5.3 some of my older scripts threw lots of these errors.
I found that the best way to correct them was to create a section near
the top of the script where I set all variables needed by the script to
their default values (usually either '', or 0). Add a comment and you're
also creating useful documentation.
There is also a dirty "fix" (it is not really a fix) that will remove
them immediately on the production machine. If you can not access
php.ini (on a shared server) or do not want to make a global change to
php.ini (the cause of those Notices should be found and corrected) put
the following in a .htaccess file and place it in any affected, upper
level directory.
# error_reporting = E_ALL & ~E_NOTICE (all error levels except Notices)
php_value error_reporting 30711
This will disable reporting of Notice level errors.
Here are some other combinations that can be useful for a quick and
dirty fix to the production site after upgrading to Php 5.3.
# php error level
# error_reporting = E_ALL & ~E_DEPRECATED
# php_value error_reporting 22527
# error_reporting = E_ALL & ~E_NOTICE & ~E_DEPRECATED
# php_value error_reporting 22519
With the fire put out you can correct the cause of the error reports at
a more leisurely pace (after you upgrade to Php 5.3+ on your test system).
--
*****************************
Chuck Anderson • Boulder, CO
http://cycletourist.com
Turn Off, Tune Out, Drop In
*****************************
|
|
|
|
| Re: Undefined variable [message #181247 is a reply to message #181246] |
Thu, 25 April 2013 02:23 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 4/24/2013 4:02 PM, Chuck Anderson wrote:
> Question Boy wrote:
>> On Apr 23, 11:27 pm, Question Boy <question....@hotmail.com> wrote:
>>> On Apr 23, 11:08 pm, Richard Yates <rich...@yatesguitar.com> wrote:
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>> On Tue, 23 Apr 2013 19:16:54 -0700 (PDT), Question Boy
>>>> <question....@hotmail.com> wrote:
>>>> > I have an simple MySQL/PHP app and it appears to be functional but the
>>>> > webmaster has informed me that it is throwing lots of errors. So he
>>>> > showed me the log file and I am trying to remedy the issues, but have
>>>> > a question.
>>>> > For instance, I have a block of code, such as:
>>>> > if ($iBookedBy=="Other") {
>>>> > echo '<option selected value="Other">Other</option>';
>>>> > } else {
>>>> > echo '<option value="Other">Other</option>';
>>>> > }
>>>> > which the log file reports as:
>>>> > PHP Notice: Undefined variable: iBookedBy
>>>> > Now I thought of trying:
>>>> > if (isset($iBookedBy)==TRUE && $iBookedBy=="Other") {
>>>> > echo '<option selected value="Other">Other</option>';
>>>> > } else {
>>>> > echo '<option value="Other">Other</option>';
>>>> > }
>>>> > but am not sure if the server will break because the variable isn't
>>>> > set or if it will still throw an error because of the second,
>>>> > original, part of the if statement? Is this a good way to handle the
>>>> > problem, or am I going about this the wrong way and there is a better
>>>> > method?
>>>> > Thank you for your help.
>>>> > QuestionBoy
>>>> 1. Yes, it will prevent the error notice.
>>>> 2. You do not need the ==TRUE. isset($iBookedBy) means the same
>>>> isset($iBookedBy)==TRUE.
>>>> 3. Your asking the question suggests that you are trying to write code
>>>> and run it directly on a production server rather than testing on a
>>>> local server. The webmaster will be happier, and you will be much more
>>>> productive, if you set up a local server like WAMP.
>>> Thank you for the reply.
>>>
>>> I was always under the impression that it was always beneficial to
>>> explicitly put ==TRUE to avoid any arbitrary interpretations. I won't
>>> waste my time anymore.
>>>
>>> My test server was not reporting any errors. I will look into which
>>> setting has to be changed.
>>>
>>> Thank you once again.
>>
>> Even setting my test server to debug mode, I don't seem to get the
>> errors reported on the production server?
>
> My guess is that you are running Php < 5.3 on your development machine,
> and the production server is running 5.3+. That is why your test system
> does not produce the errors and the production machine does. When I
> upgraded to Php 5.3 some of my older scripts threw lots of these errors.
> I found that the best way to correct them was to create a section near
> the top of the script where I set all variables needed by the script to
> their default values (usually either '', or 0). Add a comment and you're
> also creating useful documentation.
>
Even PHP > 5.3 will give notices on these notices. I suspect you just
didn't have E_NOTICE enabled on your old scripts.
Setting variables to their default values is a good idea - but only if
their equivalent isn't defined in $_POST, $_SESSION, etc.
> There is also a dirty "fix" (it is not really a fix) that will remove
> them immediately on the production machine. If you can not access
> php.ini (on a shared server) or do not want to make a global change to
> php.ini (the cause of those Notices should be found and corrected) put
> the following in a .htaccess file and place it in any affected, upper
> level directory.
>
> # error_reporting = E_ALL & ~E_NOTICE (all error levels except Notices)
> php_value error_reporting 30711
>
> This will disable reporting of Notice level errors.
>
That does NOT fix the problems. It merely hides them - which is his
current problem.
> Here are some other combinations that can be useful for a quick and
> dirty fix to the production site after upgrading to Php 5.3.
>
> # php error level
> # error_reporting = E_ALL & ~E_DEPRECATED
> # php_value error_reporting 22527
>
> # error_reporting = E_ALL & ~E_NOTICE & ~E_DEPRECATED
> # php_value error_reporting 22519
>
> With the fire put out you can correct the cause of the error reports at
> a more leisurely pace (after you upgrade to Php 5.3+ on your test system).
>
Again, you are only hiding the problems, not fixing them!
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: Undefined variable [message #181248 is a reply to message #181247] |
Thu, 25 April 2013 02:24 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 4/24/2013 10:23 PM, Jerry Stuckle wrote:
> On 4/24/2013 4:02 PM, Chuck Anderson wrote:
>> Question Boy wrote:
>>> On Apr 23, 11:27 pm, Question Boy <question....@hotmail.com> wrote:
>>>> On Apr 23, 11:08 pm, Richard Yates <rich...@yatesguitar.com> wrote:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> > On Tue, 23 Apr 2013 19:16:54 -0700 (PDT), Question Boy
>>>> > <question....@hotmail.com> wrote:
>>>> >> I have an simple MySQL/PHP app and it appears to be functional but
>>>> >> the
>>>> >> webmaster has informed me that it is throwing lots of errors. So he
>>>> >> showed me the log file and I am trying to remedy the issues, but have
>>>> >> a question.
>>>> >> For instance, I have a block of code, such as:
>>>> >> if ($iBookedBy=="Other") {
>>>> >> echo '<option selected value="Other">Other</option>';
>>>> >> } else {
>>>> >> echo '<option value="Other">Other</option>';
>>>> >> }
>>>> >> which the log file reports as:
>>>> >> PHP Notice: Undefined variable: iBookedBy
>>>> >> Now I thought of trying:
>>>> >> if (isset($iBookedBy)==TRUE && $iBookedBy=="Other") {
>>>> >> echo '<option selected value="Other">Other</option>';
>>>> >> } else {
>>>> >> echo '<option value="Other">Other</option>';
>>>> >> }
>>>> >> but am not sure if the server will break because the variable isn't
>>>> >> set or if it will still throw an error because of the second,
>>>> >> original, part of the if statement? Is this a good way to handle the
>>>> >> problem, or am I going about this the wrong way and there is a better
>>>> >> method?
>>>> >> Thank you for your help.
>>>> >> QuestionBoy
>>>> > 1. Yes, it will prevent the error notice.
>>>> > 2. You do not need the ==TRUE. isset($iBookedBy) means the same
>>>> > isset($iBookedBy)==TRUE.
>>>> > 3. Your asking the question suggests that you are trying to write code
>>>> > and run it directly on a production server rather than testing on a
>>>> > local server. The webmaster will be happier, and you will be much more
>>>> > productive, if you set up a local server like WAMP.
>>>> Thank you for the reply.
>>>>
>>>> I was always under the impression that it was always beneficial to
>>>> explicitly put ==TRUE to avoid any arbitrary interpretations. I won't
>>>> waste my time anymore.
>>>>
>>>> My test server was not reporting any errors. I will look into which
>>>> setting has to be changed.
>>>>
>>>> Thank you once again.
>>>
>>> Even setting my test server to debug mode, I don't seem to get the
>>> errors reported on the production server?
>>
>> My guess is that you are running Php < 5.3 on your development machine,
>> and the production server is running 5.3+. That is why your test system
>> does not produce the errors and the production machine does. When I
>> upgraded to Php 5.3 some of my older scripts threw lots of these errors.
>> I found that the best way to correct them was to create a section near
>> the top of the script where I set all variables needed by the script to
>> their default values (usually either '', or 0). Add a comment and you're
>> also creating useful documentation.
>>
>
> Even PHP > 5.3 will give notices on these notices. I suspect you just
<
> didn't have E_NOTICE enabled on your old scripts.
>
> Setting variables to their default values is a good idea - but only if
> their equivalent isn't defined in $_POST, $_SESSION, etc.
>
>> There is also a dirty "fix" (it is not really a fix) that will remove
>> them immediately on the production machine. If you can not access
>> php.ini (on a shared server) or do not want to make a global change to
>> php.ini (the cause of those Notices should be found and corrected) put
>> the following in a .htaccess file and place it in any affected, upper
>> level directory.
>>
>> # error_reporting = E_ALL & ~E_NOTICE (all error levels except Notices)
>> php_value error_reporting 30711
>>
>> This will disable reporting of Notice level errors.
>>
>
> That does NOT fix the problems. It merely hides them - which is his
> current problem.
>
>> Here are some other combinations that can be useful for a quick and
>> dirty fix to the production site after upgrading to Php 5.3.
>>
>> # php error level
>> # error_reporting = E_ALL & ~E_DEPRECATED
>> # php_value error_reporting 22527
>>
>> # error_reporting = E_ALL & ~E_NOTICE & ~E_DEPRECATED
>> # php_value error_reporting 22519
>>
>> With the fire put out you can correct the cause of the error reports at
>> a more leisurely pace (after you upgrade to Php 5.3+ on your test
>> system).
>>
>
> Again, you are only hiding the problems, not fixing them!
>
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: Undefined variable [message #181249 is a reply to message #181247] |
Thu, 25 April 2013 07:03 |
Chuck Anderson
Messages: 63
Registered: September 2010
Karma: 0
|
Member |
|
|
Jerry Stuckle wrote:
> On 4/24/2013 4:02 PM, Chuck Anderson wrote:
>> Question Boy wrote:
>>> On Apr 23, 11:27 pm, Question Boy <question....@hotmail.com> wrote:
>>>> On Apr 23, 11:08 pm, Richard Yates <rich...@yatesguitar.com> wrote:
>>>>
>>>> > On Tue, 23 Apr 2013 19:16:54 -0700 (PDT), Question Boy
>>>> > <question....@hotmail.com> wrote:
>>>> >> I have an simple MySQL/PHP app and it appears to be functional
>>>> >> but the
>>>> >> webmaster has informed me that it is throwing lots of errors. So he
>>>> >> showed me the log file and I am trying to remedy the issues, but
>>>> >> have
>>>> >> a question.
>>>> >> For instance, I have a block of code, such as:
>>>> >> if ($iBookedBy=="Other") {
>>>> >> echo '<option selected value="Other">Other</option>';
>>>> >> } else {
>>>> >> echo '<option value="Other">Other</option>';
>>>> >> }
>>>> >> which the log file reports as:
>>>> >> PHP Notice: Undefined variable: iBookedBy
>>>> >> Now I thought of trying:
>>>> >> if (isset($iBookedBy)==TRUE && $iBookedBy=="Other") {
>>>> >> echo '<option selected value="Other">Other</option>';
>>>> >> } else {
>>>> >> echo '<option value="Other">Other</option>';
>>>> >> }
>>>> >> but am not sure if the server will break because the variable isn't
>>>> >> set or if it will still throw an error because of the second,
>>>> >> original, part of the if statement? Is this a good way to handle
>>>> >> the
>>>> >> problem, or am I going about this the wrong way and there is a
>>>> >> better
>>>> >> method?
>>>> >> Thank you for your help.
>>>> >> QuestionBoy
>>>> > 1. Yes, it will prevent the error notice.
>>>> > 2. You do not need the ==TRUE. isset($iBookedBy) means the same
>>>> > isset($iBookedBy)==TRUE.
>>>> > 3. Your asking the question suggests that you are trying to write
>>>> > code
>>>> > and run it directly on a production server rather than testing on a
>>>> > local server. The webmaster will be happier, and you will be much
>>>> > more
>>>> > productive, if you set up a local server like WAMP.
>>>> Thank you for the reply.
>>>>
>>>> I was always under the impression that it was always beneficial to
>>>> explicitly put ==TRUE to avoid any arbitrary interpretations. I won't
>>>> waste my time anymore.
>>>>
>>>> My test server was not reporting any errors. I will look into which
>>>> setting has to be changed.
>>>>
>>>> Thank you once again.
>>>
>>> Even setting my test server to debug mode, I don't seem to get the
>>> errors reported on the production server?
>>
>> My guess is that you are running Php < 5.3 on your development machine,
>> and the production server is running 5.3+. That is why your test system
>> does not produce the errors and the production machine does. When I
>> upgraded to Php 5.3 some of my older scripts threw lots of these errors.
>> I found that the best way to correct them was to create a section near
>> the top of the script where I set all variables needed by the script to
>> their default values (usually either '', or 0). Add a comment and you're
>> also creating useful documentation.
>>
>
> Even PHP > 5.3 will give notices on these notices. I suspect you just
> didn't have E_NOTICE enabled on your old scripts.
Okay. My bad. I didn't remember that I enabled notices and deprecation
errors when I upgraded to 5.3. I believe I wanted to see things that
were going to become errors eventually, and to correct any sloppy coding
I'd allowed myself to write when I was newer to Php and did not take it
seriously - when it was more forgiving. When I did so I was hit with a
slew of notices and I had to change a lotof "if ($_POST[submit'])"s to
"if (isset($_POST[submit_form']))" ... and other things. It was a good
exercise and it has improved the quality of my code a great deal.
>
> Setting variables to their default values is a good idea - but only if
> their equivalent isn't defined in $_POST, $_SESSION, etc.
That is not a problem for me. I do not initialize "REQUEST" variables
(POST, GET, COOKIE, SESSION) - and I never have register_globals
enabled, so setting a local variable to a default value never conflicts
with the super global REQUEST variables.
I set local variables to default values near the top of the script (like
a prologue) and then I go through my REQUEST ($_POST, $_GET) variables
and set a corresponding local variable to it's value which I then use in
my script. I almost never use REQUEST variables directly within my
script. This also forces me to remember to cleanse any user input.
>
>> There is also a dirty "fix" (it is not really a fix)
I think you read too fast. I stated right up front that this was not a fix.
I have several old Php scripts I wrote that I rely on for personal
utilities (calendar, accounting, log file analysis, ...). When I needed
to use one "right now" after turning on NOTICE errors, I resorted to
dropping an htaccess file into that directory that shut off the notices
so I could use my utility and then come back later and fix it at my
leisure (my scripts all still worked, even when using undefined variables).
That's the only reason I mentioned this convenient short cut. It can
put out the immediate fire. I believe I indicated more than once in my
description that you should come back, re-enable notice errors and
actually fix the problems.
>> that will remove
>> them immediately on the production machine. If you can not access
>> php.ini (on a shared server) or do not want to make a global change to
>> php.ini (the cause of those Notices should be found and corrected) put
There's one.
>> the following in a .htaccess file and place it in any affected, upper
>> level directory.
>>
>> # error_reporting = E_ALL & ~E_NOTICE (all error levels except Notices)
>> php_value error_reporting 30711
>>
>> This will disable reporting of Notice level errors.
>>
>
> That does NOT fix the problems. It merely hides them - which is his
> current problem.
It would also hide them on the production machine (where they should
have not been displayed anyway) and, as I said, "put out the fire" for
his client (even if unable to access php.ini on a shared host). He
could then fix the scripts at a more leisurely pace and his client would
be happy that he made the visible errors disappear almost instantly.
>> Here are some other combinations that can be useful for a quick and
>> dirty fix to the production site after upgrading to Php 5.3.
>>
>> # php error level
>> # error_reporting = E_ALL & ~E_DEPRECATED
>> # php_value error_reporting 22527
>>
>> # error_reporting = E_ALL & ~E_NOTICE & ~E_DEPRECATED
>> # php_value error_reporting 22519
>>
>> With the fire put out you can correct the cause of the error reports at
>> a more leisurely pace (after you upgrade to Php 5.3+ on your test
>> system).
>>
>
> Again, you are only hiding the problems, not fixing them!
I know. And again, I also said as much.
It's like using the faux spare tire most cars come with today. It does
not fix your problem, but it does let you get where you're going for now
- and you can deal with the real problem later.
--
*****************************
Chuck Anderson • Boulder, CO
http://cycletourist.com
Turn Off, Tune Out, Drop In
*****************************
|
|
|
|
|
|
| Re: Undefined variable [message #181251 is a reply to message #181245] |
Thu, 25 April 2013 08:10 |
M. Strobel
Messages: 386
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Am 24.04.2013 15:51, schrieb Question Boy:
> On Apr 24, 6:20 am, Christoph Becker <cmbecke...@gmx.de> wrote:
>> Question Boy wrote:
>>> For instance, I have a block of code, such as:
>>
>>> if ($iBookedBy=="Other") {
>>> echo '<option selected value="Other">Other</option>';
>>> } else {
>>> echo '<option value="Other">Other</option>';
>>> }
>>
>>> which the log file reports as:
>>
>>> PHP Notice: Undefined variable: iBookedBy
>>
>> You should investigate, why $iBookeyBy is undefined. It is always
>> preferable to initialize a variable explicitely before you use it. This
>> is particularly important for PHP due to the dangerous register_globals
>> option (which was fortunately removed since PHP 5.4). If this is
>> enabled (what should never be), the code may be vulnerable. Checking
>> for isset($iBookeyBy) won't help in this case.
>>
>> --
>> Christoph M. Becker
>
> Thank you all for all the information! I have a lot of work ahead of
> me to clean thing up.
>
I propose a new reading of "PHP Notice: undefined variable...", it goes:
Hey, you are using a variable that is not defined. I will put a null into it.
Because I will make it easy for you.
If you don't care I won't either.
Maybe you expected the variable to contain something,
and your app logic will be screwed up.
It will be _a_lot_of_ work to find the error, but that's your problem.
/Str.
|
|
|
|
|
|
| Re: Undefined variable [message #181253 is a reply to message #181249] |
Thu, 25 April 2013 09:22 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 4/25/2013 3:03 AM, Chuck Anderson wrote:
> Jerry Stuckle wrote:
>> On 4/24/2013 4:02 PM, Chuck Anderson wrote:
>>> Question Boy wrote:
>>>> On Apr 23, 11:27 pm, Question Boy <question....@hotmail.com> wrote:
>>>> > On Apr 23, 11:08 pm, Richard Yates <rich...@yatesguitar.com> wrote:
>>>> >
>>>> >> On Tue, 23 Apr 2013 19:16:54 -0700 (PDT), Question Boy
>>>> >> <question....@hotmail.com> wrote:
>>>> >>> I have an simple MySQL/PHP app and it appears to be functional
>>>> >>> but the
>>>> >>> webmaster has informed me that it is throwing lots of errors. So he
>>>> >>> showed me the log file and I am trying to remedy the issues, but
>>>> >>> have
>>>> >>> a question.
>>>> >>> For instance, I have a block of code, such as:
>>>> >>> if ($iBookedBy=="Other") {
>>>> >>> echo '<option selected value="Other">Other</option>';
>>>> >>> } else {
>>>> >>> echo '<option value="Other">Other</option>';
>>>> >>> }
>>>> >>> which the log file reports as:
>>>> >>> PHP Notice: Undefined variable: iBookedBy
>>>> >>> Now I thought of trying:
>>>> >>> if (isset($iBookedBy)==TRUE && $iBookedBy=="Other") {
>>>> >>> echo '<option selected value="Other">Other</option>';
>>>> >>> } else {
>>>> >>> echo '<option value="Other">Other</option>';
>>>> >>> }
>>>> >>> but am not sure if the server will break because the variable isn't
>>>> >>> set or if it will still throw an error because of the second,
>>>> >>> original, part of the if statement? Is this a good way to handle
>>>> >>> the
>>>> >>> problem, or am I going about this the wrong way and there is a
>>>> >>> better
>>>> >>> method?
>>>> >>> Thank you for your help.
>>>> >>> QuestionBoy
>>>> >> 1. Yes, it will prevent the error notice.
>>>> >> 2. You do not need the ==TRUE. isset($iBookedBy) means the same
>>>> >> isset($iBookedBy)==TRUE.
>>>> >> 3. Your asking the question suggests that you are trying to write
>>>> >> code
>>>> >> and run it directly on a production server rather than testing on a
>>>> >> local server. The webmaster will be happier, and you will be much
>>>> >> more
>>>> >> productive, if you set up a local server like WAMP.
>>>> > Thank you for the reply.
>>>> >
>>>> > I was always under the impression that it was always beneficial to
>>>> > explicitly put ==TRUE to avoid any arbitrary interpretations. I won't
>>>> > waste my time anymore.
>>>> >
>>>> > My test server was not reporting any errors. I will look into which
>>>> > setting has to be changed.
>>>> >
>>>> > Thank you once again.
>>>>
>>>> Even setting my test server to debug mode, I don't seem to get the
>>>> errors reported on the production server?
>>>
>>> My guess is that you are running Php < 5.3 on your development machine,
>>> and the production server is running 5.3+. That is why your test system
>>> does not produce the errors and the production machine does. When I
>>> upgraded to Php 5.3 some of my older scripts threw lots of these errors.
>>> I found that the best way to correct them was to create a section near
>>> the top of the script where I set all variables needed by the script to
>>> their default values (usually either '', or 0). Add a comment and you're
>>> also creating useful documentation.
>>>
>>
>> Even PHP > 5.3 will give notices on these notices. I suspect you just
>> didn't have E_NOTICE enabled on your old scripts.
>
> Okay. My bad. I didn't remember that I enabled notices and deprecation
> errors when I upgraded to 5.3. I believe I wanted to see things that
> were going to become errors eventually, and to correct any sloppy coding
> I'd allowed myself to write when I was newer to Php and did not take it
> seriously - when it was more forgiving. When I did so I was hit with a
> slew of notices and I had to change a lotof "if ($_POST[submit'])"s to
> "if (isset($_POST[submit_form']))" ... and other things. It was a good
> exercise and it has improved the quality of my code a great deal.
>
Yup, it's easy to do.
>>
>> Setting variables to their default values is a good idea - but only if
>> their equivalent isn't defined in $_POST, $_SESSION, etc.
>
> That is not a problem for me. I do not initialize "REQUEST" variables
> (POST, GET, COOKIE, SESSION) - and I never have register_globals
> enabled, so setting a local variable to a default value never conflicts
> with the super global REQUEST variables.
>
I don't use $_REQUEST at all. I like to know where my data are coming
from.
> I set local variables to default values near the top of the script (like
> a prologue) and then I go through my REQUEST ($_POST, $_GET) variables
> and set a corresponding local variable to it's value which I then use in
> my script. I almost never use REQUEST variables directly within my
> script. This also forces me to remember to cleanse any user input.
>
I learned this way in C (actually way back in Fortran II). But I found
C++'s way of defining/initializing a variable where it's first used to
make my code cleaner. So now in PHP I initialize it when I'm ready to
use it - not at the top of the code. It's a matter of style, but I've
found it helps with cleaner code - a year later you don't have to go
looking back to see what it's default value is, for instance.
>>
>>> There is also a dirty "fix" (it is not really a fix)
>
> I think you read too fast. I stated right up front that this was not a
> fix.
>
> I have several old Php scripts I wrote that I rely on for personal
> utilities (calendar, accounting, log file analysis, ...). When I needed
> to use one "right now" after turning on NOTICE errors, I resorted to
> dropping an htaccess file into that directory that shut off the notices
> so I could use my utility and then come back later and fix it at my
> leisure (my scripts all still worked, even when using undefined variables).
>
> That's the only reason I mentioned this convenient short cut. It can
> put out the immediate fire. I believe I indicated more than once in my
> description that you should come back, re-enable notice errors and
> actually fix the problems.
>
No, I didn't read too fast. But too many new programmers take such
suggestions as fixes. And, of course, it doesn't work on all systems
(only Apache with the correct configuration).
>>> that will remove
>>> them immediately on the production machine. If you can not access
>>> php.ini (on a shared server) or do not want to make a global change to
>>> php.ini (the cause of those Notices should be found and corrected) put
>
> There's one.
>
>>> the following in a .htaccess file and place it in any affected, upper
>>> level directory.
>>>
>>> # error_reporting = E_ALL & ~E_NOTICE (all error levels except Notices)
>>> php_value error_reporting 30711
>>>
>>> This will disable reporting of Notice level errors.
>>>
>>
>> That does NOT fix the problems. It merely hides them - which is his
>> current problem.
>
> It would also hide them on the production machine (where they should
> have not been displayed anyway) and, as I said, "put out the fire" for
> his client (even if unable to access php.ini on a shared host). He
> could then fix the scripts at a more leisurely pace and his client would
> be happy that he made the visible errors disappear almost instantly.
>
Unless it's a huge amount of bad code, it shouldn't take that long to
fix the problems.
>>> Here are some other combinations that can be useful for a quick and
>>> dirty fix to the production site after upgrading to Php 5.3.
>>>
>>> # php error level
>>> # error_reporting = E_ALL & ~E_DEPRECATED
>>> # php_value error_reporting 22527
>>>
>>> # error_reporting = E_ALL & ~E_NOTICE & ~E_DEPRECATED
>>> # php_value error_reporting 22519
>>>
>>> With the fire put out you can correct the cause of the error reports at
>>> a more leisurely pace (after you upgrade to Php 5.3+ on your test
>>> system).
>>>
>>
>> Again, you are only hiding the problems, not fixing them!
>
> I know. And again, I also said as much.
>
> It's like using the faux spare tire most cars come with today. It does
> not fix your problem, but it does let you get where you're going for now
> - and you can deal with the real problem later.
>
Yes, but as I said before - too many people read such updates as
"fixes", even though you said they aren't.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
|
|
| Re: Undefined variable [message #181255 is a reply to message #181254] |
Thu, 25 April 2013 12:12 |
The Natural Philosoph
Messages: 993
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 25/04/13 13:04, Thomas 'PointedEars' Lahn wrote:
> Tim Streater wrote:
>
>> Jerry Stuckle <jstucklex(at)attglobal(dot)net> wrote:
>>
>> <nothing at all>
> Not true; he posted 123 lines, of them two new lines (not counting the
> signature), of which one contained a single non-whitespace character, “<”.
>
> Honi soit qui mal y pense.
>
>
> PointedEars
Dear old Jerry. I suppose we should make him a mascot like an old deaf
dog that drools and farts a lot, but is a sentimental reminder of th
etimes when he used to bark and chase sticks, under the impressions that
this was really his purpose in life.
--
Ineptocracy
(in-ep-toc’-ra-cy) – a system of government where the least capable to lead are elected by the least capable of producing, and where the members of society least likely to sustain themselves or succeed, are rewarded with goods and services paid for by the confiscated wealth of a diminishing number of producers.
|
|
|
|
| Re: Undefined variable [message #181256 is a reply to message #181251] |
Thu, 25 April 2013 18:23 |
Denis McMahon
Messages: 634
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On Thu, 25 Apr 2013 10:10:24 +0200, M. Strobel wrote:
> I propose a new reading of "PHP Notice: undefined variable...", it goes:
>
> Hey, you are using a variable that is not defined. I will put a null
...........................................................^^^^
*might*
> into it.
> Because I will make it easy for you.
> If you don't care I won't either.
+ some lines:
I may put some random value there instead.
The double I use now might not be the string I use next.
Or the integer I used last.
> Maybe you expected the variable to contain something,
> and your app logic will be screwed up.
> It will be _a_lot_of_ work to find the error, but that's your
> problem.
(edited to be more complete and future proof)
--
Denis McMahon, denismfmcmahon(at)gmail(dot)com
|
|
|
|
| Re: Undefined variable [message #181257 is a reply to message #181256] |
Thu, 25 April 2013 20:05 |
M. Strobel
Messages: 386
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Am 25.04.2013 20:23, schrieb Denis McMahon:
> On Thu, 25 Apr 2013 10:10:24 +0200, M. Strobel wrote:
>
>> I propose a new reading of "PHP Notice: undefined variable...", it goes:
>>
>> Hey, you are using a variable that is not defined. I will put a null
> ..........................................................^^^^
>
> *might*
>
>> into it.
>> Because I will make it easy for you.
>> If you don't care I won't either.
>
> + some lines:
> I may put some random value there instead.
> The double I use now might not be the string I use next.
> Or the integer I used last.
>
>> Maybe you expected the variable to contain something,
>> and your app logic will be screwed up.
>> It will be _a_lot_of_ work to find the error, but that's your
>> problem.
>
> (edited to be more complete and future proof)
>
ah, a new community project :-)
I thought (and read) the variables were defined after being accessed, but they are
not. Very strange decisions of the PHP makers. Console log:
> echo $a, PHP_EOL;
PHP Notice: Undefined variable: a in /usr/local/bin/myreadline.php(42) : eval()'d
code on line 1
> var_dump($a);
PHP Notice: Undefined variable: a in /usr/local/bin/myreadline.php(42) : eval()'d
code on line 1
NULL
> if ($a==0.0) echo "yes\n";
PHP Notice: Undefined variable: a in /usr/local/bin/myreadline.php(42) : eval()'d
code on line 1
yes
> var_dump($a);
PHP Notice: Undefined variable: a in /usr/local/bin/myreadline.php(42) : eval()'d
code on line 1
NULL
/Str.
|
|
|
|
| Re: Undefined variable [message #181258 is a reply to message #181257] |
Fri, 26 April 2013 03:27 |
Denis McMahon
Messages: 634
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On Thu, 25 Apr 2013 22:05:46 +0200, M. Strobel wrote:
> Am 25.04.2013 20:23, schrieb Denis McMahon:
>> On Thu, 25 Apr 2013 10:10:24 +0200, M. Strobel wrote:
>>
>>> I propose a new reading of "PHP Notice: undefined variable...", it
>>> goes:
>>>
>>> Hey, you are using a variable that is not defined. I will put a
>>> null
>> ..........................................................^^^^
>>
>> *might*
>>
>>> into it.
>>> Because I will make it easy for you.
>>> If you don't care I won't either.
>>
>> + some lines:
>> I may put some random value there instead.
>> The double I use now might not be the string I use next.
>> Or the integer I used last.
>>
>>> Maybe you expected the variable to contain something,
>>> and your app logic will be screwed up.
>>> It will be _a_lot_of_ work to find the error, but that's your
>>> problem.
>>
>> (edited to be more complete and future proof)
>>
>>
> ah, a new community project :-)
>
> I thought (and read) the variables were defined after being accessed,
> but they are not. Very strange decisions of the PHP makers. Console log:
Yes, but that always might change in the next update ;)
I did wonder about:
"The array of doubles I'm using now might not be the class of kitten
hugging monkeys I'll use next week or the tuples of solar hydrogen I used
yesterday."
but that seemed perhaps a little too complex for some of the readers
here. :)
(although the kitten hugging monkeys may be more intelligent than some of
those readers too ... and come to that, so might the tuples of solar
hydrogen)
--
Denis McMahon, denismfmcmahon(at)gmail(dot)com
|
|
|
|
| Re: Undefined variable [message #181259 is a reply to message #181253] |
Fri, 26 April 2013 05:59 |
Chuck Anderson
Messages: 63
Registered: September 2010
Karma: 0
|
Member |
|
|
Jerry Stuckle wrote:
> On 4/25/2013 3:03 AM, Chuck Anderson wrote:
>> Jerry Stuckle wrote:
>>> On 4/24/2013 4:02 PM, Chuck Anderson wrote:
>>>> Question Boy wrote:
>>>> > On Apr 23, 11:27 pm, Question Boy <question....@hotmail.com> wrote:
>>>> >> On Apr 23, 11:08 pm, Richard Yates <rich...@yatesguitar.com> wrote:
>>>> >>
>>>> >>> On Tue, 23 Apr 2013 19:16:54 -0700 (PDT), Question Boy
>>>> >>> <question....@hotmail.com> wrote:
>>>> >>>> I have an simple MySQL/PHP app and it appears to be functional
>>>> >>>> but the
>>>> >>>> webmaster has informed me that it is throwing lots of errors.
>>>> >>>> So he
>>>> >>>> showed me the log file and I am trying to remedy the issues, but
>>>> >>>> have
>>>> >>>> a question.
>>>> >>>> For instance, I have a block of code, such as:
>>>> >>>> if ($iBookedBy=="Other") {
>>>> >>>> echo '<option selected value="Other">Other</option>';
>>>> >>>> } else {
>>>> >>>> echo '<option value="Other">Other</option>';
>>>> >>>> }
>>>> >>>> which the log file reports as:
>>>> >>>> PHP Notice: Undefined variable: iBookedBy
>>>> >>>> Now I thought of trying:
>>>> >>>> if (isset($iBookedBy)==TRUE && $iBookedBy=="Other") {
>>>> >>>> echo '<option selected value="Other">Other</option>';
>>>> >>>> } else {
>>>> >>>> echo '<option value="Other">Other</option>';
>>>> >>>> }
>>>>
>>>> My guess is that you are running Php < 5.3 on your development
>>>> machine,
>>>> and the production server is running 5.3+. That is why your test
>>>> system
>>>> does not produce the errors and the production machine does. When I
>>>> upgraded to Php 5.3 some of my older scripts threw lots of these
>>>> errors.
>>>> I found that the best way to correct them was to create a section near
>>>> the top of the script where I set all variables needed by the
>>>> script to
>>>> their default values (usually either '', or 0). Add a comment and
>>>> you're
>>>> also creating useful documentation.
>>>>
>>>
[ ... snip ... ]
>>> Setting variables to their default values is a good idea - but only if
>>> their equivalent isn't defined in $_POST, $_SESSION, etc.
>>
>> That is not a problem for me. I do not initialize "REQUEST" variables
>> (POST, GET, COOKIE, SESSION) - and I never have register_globals
>> enabled, so setting a local variable to a default value never conflicts
>> with the super global REQUEST variables.
>>
>
> I don't use $_REQUEST at all. I like to know where my data are coming
> from.
Just a point of clarification. I was using the word REQUEST as a
shortcut to indicate POST, GET, and COOKIE.
>> a prologue) and then I go through my REQUEST ($_POST, $_GET) variables
>> and set a corresponding local variable to it's value which I then use in
>> my script. I almost never use REQUEST variables directly within my
>> script. This also forces me to remember to cleanse any user input.
>>
> I set local variables to default values near the top of the script (like
>
> I learned this way in C (actually way back in Fortran II).
It was C prologues for me - and a proprietary language I used
extensively at Bell Labs.
[ .... snip ... ]
>>> Again, you are only hiding the problems, not fixing them!
>>
>> I know. And again, I also said as much.
>>
>
> Yes, but as I said before - too many people read such updates as
> "fixes", even though you said they aren't.
>
Poor Buggers ;-)
--
*****************************
Chuck Anderson • Boulder, CO
http://cycletourist.com
Turn Off, Tune Out, Drop In
*****************************
|
|
|
|
| Re: Undefined variable [message #181265 is a reply to message #181258] |
Fri, 26 April 2013 19:30 |
Thomas 'PointedEars'
Messages: 701
Registered: October 2010
Karma: 0
|
Senior Member |
|
|
Denis McMahon wrote:
> On Thu, 25 Apr 2013 22:05:46 +0200, M. Strobel wrote:
>> Am 25.04.2013 20:23, schrieb Denis McMahon:
>>> On Thu, 25 Apr 2013 10:10:24 +0200, M. Strobel wrote:
>>>> I propose a new reading of "PHP Notice: undefined variable...", it
>>>> goes:
>>>>
>>>> Hey, you are using a variable that is not defined. I will put a
>>>> null
>>> ..........................................................^^^^
>>>
>>> *might*
>>>
>>>> into it.
>>>> Because I will make it easy for you.
>>>> If you don't care I won't either.
>>>
>>> + some lines:
>>> I may put some random value there instead.
>>> The double I use now might not be the string I use next.
>>> Or the integer I used last.
>>> […]
> […]
>
> I did wonder about:
>
> "The array of doubles I'm using now might not be the class of kitten
> hugging monkeys I'll use next week or the tuples of solar hydrogen I used
> yesterday."
>
> but that seemed perhaps a little too complex for some of the readers
> here. :)
>
> (although the kitten hugging monkeys may be more intelligent than some of
> those readers too ... and come to that, so might the tuples of solar
> hydrogen)
However, the non-trolling reader will observe that the evaluation value of a
reference to an undefined variable actually *is* NULL, and that type
juggling as it occurs e.g. with the “==” operator or a type-converting test
(as opposed to with “===”) is *well-defined* (albeit perhaps unintuitive to
some), in PHP (and other dynamically typed programming languages).
It is simply false that a replacement value will be chosen randomly.
<http://www.php.net/manual/en/language.variables.basics.php>
<http://www.php.net/manual/en/language.types.type-juggling.php>
PointedEars
--
Sometimes, what you learn is wrong. If those wrong ideas are close to the
root of the knowledge tree you build on a particular subject, pruning the
bad branches can sometimes cause the whole tree to collapse.
-- Mike Duffy in cljs, <news:Xns9FB6521286DB8invalidcom(at)94(dot)75(dot)214(dot)39>
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]