Sherif Ramadan wrote:
On Tue, Sep 4, 2012 at 7:04 AM, Lester Caine <les...@lsces.co.uk> wrote:
Pierre Joye wrote:
How many of the major PHP user projects ARE currently strict compliant?
And
how many are still requiring E_STRICT switched off in PHP5.4?
This is a development and very useful. PHP does not enforce this mode.
And like any other errors, it only ends in your logs.
But this has been told to you a good dozen of times in the past, and
it is really getting ridiculous to have to explain that over and over.
And the point of YOUR comments?
With E_STRICT enabled - as is the default on PHP5.4 - programs simply crash
if they have not been 'converted'!
E_STRICT can't crash you program. It's just like an E_WARNING or
E_NTOICE level error. It's non-fatal. It does not inhibit the
execution of code.
??? OH YES IT DOES !!!
MANY times I get a a few lines of text on a white screen ...
Switch off E_STRICT and everything works fine ... as it was on PHP5.2
The QUESTION is a perfectly valid one ... especially when I've just hit yet
another current project that we have to make sure to disable E_STRICT when
they get transferred to a PHP5.4 machine! I have no doubt a lot more will
also be affected and so knowing the right answers is important. As perhaps
is understanding the reason some projects are not converting code?
What exactly is the question that you're posing to PHP Internals? An
audit of how much code doesn't follow strict standards? Probably a
lot. I've seen plenty of it in production myself and among them even
the most popular PHP frameworks. Having tested Joomla on PHP 5.4
before a switch to production I recall seeing an actual drop in
performance due to the sheer number of E_DEPRECATED and/or E_STRICT
errors that the code produced.
That is one which was white screening for me, and all I was trying to do was a
favour for some one. A quick hack of the config file and we were working again,
but certainly some modules in Joomla are not save when used with E_STRICT set!
However, none of that prevented the code from running (or "crashing"
as you say). All you have to do is change the error_reporting
directive if you chose to ignore those errors for the time being. You
simply don't have display_errors on in production anyway so the worst
possible outcome here is that you end up with an error log stuffed
with those errors. Nothing critical here.
This is not even a minor concern for most code basis that exhibit this
problem to a great degree because the majority of them aren't willing
to upgrade to 5.4 or have realized the problem by now and are fixing
their code.
The 'concern' is that ISP's are following the recommendations, and using the
default production setup, so E_STRICT is on - PLEASE LEAVE IT OFF should be the
standard!
While the preference on PHP5.4 may be to force people to comply, the reality
is that this is a switch which it's more likely needs switching off in
production simply because user land has no idea how to handle the problems
yet. And I'll keep banging on until what is distributed from the php.net
site actually works on a current default install ...
The userland problem is a trivial issue. All they have to do is turn
display_errors off in production as is recommended and is the default
anyway. There is nothing major here to hold you back other than
yourself.
--
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
