Everything

php

FRC: html_erros and docref_root

php.internals

(Marcus Börger)

23 years ago

Hi all

I have changed the default ini value for html_errors to 0.

I think default ini settings should work for production boxes and noone should
have html_errors=On for those.

The second thing i changed is that errors are no longer pointing to any
documentation if either html_erros=0 or docref_root=''.

BUT now we (ok I) changed behavior of phpinfo(), too. However phpinfo()
shouldn't have been bound to html_errors in first place. Plase also see
http://bugs.php.net/bug.php?id=21007 and i am not the only one saying
that this should be solved in another way.

The reason i changed the behavior is that (stupid) people use features made
to make development life easier (namely html_errors=1 and docref_root=...)
on production boxes AND that we got the first bugreport that way. YES
someone filed in a bugreport by clicking on a doref'ed html error and clicking
like hell on php.net to finally find bugs.php.net....

Since the docref stuff is there to make developers life easier i thing removing
it would be the worst opportunity. If you however feel that option is good i
guess you are very egocentric and make developers life harder -> ask yourself
why php is popular (not everyone knows php as good as we).

A quick solution would be to make docref_root default to '' so there are also
no links to the manual.

But from my point of view the only thing to do is fix bug 21007.

However i do not see it as such a big problem to receive one bogus bugreport.

enough written on that (feel free to comment on every paragraph)
marcus

Alan Knowles

23 years ago

is it worth make the default use something like the PHPID=..... to point
to a short note saying - modify your php.ini configuration file to
enable docref links. - PLEASE DO NOT DO THIS ON PRODUCTION BOX's
otherwise we will come round with the lart...

Regards
Alan

Marcus Börger wrote:

> Hi all
>
> I have changed the default ini value for html_errors to 0.
>
> I think default ini settings should work for production boxes and
> noone should
> have html_errors=On for those.
>
> The second thing i changed is that errors are no longer pointing to any
> documentation if either html_erros=0 or docref_root=''.
>
> BUT now we (ok I) changed behavior of phpinfo(), too. However phpinfo()
> shouldn't have been bound to html_errors in first place. Plase also see
> http://bugs.php.net/bug.php?id=21007 and i am not the only one saying
> that this should be solved in another way.
>
> The reason i changed the behavior is that (stupid) people use features
> made
> to make development life easier (namely html_errors=1 and
> docref_root=...)
> on production boxes AND that we got the first bugreport that way. YES
> someone filed in a bugreport by clicking on a doref'ed html error and
> clicking
> like hell on php.net to finally find bugs.php.net....
>
> Since the docref stuff is there to make developers life easier i thing
> removing
> it would be the worst opportunity. If you however feel that option is
> good i
> guess you are very egocentric and make developers life harder -> ask
> yourself
> why php is popular (not everyone knows php as good as we).
>
> A quick solution would be to make docref_root default to '' so there
> are also
> no links to the manual.
>
> But from my point of view the only thing to do is fix bug 21007.
>
> However i do not see it as such a big problem to receive one bogus
> bugreport.
>
> enough written on that (feel free to comment on every paragraph)
> marcus
>
>

--
Can you help out?
Need Consulting Services or Know of a Job?
http://www.akbkhome.com

Jani Taskinen

23 years ago

On Sun, 16 Mar 2003, Marcus Börger wrote:

>But from my point of view the only thing to do is fix bug 21007.

So are you fixing it?

--Jani

(Marcus Börger)

23 years ago

At 16:30 18.03.2003, Jani Taskinen wrote:

>On Sun, 16 Mar 2003, Marcus Börger wrote:
>
> >But from my point of view the only thing to do is fix bug 21007.
>
>     So are you fixing it?
>

Yeah i'll add something to PG() and set it different from
CLI and blabla...ok? What's my timeframe for the 4.3.2
or do we skip it for that version and take a 'dirty' approach
there?

marcus

Jani Taskinen

23 years ago

On Tue, 18 Mar 2003, Marcus Börger wrote:

>At 16:30 18.03.2003, Jani Taskinen wrote:
>>On Sun, 16 Mar 2003, Marcus Börger wrote:
>>
>> >But from my point of view the only thing to do is fix bug 21007.
>>
>>     So are you fixing it?
>>
>
>Yeah i'll add something to PG() and set it different from
>CLI and blabla...ok? What's my timeframe for the 4.3.2

Sounds okay.

>or do we skip it for that version and take a 'dirty' approach
>there?

No, let's get it done properly. No hurry, I guess we'll
have RC2, there were some fixes I rather have tested
before we go live with 4.3.2..

Some 64bit issues, some bugs marked "Critical", etc..

--Jani

Dave Hill

23 years ago

>     Some 64bit issues, some bugs marked "Critical", etc..
>

On the 64bit issues... other than the ext/mbstring thing I am not
currently aware of any. I am still looking at the current test
failures though - I have 12 and so far 3 are explainable do to os
"features" and one is the mbstring problem. The last I have looked at
(but22510.phpt) drops core, but I got lost trying to figure it out,
and I am assuming others are still seeing this as the bug is not
closed yet.

On the ext/mbstring problem, I haven't heard anything from the listed
maintainer - does anyone have a feel for how important it is to fix
this one ?

Dave