Re: [PHP-DEV] E_STRICT 'errors' - was Are exceptions allowed in php core?
Jan Ehrhardt wrote: Lester Caine in php.internals (Tue, 04 Sep 2012 22:30:34 +0100): Jan Ehrhardt wrote: Rasmus Lerdorf in php.internals (Tue, 04 Sep 2012 13:15:50 -0700): Just call error_reporting() at the beginning of your script. Which ain't possible in drupal (or hardly). You do not write any code. You just click together modules, written by others. Actually Jan - Rasmus is right here - we just have to fix these applications to bypass problems. It's just a matter of someone who knows how to advancing the information. But it would be nice if projects like Drupal would indicate what they plan to do to bring their code in line with PHP's current 'standards'? Drupal has four options for running under 5.4: 1. Turn E_STRICT off by default 2. Turn E_STRICT on by default 3. Do not mess around with system settings 4. Implement their own error_reporting setting, completely configurable (1) is not exactly bringing drupal in line with the current standards. It is a workaround. (2) and (3) will lead to loads of issues in those thousands of modules. (4) seems to me the only reasonable way out. Or if not, simply provide the configuration necessary for it to run without problems on each version of PHP? That would be (4) imo. However, there is no sign at all that the issue has ever attracted the full attention of one of the core developers. If you look at http://drupal.org/node/1267246 the current choice for drupal8 seems to be (3). Needs backport to drupal7 ... I will leave it with this, because it is way off topic in the internals list. ACTUALLY Jan - This is exactly the sort of confusion that I'm finding on other projects! Configuring their own error_reporting setting in the config is exactly what a lot of projects do. It's ACTUALLY what caused my initial problems because I did not pick up early on that the setting was being overriden in one of the libraries I was loading! I wasn't getting errors because e_strict was being deliberately disabled. But my point here is that it is the projects attitude to e_strict that is important. http://drupal.org/node/348448 flags that for Drupal 8 everything should be clean, but that it's not been enforced on Drupal 7. However a very quick scan of their documentation does not find any specific reference to that in their coding standards. Joomla seems to be in the same state - everything from version 1.6 should be compliant, but that was not what I was finding. I still have to recreate my own crash problem with that - my current 5.4 setup IS just creating reams of error reports and clobbering performance. The client has let me switch e_strict on, but obviously I have something different on the production machine to the development setup. You indicated that you switched back to PHP5.3 and personally I think many people are not even moving from PHP5.2 because they have working setups and don't want to break things. Yes we can hide the problems by the right setting in php.ini, or in the project configuration, but what we need to be supporting is the move to make legacy code complaint, or provide an workable upgrade path. But when core php material such as PEAR has not addressed the problem how can we expect projects that are reliant on it to comply? OK it's not internals problem - but it is only the people who fully understand what is going on internally that can review what is going on in userland, correct misconceptions and ensure that the correct practices are being followed? -- 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
Re: [PHP-DEV] E_STRICT 'errors' - was Are exceptions allowed in php core?
2012.09.04. 22:25, Jan Ehrhardt php...@ehrhardt.nl ezt írta: Rasmus Lerdorf in php.internals (Tue, 04 Sep 2012 13:15:50 -0700): Just call error_reporting() at the beginning of your script. Which ain't possible in drupal (or hardly). You do not write any code. You just click together modules, written by others. Jan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Oh, I thought only developers are subcribed to this list. To be serious: nope, it is perfectly valid to write your own modul to extend or change the functionality of drupal, and it does provide a pretty huge amount of infrastructure to do that (this is what every module use).
Re: [PHP-DEV] E_STRICT 'errors' - was Are exceptions allowed in php core?
2012.09.04. 23:31, Lester Caine les...@lsces.co.uk ezt írta: Jan Ehrhardt wrote: Rasmus Lerdorf in php.internals (Tue, 04 Sep 2012 13:15:50 -0700): Just call error_reporting() at the beginning of your script. Which ain't possible in drupal (or hardly). You do not write any code. You just click together modules, written by others. Actually Jan - Rasmus is right here - we just have to fix these applications to bypass problems. It's just a mater of someone who knows how to advancing the information. But it would be nice if projects like Drupal would indicate what they plan to do to bring their code in line with PHP's current 'standards'? Or if not, simply provide the configuration necessary for it to run without problems on each version of PHP? I have no problem with it being up to the projects to have to bend to the changes in PHP, my problem is that some of these bends are not totally thought out up front and are resulting in a lot of unnecessary work simply to stand still. generators are a case in point ... why did nobody who understands the fine detail spot the problem of hidden exceptions? Is it now a done deal that we have to live with these new ones now, or will an error based provision be made? It may take some time for me to go through ALL the white screen crashes I've been creating to cross check their actual cause, but without competent hand holding correcting mistakes like this, things are going to get missed. That IS all I have been asking for and the internals list is the only place where these questions get competent support. Although even here navigating the side issues can be interesting? Could you stop changing subjects please? For this issue, fixing the issue for drupal would be easy, but usually for a project with that size needs some time to migrate to a new version, and AFAIR drupal versions are not guaranteed to be supported for php versions which weren't supported when the drupal version was released(I remember similar issues when php 5.3 was released.). Maybe this will change, as we plan to pump out new versions more frequently than them. Generators are a different topic. Yield is a language construct but it is involving an oop component to so it's job. Some people from the core should nevet throw exceptions group didn't noticed this and those who did was fine with a generator class method throwing an exception. As Stas mentioned it would be nice having more voters participating/reviewing changes.
Re: [PHP-DEV] E_STRICT 'errors' - was Are exceptions allowed in php core?
Ferenc Kovacs wrote: Rasmus Lerdorf in php.internals (Tue, 04 Sep 2012 13:15:50 -0700): Just call error_reporting() at the beginning of your script. Which ain't possible in drupal (or hardly). You do not write any code. You just click together modules, written by others. Oh, I thought only developers are subcribed to this list. To be serious: nope, it is perfectly valid to write your own modul to extend or change the functionality of drupal, and it does provide a pretty huge amount of infrastructure to do that (this is what every module use). From the development point of view, drupal like zend was not a method of working I could get on with. I did have a go. Hacking the configuration to get around this particular problem is a doddle ... just not something that the majority of the drupal users would be able to tackle though? In reality a large proportion of the on-line use of PHP is probably by users of secondary layers such as Joomla and Drupal and while they do seem to be heading in the right direction, there does seem to be a level of confusion at their end on just how to handle the differences since 5.2 ? -- 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
Re: [PHP-DEV] E_STRICT 'errors' - was Are exceptions allowed in php core?
Hi! forgot to do reply all :) On Sep 4, 2012 10:25 PM, Jan Ehrhardt php...@ehrhardt.nl wrote: Rasmus Lerdorf in php.internals (Tue, 04 Sep 2012 13:15:50 -0700): Just call error_reporting() at the beginning of your script. Which ain't possible in drupal (or hardly). You do not write any code. You just click together modules, written by others. .htaccess (or pecl's htscanner for fcgi and 5.2), .user.ini (5.3+) will both let you do that easily. And patching bootstrap.inc is still acceptable. While it is not necessary if you don't mind too much about the noises in your error logs :) Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] E_STRICT 'errors' - was Are exceptions allowed in php core?
OK, apparently we will continue the discussion her. Pierre Joye in php.internals (Wed, 5 Sep 2012 13:15:43 +0200): On Sep 4, 2012 10:25 PM, Jan Ehrhardt php...@ehrhardt.nl wrote: Rasmus Lerdorf in php.internals (Tue, 04 Sep 2012 13:15:50 -0700): Just call error_reporting() at the beginning of your script. Which ain't possible in drupal (or hardly). You do not write any code. You just click together modules, written by others. .htaccess (or pecl's htscanner for fcgi and 5.2), .user.ini (5.3+) will both let you do that easily. No, it will not, because bootstrap.inc overrides the php.ini settings as well as the .htaccess settings. And patching bootstrap.inc is still acceptable. You do not want to patch drupal's core yourself. Too much chance your patch gets lost at every minor update. And besides that you'll have to revert your own patches if you run into a problem and want to discuss it on drupal.org. While it is not necessary if you don't mind too much about the noises in your error logs :) On a development server you want to see the warnings on screen, without all those E_STRICT warnings. And the noise will degrade the already low performance of a drupal7 system. Quote from http://drupal.org/node/1267246 This incurs a significant performance overhead for error handling whenever a notice occurs, as well as a lot of useless noise in Drupal's watchdog log (and even on screen if error logging to screen has not been disabled), and given that these are mostly coding style issues and not indicative of any real problem. Jan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] E_STRICT 'errors' - was Are exceptions allowed in php core?
Gustavo Lopes wrote: Second, E_STRICT exists to encourage good OOP practices. There is a lot of code that generates E_STRICT that does what it was intended to do (ask Lester). By definition, code that's not supposed to generate E_STRICT messages but does is buggy, but the fact that some code raises an E_STRICT does not signal, by itself, a bug. And in hindsight I'd say this was one of the worst decisions made in the past !!! Simply switching something off just to make code work again is just wrong how ever you look at it. This 'strict' stuff should have been handled with a bit more intelligence such as providing a report as to non-compliant code which picks up all the 'style differences' rather than having to work through layer after layer of errors. My converted code is messy and does now need a 'style tidy' clean-up. And I'm still not happy that what I AM doing the right things anyway! 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? -- 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
Re: [PHP-DEV] E_STRICT 'errors' - was Are exceptions allowed in php core?
hi, On Tue, Sep 4, 2012 at 11:32 AM, Lester Caine les...@lsces.co.uk 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. -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] E_STRICT 'errors' - was Are exceptions allowed in php core?
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'! 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? 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 ... -- 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
Re: [PHP-DEV] E_STRICT 'errors' - was Are exceptions allowed in php core?
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. 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. 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. 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] E_STRICT 'errors' - was Are exceptions allowed in php core?
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
Re: [PHP-DEV] E_STRICT 'errors' - was Are exceptions allowed in php core?
hi Lester, On Tue, Sep 4, 2012 at 2:51 PM, Lester Caine les...@lsces.co.uk wrote: ??? 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 If you have any doubts about how to configure your development or production servers, how to use logs or how to effectively debug php applications, please ask questions on php-general or php-setup mailing lists. Thanks for your understanding, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] E_STRICT 'errors' - was Are exceptions allowed in php core?
Pierre Joye wrote: On Tue, Sep 4, 2012 at 2:51 PM, Lester Caineles...@lsces.co.uk wrote: ??? 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 If you have any doubts about how to configure your development or production servers, how to use logs or how to effectively debug php applications, please ask questions on php-general or php-setup mailing lists. Thanks for your understanding, Butt out Pierre ... I keep being told that there is nothing wrong with E_STRICT, and again someone has said that it does NOT cause crashes. I beg to differ here - IT DOES! Now if you are saying that I need to document these crashes as they SHOULD not be happening then I'll roll things back and start doing that, but *I* thought that these crashes were simply a known effect of using E_STRICT? And so I followed the directions, and switched E_STRICT off. On production machines of PHP5.3 with E_STRICT enabled and on PHP5.4 one gets white screen crashes using older code ... as far as I was concerned that was a known fact. Switch it off and everything runs fine! -- 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
Re: [PHP-DEV] E_STRICT 'errors' - was Are exceptions allowed in php core?
Am Dienstag, 4. September 2012 um 15:09 schrieb Lester Caine: I keep being told that there is nothing wrong with E_STRICT, and again someone has said that it does NOT cause crashes. I beg to differ here - IT DOES! Now if you are saying that I need to document these crashes as they SHOULD not be happening then I'll roll things back and start doing that, but *I* thought that these crashes were simply a known effect of using E_STRICT? And so I followed the directions, and switched E_STRICT off. On production machines of PHP5.3 with E_STRICT enabled and on PHP5.4 one gets white screen crashes using older code ... as far as I was concerned that was a known fact. Switch it off and everything runs fine! Hi Lester, did you actually check the error messages or did you stop with the white screen? If it is the later one, please try to reproduce such issues, so that one can investigate it further. Because the current situation is: - you say: it crashes - somebody else says: it doesn't And I don't think that this will lead anywhere... Cheers Jannik
Re: [PHP-DEV] E_STRICT 'errors' - was Are exceptions allowed in php core?
On 4 September 2012 15:09, Lester Caine les...@lsces.co.uk wrote: Pierre Joye wrote: On Tue, Sep 4, 2012 at 2:51 PM, Lester Caineles...@lsces.co.uk wrote: ??? 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 If you have any doubts about how to configure your development or production servers, how to use logs or how to effectively debug php applications, please ask questions on php-general or php-setup mailing lists. Thanks for your understanding, Butt out Pierre ... I keep being told that there is nothing wrong with E_STRICT, and again someone has said that it does NOT cause crashes. I beg to differ here - IT DOES! Now if you are saying that I need to document these crashes as they SHOULD not be happening then I'll roll things back and start doing that, but *I* thought that these crashes were simply a known effect of using E_STRICT? And so I followed the directions, and switched E_STRICT off. On production machines of PHP5.3 with E_STRICT enabled and on PHP5.4 one gets white screen crashes using older code ... as far as I was concerned that was a known fact. Switch it off and everything runs fine! From php.ini: ; display_errors ; Default Value: On ; Development Value: On ; Production Value: Off In a production environment with display_errors off, E_STRICT doesn't crash anything. Actually, even with it on, it doesn't crash anything - shitty code does, by creating notices and then using header() calls afterwards to create redirects. Solution: fix your server. Fix your code. It worked for the rest of us. Regards Peter -- hype WWW: plphp.dk / plind.dk CV: careers.stackoverflow.com/peterlind LinkedIn: plind Twitter: kafe15 /hype -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] E_STRICT 'errors' - was Are exceptions allowed in php core?
On Tue, Sep 4, 2012 at 3:09 PM, Lester Caine les...@lsces.co.uk wrote:
Pierre Joye wrote:
On Tue, Sep 4, 2012 at 2:51 PM, Lester Caineles...@lsces.co.uk wrote:
??? 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
If you have any doubts about how to configure your development or
production servers, how to use logs or how to effectively debug php
applications, please ask questions on php-general or php-setup mailing
lists.
Thanks for your understanding,
Butt out Pierre ...
I keep being told that there is nothing wrong with E_STRICT, and again
someone has said that it does NOT cause crashes. I beg to differ here - IT
DOES!
never heard of that one before.
for example, running
?php
for($i=0;$i100;$i++){
$foo=foo_.$i;
${$foo}-bar = 123;
}
echo done;
gives me 100 E_STRICT, but still executes just fine and prints done at
the end.
the only explanation that I can think of is that you have a custom error
handler somewhere in your code, which somehow does something unexpected
(exits the script execution or does something like an infinite recursion
which segfaults/OOMs your application.
if you still think that it isn't the case, then please open an issue on
bugs.php.net with a reproduce script, as this would be clearly a bug.
Now if you are saying that I need to document these crashes as they SHOULD
not be happening then I'll roll things back and start doing that,
I would be generally surprised if you are serious about not knowing about
that triggering an E_STRICT shouldn't blow up your php.
but *I* thought that these crashes were simply a known effect of using
E_STRICT?
nope.
E_STRICT is currently the least serious/grave notice that the we have in
php(see the initial documentation at
http://php.net/manual/en/migrating5.errorrep.php), and until 5.4, it wasn't
part of E_ALL at all (see http://www.php.net/manual/en/migration54.other.php
).
which made some people bashing the project, that we call something E_ALL
which doesn't include everything.
so it was changed with 5.4, so
And so I followed the directions, and switched E_STRICT off. On production
machines of PHP5.3 with E_STRICT enabled and on PHP5.4 one gets white
screen crashes using older code ... as far as I was concerned that was a
known fact. Switch it off and everything runs fine!
would be nice if you could come up with a small snippet/stand alone script
to reproduce the issue and attach it to a bugreport.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Re: [PHP-DEV] E_STRICT 'errors' - was Are exceptions allowed in php core?
Peter Lind wrote: From php.ini: ; display_errors ; Default Value: On ; Development Value: On ; Production Value: Off In a production environment with display_errors off, E_STRICT doesn't crash anything. Actually, even with it on, it doesn't crash anything - shitty code does, by creating notices and then using header() calls afterwards to create redirects. Solution: fix your server. Fix your code. It worked for the rest of us. Using third party code - joomla - only difference between working and not working is switching E_STRICT on. With display_errors=off one gets a white screen. I was not surprised as I've had this all the way through with code from many sources. Yes a lot of the time you just get the error messages, but a white screen crash has been the norm most of the time so leaving display_errors=on helps while fault finding on the development systems. Most of the production strict fixes have now been committed on my own code, but I think I've still got an older 5.2 machine that still has the earlier code. I THINK one of the crashes comes when using $this in a static function. Certainly a lot of the recoding has been splitting a lot of these out to two separate functions but I've been seeing white screens for the past year as I work through third part code and to be honest since ALL I was changing as E_STRICT I had not looked much closer :( Other than e_strict and fatal as the last message visible. -- 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
Re: [PHP-DEV] E_STRICT 'errors' - was Are exceptions allowed in php core?
Using third party code - joomla - only difference between working and not working is switching E_STRICT on. With display_errors=off one gets a white screen. I was not surprised as I've had this all the way through with code from many sources. Yes a lot of the time you just get the error messages, but a white screen crash has been the norm most of the time so leaving display_errors=on helps while fault finding on the development systems. usually most people set display_errors=off but log_errors = on and just check the logfiles for errors. there is no point bothering your users with messages they won't understand or could be able to do anything about, plus it is usually a security vulnerability (Information Leakage). -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] E_STRICT 'errors' - was Are exceptions allowed in php core?
On Tue, Sep 4, 2012 at 9:43 AM, Ferenc Kovacs tyr...@gmail.com wrote:
never heard of that one before.
for example, running
?php
for($i=0;$i100;$i++){
$foo=foo_.$i;
${$foo}-bar = 123;
}
echo done;
gives me 100 E_STRICT, but still executes just fine and prints done at
the end.
the only explanation that I can think of is that you have a custom error
handler somewhere in your code, which somehow does something unexpected
(exits the script execution or does something like an infinite recursion
which segfaults/OOMs your application.
if you still think that it isn't the case, then please open an issue on
bugs.php.net with a reproduce script, as this would be clearly a bug.
I think Ferenc is correct in that this sounds like there's a custom
error handler somewhere. If the custom error handler collects error
info and then throws an exception (as has been detailed in various
blog posts as one manner of unifying the errors), this would cause the
trouble you're seeing.
Adam
--
Nephtali: A simple, flexible, fast, and security-focused PHP framework
http://nephtaliproject.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] E_STRICT 'errors' - was Are exceptions allowed in php core?
Ferenc Kovacs wrote: Using third party code - joomla - only difference between working and not working is switching E_STRICT on. With display_errors=off one gets a white screen. I was not surprised as I've had this all the way through with code from many sources. Yes a lot of the time you just get the error messages, but a white screen crash has been the norm most of the time so leaving display_errors=on helps while fault finding on the development systems. usually most people set display_errors=off but log_errors = on and just check the logfiles for errors. there is no point bothering your users with messages they won't understand or could be able to do anything about, plus it is usually a security vulnerability (Information Leakage). I know all about that side of things ... now I just need to recreate what has been giving me white screens ... having spent a year getting rid of them. GOT IT ... Or at least a white screen, but of cause now that some things have been pointed out then it's obvious what is going on! 12 months on I can see things differently! It is a fatal 'PHP Fatal error: Cannot make static method ... non static' at least on this white screen. The base library has some 'static' references but the descendent classes don't. Having updated some core libraries, the rest of the code is out of sync. But I've managed to pick up a back version that is full of 'deprecated' errors as well. So I need to scroll forward a bit so that I only have E_STRICT differences. I'm fairly sure now that it's the missing 'static' references in PEAR that start some of the confusion on this. I needed a clean strict version of PEAR as the base classes for some areas. And then make sure I don't access that with other websites that have yet to be 'upgraded'. Joomla may be failing over if it's picking up the wrong central libraries? Not having using it before I'll need to check what is picking up centrally. And the error log growing at 40 time the size of the access log is not encouraging from a maintenance viewpoint :( Hiding errors is all very well, but the error log still needs to be usable in production. -- 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
Re: [PHP-DEV] E_STRICT 'errors' - was Are exceptions allowed in php core?
On 09/04/2012 09:36 AM, Adam Richardson wrote: I think Ferenc is correct in that this sounds like there's a custom error handler somewhere. If the custom error handler collects error info and then throws an exception (as has been detailed in various blog posts as one manner of unifying the errors), this would cause the trouble you're seeing. Only on a new E_STRICT. Even with E_STRICT off by default, custom error handlers are still called, and I think Lester said that turning E_STRICT off made it work. So if this is the cause, then it has nothing to do with E_STRICT being in E_ALL or not, nor whether display_errors is on or off. It would have to do with the custom error handler blowing up on one specific E_STRICT, which I find rather unlikely. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] E_STRICT 'errors' - was Are exceptions allowed in php core?
On Tue, Sep 4, 2012 at 12:57 PM, Rasmus Lerdorf ras...@lerdorf.com wrote: Only on a new E_STRICT. Even with E_STRICT off by default, custom error handlers are still called, and I think Lester said that turning E_STRICT off made it work. So if this is the cause, then it has nothing to do with E_STRICT being in E_ALL or not, nor whether display_errors is on or off. It would have to do with the custom error handler blowing up on one specific E_STRICT, which I find rather unlikely. -Rasmus Whoops, you're right! I forgot that the custom error handler is called regardless of error reporting. Adam -- Nephtali: A simple, flexible, fast, and security-focused PHP framework http://nephtaliproject.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] E_STRICT 'errors' - was Are exceptions allowed in php core?
2012.09.04. 18:58, Rasmus Lerdorf ras...@lerdorf.com ezt írta: On 09/04/2012 09:36 AM, Adam Richardson wrote: I think Ferenc is correct in that this sounds like there's a custom error handler somewhere. If the custom error handler collects error info and then throws an exception (as has been detailed in various blog posts as one manner of unifying the errors), this would cause the trouble you're seeing. Only on a new E_STRICT. Even with E_STRICT off by default, custom error handlers are still called, and I think Lester said that turning E_STRICT off made it work. So if this is the cause, then it has nothing to do with E_STRICT being in E_ALL or not, nor whether display_errors is on or off. It would have to do with the custom error handler blowing up on one specific E_STRICT, which I find rather unlikely. Don't forget that many error handlers check the error level against the currently set error_reporting (so that they won't be executed on supressed errors and such). AFAIR we even promote that implementation in our error handler example in our docs. That would mean that the error handler main logic is only executed if E_STRICT is in the error_reporting.
Re: [PHP-DEV] E_STRICT 'errors' - was Are exceptions allowed in php core?
On Tue, Sep 4, 2012 at 1:34 PM, Ferenc Kovacs tyr...@gmail.com wrote: 2012.09.04. 18:58, Rasmus Lerdorf ras...@lerdorf.com ezt írta: On 09/04/2012 09:36 AM, Adam Richardson wrote: I think Ferenc is correct in that this sounds like there's a custom error handler somewhere. If the custom error handler collects error info and then throws an exception (as has been detailed in various blog posts as one manner of unifying the errors), this would cause the trouble you're seeing. Only on a new E_STRICT. Even with E_STRICT off by default, custom error handlers are still called, and I think Lester said that turning E_STRICT off made it work. So if this is the cause, then it has nothing to do with E_STRICT being in E_ALL or not, nor whether display_errors is on or off. It would have to do with the custom error handler blowing up on one specific E_STRICT, which I find rather unlikely. Don't forget that many error handlers check the error level against the currently set error_reporting (so that they won't be executed on supressed errors and such). AFAIR we even promote that implementation in our error handler example in our docs. That would mean that the error handler main logic is only executed if E_STRICT is in the error_reporting. I was second-guessing my recall I had a similar issue way back, after Rasmus pointed out that the custom error handler is called even if E_STRICT is off. However, I just looked back at my framework code, I see I'm checking to make sure the error level matches, just as Ferenc pointed out (what a forgetful old man I am.) So, I think this could still be causing the issue and it's something worth exploring on Lester's part. Adam -- Nephtali: A simple, flexible, fast, and security-focused PHP framework http://nephtaliproject.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] E_STRICT 'errors' - was Are exceptions allowed in php core?
Adam Richardson wrote: I was second-guessing my recall I had a similar issue way back, after Rasmus pointed out that the custom error handler is called even if E_STRICT is off. However, I just looked back at my framework code, I see I'm checking to make sure the error level matches, just as Ferenc pointed out (what a forgetful old man I am.) So, I think this could still be causing the issue and it's something worth exploring on Lester's part. If I have any custom error handling I don't know about it. I don't think ADOdb or SMARTY adds anything, and I don't load anything. Switching back to old code to at least prove to myself I WAS getting crashes, I got a white screen within half an hour of configuring an old setup. Knowing that I did get crashes when dealing with 'static' functions, I started there, and now that other things have been pointed out, the problem in that case is ALL parts of the codebase need to be updated at once. Otherwise fixing things in one library breaks other code. It may well be that having got a clean strict PHP5.4 setup I've then been getting problems when porting additional sites over. I KNOW that I've had a setup where simply switching E_STRICT on and off gives white screens, and I did have that situation a couple of weeks back. Simply adding and removing a custom error_reporting() got me working or not, but that was trying to run Joomla on a PHP5.4 setup with a strict clean PEAR and other libraries. So I may well have been suffering from 'cross contamination'. But this is the whole point ... getting a clean setup that will run older sites is a right pain :( I need to get back to a PHP5.2 setup which works and then cross check what is failing on the PHP5.4 setup. But none of this is productive work. Nothing I've moved over in the last 3 months have worked 'out of the box', all have had to have something done to get them running again. One thing I think is clear is that I need to avoid using a central PEAR until such time as everything is stable. Certainly that is this initial crash problem, but I know there were more problem areas. I am regretting giving in to the pressure to upgrade the shared codebase to be strict compliant. I think that I'd much further forward simply ignoring it altogether and done my own thing. Certainly some third party stuff left is not going to be work with E_STRICT any time soon :( -- 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
Re: [PHP-DEV] E_STRICT 'errors' - was Are exceptions allowed in php core?
On Tue, Sep 4, 2012 at 2:15 PM, Lester Caine les...@lsces.co.uk wrote: Adam Richardson wrote: I was second-guessing my recall I had a similar issue way back, after Rasmus pointed out that the custom error handler is called even if E_STRICT is off. However, I just looked back at my framework code, I see I'm checking to make sure the error level matches, just as Ferenc pointed out (what a forgetful old man I am.) So, I think this could still be causing the issue and it's something worth exploring on Lester's part. If I have any custom error handling I don't know about it. I don't think ADOdb or SMARTY adds anything, and I don't load anything. Well, Smarty can influence error handling: http://www.smarty.net/docs/en/api.mute.expected.errors.tpl And, ADOdb can, too: http://phplens.com/lens/adodb/docs-adodb.htm#errorhandling I'm not saying they're your issues, but just another spot to check. Adam -- Nephtali: A simple, flexible, fast, and security-focused PHP framework http://nephtaliproject.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] E_STRICT 'errors' - was Are exceptions allowed in php core?
Adam Richardson wrote: If I have any custom error handling I don't know about it. I don't think ADOdb or SMARTY adds anything, and I don't load anything. Well, Smarty can influence error handling: http://www.smarty.net/docs/en/api.mute.expected.errors.tpl I think I am right in saying that this is only Smarty3 The changes in this area was one reason for not upgrading to Smarty3. I don't think Smarty2 has an exception handler. But it my be that all of the templates have to be reworked for Smarty3 simply to take advantage of some of the other 'strict' updates in it. And, ADOdb can, too: http://phplens.com/lens/adodb/docs-adodb.htm#errorhandling Only using in-line error handling so adodb-exceptions.inc.php is not loaded. I'm not saying they're your issues, but just another spot to check. Joomla doesn't use either anyway, and neither do a number of the other sites I've been porting, but we still get problems. -- 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
Re: [PHP-DEV] E_STRICT 'errors' - was Are exceptions allowed in php core?
Now that you have changed the subject, I feel free to break in with a voice from userland. Rasmus Lerdorf in php.internals (Tue, 04 Sep 2012 09:57:59 -0700): Even with E_STRICT off (...) Sometimes it is not easy for users to turn off E_STRICT. Lester already mentioned one scenario: ISP's tend to install PHP with the default settings without the possibility to change them. Another scenario is the one that a framework or CMS overrides the php.ini settings. Quote from the bootstrap.inc of drupal7: // Enforce E_ALL, but allow users to set levels not part of E_ALL. error_reporting(E_ALL | error_reporting()); For the sake of argument I changed our development server from PHP 5.3.16 to PHP 5.4.6. I immediately got confronted with warnings like Warning: Illegal string offset 'field' in EntityReference_SelectionHandler_Generic_user-entityFieldQueryAlter() I know it is very bad coding in drupal7's bootstrap.inc. Read the comments at http://drupal.org/node/1267246 and you'll see I am not alone. Nevertheless, I am not interested in warnings like the one above from one of the many modules in drupal7. But I cannot turn off E_STRICT in drupal7 without changing bootstrap.inc manually. And that is the last thing I want to do. So I am changing our development server back to PHP 5.3.16. The E_STRICT change prevents me from upgrading to PHP 5.4. In my case I can just wait for a patch of bootstrap.inc. But users on a shared hosting server may have no way to avoid these warnings. Jan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] E_STRICT 'errors' - was Are exceptions allowed in php core?
On Tue, Sep 4, 2012 at 3:09 PM, Lester Caine les...@lsces.co.uk wrote:
Joomla doesn't use either anyway, and neither do a number of the other sites
I've been porting, but we still get problems.
Well, just to be sure, have you searched the entire codebase of one of
the existing sites experiencing the issues for the text
'set_error_handler(' just to be sure this isn't a possible cause?
Adam
--
Nephtali: A simple, flexible, fast, and security-focused PHP framework
http://nephtaliproject.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] E_STRICT 'errors' - was Are exceptions allowed in php core?
On 09/04/2012 12:20 PM, Jan Ehrhardt wrote: Now that you have changed the subject, I feel free to break in with a voice from userland. Rasmus Lerdorf in php.internals (Tue, 04 Sep 2012 09:57:59 -0700): Even with E_STRICT off (...) Sometimes it is not easy for users to turn off E_STRICT. Lester already mentioned one scenario: ISP's tend to install PHP with the default settings without the possibility to change them. Just call error_reporting() at the beginning of your script. It doesn't matter what your ISP has set there. You are in total control from userland. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] E_STRICT 'errors' - was Are exceptions allowed in php core?
Hi! I keep being told that there is nothing wrong with E_STRICT, and again someone has said that it does NOT cause crashes. I beg to differ here - IT DOES! If you have a scenario where E_STRICT causes PHP to crash - please submit a bug to bugs.php.net. If this is your application that is malfunctioning and not PHP then you should fix your application. If you have problems with that you can seek help on php-general or any other forums out there. In any case, I don't see how screaming about it here is going to lead to anything useful. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] E_STRICT 'errors' - was Are exceptions allowed in php core?
Rasmus Lerdorf in php.internals (Tue, 04 Sep 2012 13:15:50 -0700): Just call error_reporting() at the beginning of your script. Which ain't possible in drupal (or hardly). You do not write any code. You just click together modules, written by others. Jan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] E_STRICT 'errors' - was Are exceptions allowed in php core?
Jan Ehrhardt wrote: Rasmus Lerdorf in php.internals (Tue, 04 Sep 2012 13:15:50 -0700): Just call error_reporting() at the beginning of your script. Which ain't possible in drupal (or hardly). You do not write any code. You just click together modules, written by others. Actually Jan - Rasmus is right here - we just have to fix these applications to bypass problems. It's just a mater of someone who knows how to advancing the information. But it would be nice if projects like Drupal would indicate what they plan to do to bring their code in line with PHP's current 'standards'? Or if not, simply provide the configuration necessary for it to run without problems on each version of PHP? I have no problem with it being up to the projects to have to bend to the changes in PHP, my problem is that some of these bends are not totally thought out up front and are resulting in a lot of unnecessary work simply to stand still. generators are a case in point ... why did nobody who understands the fine detail spot the problem of hidden exceptions? Is it now a done deal that we have to live with these new ones now, or will an error based provision be made? It may take some time for me to go through ALL the white screen crashes I've been creating to cross check their actual cause, but without competent hand holding correcting mistakes like this, things are going to get missed. That IS all I have been asking for and the internals list is the only place where these questions get competent support. Although even here navigating the side issues can be interesting? -- 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
Re: [PHP-DEV] E_STRICT 'errors' - was Are exceptions allowed in php core?
Lester Caine in php.internals (Tue, 04 Sep 2012 22:30:34 +0100): Jan Ehrhardt wrote: Rasmus Lerdorf in php.internals (Tue, 04 Sep 2012 13:15:50 -0700): Just call error_reporting() at the beginning of your script. Which ain't possible in drupal (or hardly). You do not write any code. You just click together modules, written by others. Actually Jan - Rasmus is right here - we just have to fix these applications to bypass problems. It's just a matter of someone who knows how to advancing the information. But it would be nice if projects like Drupal would indicate what they plan to do to bring their code in line with PHP's current 'standards'? Drupal has four options for running under 5.4: 1. Turn E_STRICT off by default 2. Turn E_STRICT on by default 3. Do not mess around with system settings 4. Implement their own error_reporting setting, completely configurable (1) is not exactly bringing drupal in line with the current standards. It is a workaround. (2) and (3) will lead to loads of issues in those thousands of modules. (4) seems to me the only reasonable way out. Or if not, simply provide the configuration necessary for it to run without problems on each version of PHP? That would be (4) imo. However, there is no sign at all that the issue has ever attracted the full attention of one of the core developers. If you look at http://drupal.org/node/1267246 the current choice for drupal8 seems to be (3). Needs backport to drupal7 ... I will leave it with this, because it is way off topic in the internals list. Jan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
