Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.php > #9194

Re: Undefined variable

Show all headers | View raw

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
*****************************

Back to comp.lang.php | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Undefined variable Question Boy <question.boy@hotmail.com> - 2013-04-23 19:16 -0700
  Re: Undefined variable Question Boy <question.boy@hotmail.com> - 2013-04-23 20:06 -0700
  Re: Undefined variable Richard Yates <richard@yatesguitar.com> - 2013-04-23 20:08 -0700
    Re: Undefined variable Question Boy <question.boy@hotmail.com> - 2013-04-23 20:27 -0700
      Re: Undefined variable Question Boy <question.boy@hotmail.com> - 2013-04-23 20:49 -0700
        Re: Undefined variable David Robley <me@home.invalid> - 2013-04-24 17:34 +0930
        Re: Undefined variable Jerry Stuckle <jstucklex@attglobal.net> - 2013-04-24 05:53 -0400
        Re: Undefined variable Chuck Anderson <cycletourist@invalid.invalid> - 2013-04-24 14:02 -0600
          Re: Undefined variable Jerry Stuckle <jstucklex@attglobal.net> - 2013-04-24 22:23 -0400
            Re: Undefined variable Jerry Stuckle <jstucklex@attglobal.net> - 2013-04-24 22:24 -0400
              Re: Undefined variable Tim Streater <timstreater@greenbee.net> - 2013-04-25 08:36 +0100
                Re: Undefined variable Jerry Stuckle <jstucklex@attglobal.net> - 2013-04-25 05:13 -0400
                Re: Undefined variable Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-04-25 14:04 +0200
                Re: Undefined variable The Natural Philosopher <tnp@invalid.invalid> - 2013-04-25 13:12 +0100
            Re: Undefined variable Chuck Anderson <cycletourist@invalid.invalid> - 2013-04-25 01:03 -0600
              Re: Undefined variable Jerry Stuckle <jstucklex@attglobal.net> - 2013-04-25 05:22 -0400
                Re: Undefined variable Chuck Anderson <cycletourist@invalid.invalid> - 2013-04-25 23:59 -0600
      Re: Undefined variable The Natural Philosopher <tnp@invalid.invalid> - 2013-04-24 10:24 +0100
        Re: Undefined variable Jerry Stuckle <jstucklex@attglobal.net> - 2013-04-24 05:55 -0400
  Re: Undefined variable Christoph Becker <cmbecker69@gmx.de> - 2013-04-24 12:20 +0200
    Re: Undefined variable Question Boy <question.boy@hotmail.com> - 2013-04-24 06:51 -0700
      Re: Undefined variable "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2013-04-25 10:10 +0200
        Re: Undefined variable Denis McMahon <denismfmcmahon@gmail.com> - 2013-04-25 18:23 +0000
          Re: Undefined variable "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2013-04-25 22:05 +0200
            Re: Undefined variable Denis McMahon <denismfmcmahon@gmail.com> - 2013-04-26 03:27 +0000
              Re: Undefined variable Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-04-26 21:30 +0200

csiph-web