Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:72268 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 12843 invoked from network); 5 Feb 2014 12:34:22 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 5 Feb 2014 12:34:22 -0000 Authentication-Results: pb1.pair.com header.from=lester@lsces.co.uk; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=lester@lsces.co.uk; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 217.147.176.204 cause and error) X-PHP-List-Original-Sender: lester@lsces.co.uk X-Host-Fingerprint: 217.147.176.204 mail4.serversure.net Linux 2.6 Received: from [217.147.176.204] ([217.147.176.204:54703] helo=mail4.serversure.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id EE/C5-09402-DCF22F25 for ; Wed, 05 Feb 2014 07:34:22 -0500 Received: (qmail 12948 invoked by uid 89); 5 Feb 2014 12:34:17 -0000 Received: by simscan 1.3.1 ppid: 12941, pid: 12945, t: 0.0705s scanners: attach: 1.3.1 clamav: 0.96/m:52 Received: from unknown (HELO linux-dev4.lsces.org.uk) (lester@rainbowdigitalmedia.org.uk@81.138.11.136) by mail4.serversure.net with ESMTPA; 5 Feb 2014 12:34:17 -0000 Message-ID: <52F23078.4040206@lsces.co.uk> Date: Wed, 05 Feb 2014 12:37:12 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:26.0) Gecko/20100101 Firefox/26.0 SeaMonkey/2.23 MIME-Version: 1.0 To: PHP internals References: <52EF4BF8.60005@sugarcrm.com> <52F14C66.3030806@gmail.com> <52F15B62.1070006@gmail.com> <52F20C7C.3040803@lsces.co.uk> <52F2165E.6040104@lsces.co.uk> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Declare minimum PHP version required? From: lester@lsces.co.uk (Lester Caine) Pierre Joye wrote: > But the key point remains the same, no error should be displayed in > production (whatever hosting is used), this is well documented since > years. I have some hard time to understand why we keep having to > explain why. If the documentation needs improvements, then let try to > fix it. But adding yet another option to finally do something that we > try to prevent since years does not sound very appealing to me. I get it that all user gets is a white screen because that is what has been documented to returned. In the past we at least got something, but in these modern times IS a blank screen really an acceptable return? If it was just returning messy displays it would at least be something and we can then build on that to get things working properly. A number of my customers have come to me because they got no help from their ISP's and other ISP's switched back to older versions of PHP because too many sites simply broke. They don't have enough staff to fix PHP code and it's not their job? One of the best ways of getting the PHP5.2 sites updated is providing a default setup that minimizes the occurrence of a blank page. As Yasuo says 'even just a warning page'. With a blank page would a simple user even know that PHP has anything to do with why it's blank? -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk