FUDforum
Fast Uncompromising Discussions. FUDforum will get your users talking.

Home » Imported messages » comp.lang.php » Undefined variable
Show: Today's Messages :: Polls :: Message Navigator
Return to the default flat view Create a new topic Submit Reply
Re: Undefined variable [message #181247 is a reply to message #181246] Thu, 25 April 2013 02:23 Go to previous messageGo to previous message
Jerry Stuckle is currently offline  Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma:
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
==================
[Message index]
 
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic: Rejecting Certain Non-ASCII Characters
Next Topic: determine a mysqli_result object
Goto Forum:
  

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ]

Current Time: Sun Nov 24 19:45:15 GMT 2024

Total time taken to generate the page: 0.04583 seconds