# FRC: html_erros and docref_root

- Thread: https://externals.io/message/65
- Original archive: https://news-web.php.net/php.internals/65
- Started by marcus.boerger@t-online.de on 2003-03-16T22:35:10+00:00
- Messages: 3
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #65 — marcus.boerger@t-online.de — 2003-03-16T22:35:10+00:00

URL: https://externals.io/message/65#65

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

---

## #88 — marcus.boerger@t-online.de — 2003-03-18T15:41:42+00:00

URL: https://externals.io/message/65#88 · In reply to: #65

At 16:30 18.03.2003, Jani Taskinen wrote:
>
>
> > […]
>
>     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

---

## #116 — David Hill — 2003-03-19T22:37:49+00:00

URL: https://externals.io/message/65#116

>     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