Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:24 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 28138 invoked from network); 13 Mar 2003 17:39:24 -0000 Received: from unknown (HELO cs78146114.pp.htv.fi) (62.78.146.114) by pb1.pair.com with SMTP; 13 Mar 2003 17:39:24 -0000 Received: from localhost (jani@localhost) by cs78146114.pp.htv.fi (8.11.6/8.11.6) with ESMTP id h2DHdFx22463; Thu, 13 Mar 2003 19:39:15 +0200 X-Authentication-Warning: cs78146114.pp.htv.fi: jani owned process doing -bs Date: Thu, 13 Mar 2003 19:39:15 +0200 (EET) Sender: jani@cs78146114.pp.htv.fi Reply-To: Jani Taskinen To: Jon Parise cc: internals@lists.php.net In-Reply-To: <20030313164948.GA23178@csh.rit.edu> Message-ID: References: <20030313164948.GA23178@csh.rit.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: [PHP-DEV] Disabling error docref stuff by default From: sniper@iki.fi (Jani Taskinen) On Thu, 13 Mar 2003, Jon Parise wrote: >On Thu, Mar 13, 2003 at 01:10:10AM -0800, Rasmus Lerdorf wrote: > >> Could we disable these error links by default? As people are slowly >> migrating to 4.3, it is becoming very clear that all sorts of people are >> getting confused about these. Especially when a spam web site spews one >> of these and irate users trying to unspam themselves end up blaming >> webmaster@php.net for their troubles. Or just people following a link >> from one of these and emailing us about some error on some website out >> there that we have nothing to do with. > >I'm inclined to agree. What if it were made (bu default) on the >error_reporting level? E_ALL would use the docrefs but "lower" levels >would not (e.g. E_FATAL). > >Or a new INI option (docref_errors or docref_enable)? NO MORE INI OPTIONS!! There are so many options now that it's getting a hell to QA anything anymore..for example those session.bug_compat_42 and session.bug_compat_warn options. And what's wrong with 'display_errors=off' ??? No production website should have that set to 'ON' anyway. --Jani