# PHP5.4 'nannying' - Thread: https://externals.io/message/58998 - Original archive: https://news-web.php.net/php.internals/58998 - Started by Lester Caine on 2012-03-18T09:14:39+00:00 - Messages: 13 - 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 --- ## #58998 — Lester Caine — 2012-03-18T09:14:39+00:00 URL: https://externals.io/message/58998#58998 OK having jumped through several hoops trying to get a stable installation of Apache2.4.1 with PHP5.4 and Firebird 2.5.1 I now have a machine running and while I've not been able to do a speed comparison as yet performance does seem to be improved on what a simple comparison of machine speed improvement would suggest. Being a 6 core processor, on does wonder if better threaded performance of PHP with Apache would be an advantage? But the main problem now is handling an array of 'nanny' messages telling me that the code is badly written. Since the code base has been developed form an environment where it was still PHP4 compatible, many of the 'incremental improvements' of PHP5.2 and PHP5.3 have yet to be addressed, so I suspect that while the code runs clean with 'display_errors' ON in 5.3.10 I suspect every one of several hundred files now needs to be modified to include things like 'private/protected/static' correctly in every base and descendent class? Of cause things are not helped when PEAR packages add their own array of warnings, but the main problem is where the heck to start on this. I think what I am probably looking for is a clean guide as to how code SHOULD be written nowadays in order to avoid the nanny messages since it's certainly not my normal practice after 10 years of coding in PHP5 ... -- 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// Firebird - http://www.firebirdsql.org/index.php --- ## #59002 — Reindl Harald — 2012-03-18T11:35:22+00:00 URL: https://externals.io/message/58998#59002 · In reply to: #58998 Am 18.03.2012 10:14, schrieb Lester Caine: > I think what I am probably looking for is a clean guide as to how code SHOULD be written nowadays in order to avoid > the nanny messages since it's certainly not my normal practice after 10 years of coding in PHP5 ... usually it would have been enough if you had used full error-reporting from very first start and fixed deprecated warnings long ago this way i am maintaining a CMS with around 250000 LOC since 2003 and did every major PHP-upgrade wgere it is used and distributed on some hundret domains without any problem any code which does not run with `E_STRICT` is not allowed to run on our sevrvers and so the are no compromises needed yes, so easy is life if someone decides not support any crap --- ## #59003 — Kiall Mac Innes — 2012-03-18T12:53:10+00:00 URL: https://externals.io/message/58998#59003 · In reply to: #58998 May I suggest changing the error reporting value, that way we can stop hearing about your damn code ;) Seriously though, I doubt anyone has a guide like that. I know I've always had `E_STRICT` enabled and honestly don't have the slightest clue how to trigger a strict warning. When you develop with it on.. you just don't make those mistakes and identify new issues as they happen. Not 10 years of mistakes and depreciations at once. Your best bet is to disable strict warnings in production, and chip away at them as they show up on your development server. Thanks, Kiall Sent from my phone. > OK having jumped through several hoops trying to get a stable installation > of Apache2.4.1 with PHP5.4 and Firebird 2.5.1 I now have a machine running > and while I've not been able to do a speed comparison as yet performance > does seem to be improved on what a simple comparison of machine speed > improvement would suggest. > > Being a 6 core processor, on does wonder if better threaded performance of > PHP with Apache would be an advantage? But the main problem now is handling > an array of 'nanny' messages telling me that the code is badly written. > Since the code base has been developed form an environment where it was > still PHP4 compatible, many of the 'incremental improvements' of PHP5.2 and > PHP5.3 have yet to be addressed, so I suspect that while the code runs > clean with 'display_errors' ON in 5.3.10 I suspect every one of several > hundred files now needs to be modified to include things like > 'private/protected/static' correctly in every base and descendent class? Of > cause things are not helped when PEAR packages add their own array of > warnings, but the main problem is where the heck to start on this. > > I think what I am probably looking for is a clean guide as to how code > SHOULD be written nowadays in order to avoid the nanny messages since it's > certainly not my normal practice after 10 years of coding in PHP5 ... > > -- > 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// > Firebird - http://www.firebirdsql.org/**index.php OK having jumped through several hoops trying to get a stable installation > of Apache2.4.1 with PHP5.4 and Firebird 2.5.1 I now have a machine running > and while I've not been able to do a speed comparison as yet performance > does seem to be improved on what a simple comparison of machine speed > improvement would suggest. > > Being a 6 core processor, on does wonder if better threaded performance of > PHP with Apache would be an advantage? But the main problem now is handling > an array of 'nanny' messages telling me that the code is badly written. > Since the code base has been developed form an environment where it was > still PHP4 compatible, many of the 'incremental improvements' of PHP5.2 and > PHP5.3 have yet to be addressed, so I suspect that while the code runs clean > with 'display_errors' ON in 5.3.10 I suspect every one of several hundred > files now needs to be modified to include things like > 'private/protected/static' correctly in every base and descendent class? Of > cause things are not helped when PEAR packages add their own array of > warnings, but the main problem is where the heck to start on this. > > I think what I am probably looking for is a clean guide as to how code > SHOULD be written nowadays in order to avoid the nanny messages since it's > certainly not my normal practice after 10 years of coding in PHP5 ... > > -- > 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// > Firebird - http://www.firebirdsql.org/index.php > > -- > > > -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #59005 — Lester Caine — 2012-03-18T15:53:00+00:00 URL: https://externals.io/message/58998#59005 · In reply to: #59002 Reindl Harald wrote: > > Am 18.03.2012 10:14, schrieb Lester Caine: > > […] > usually it would have been enough if you had used full error-reporting > from very first start and fixed deprecated warnings long ago The code IS running clean in PHP5.3 and we had this same discussion back when all the deprecated warnings came in ... it took some months to get to a point where the error log was clean again ... > this way i am maintaining a CMS with around 250000 LOC since 2003 > and did every major PHP-upgrade wgere it is used and distributed on > some hundret domains without any problem > > any code which does not run with `E_STRICT` is not allowed to > run on our sevrvers and so the are no compromises needed > yes, so easy is life if someone decides not support any crap Ditto ... which is why the reams of new messages are what is somewhat confusing. The code runs fine and switching off the warnings prevents the logs growing at a rapid rate, I'm happy to run with display_errors = on because if an error does crop up we prefer to know about it fast. So I need to work out why with PHP5.4 we have such an overload of warning messages ... so I CAN fix them ... which is why I'm asking here for advise on migration information to a clean code base 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// Firebird - http://www.firebirdsql.org/index.php --- ## #59007 — Ferenc Kovacs — 2012-03-18T17:16:41+00:00 URL: https://externals.io/message/58998#59007 · In reply to: #59005 > Reindl Harald wrote: > > > […] > The code IS running clean in PHP5.3 and we had this same discussion back > when all the deprecated warnings came in ... it took some months to get to > a point where the error log was clean again ... > > > this way i am maintaining a CMS with around 250000 LOC since 2003 > > […] > Ditto ... which is why the reams of new messages are what is somewhat > confusing. The code runs fine and switching off the warnings prevents the > logs growing at a rapid rate, > I'm happy to run with display_errors = on because if an error does crop up > we prefer to know about it fast. > > So I need to work out why with PHP5.4 we have such an overload of warning > messages ... so I CAN fix them ... which is why I'm asking here for advise > on migration information to a clean code base in PHP5.4 ... > > http://docs.php.net/manual/en/migration54.other.php - *E_ALL* now includes *E_STRICT* level errors in the error_reporting configuration directive. I would guess your code was running clean, because you didn't have `E_STRICT` in your error_reporting, now in php 5.4, `E_ALL` includes that by default, and if you don't explicitly mask it, you will see those messages. -- Ferenc Kovács @Tyr43l - http://tyrael.hu --- ## #59008 — johannes@schlueters.de — 2012-03-18T17:27:50+00:00 URL: https://externals.io/message/58998#59008 · In reply to: #59005 > So I need to work out why with PHP5.4 we have such an overload of warning > messages ... so I CAN fix them ... which is why I'm asking here for advise on > migration information to a clean code base in PHP5.4 ... See http://php.net/migration54 if that doesn't help please check with a user forum (like php-generals list), if something is missing please file a bug and/or provide a patch. This list is not for user support. This list is for future development. Please help all here to keep it productive. Thanks. johannes --- ## #59009 — Lester Caine — 2012-03-18T17:53:25+00:00 URL: https://externals.io/message/58998#59009 · In reply to: #59007 Ferenc Kovacs wrote: > * *|E_ALL|* now includes *|E_STRICT|* level errors in the error_reporting > configuration > directive. > > I would guess your code was running clean, because you didn't have `E_STRICT` in > your error_reporting, now in php 5.4, `E_ALL` includes that by default, and if you > don't explicitly mask it, you will see those messages. This yet another example of subtle problems being created by not understanding when settings get overriden without it being obvious! My 5.3 servers are set up to ( `E_ALL` | `E_STRICT` ), and I was checking THAT in phpinfo, but a 'fix' for the strict errors had been applied elsewhere in the codebase which simply over-rid error_reporting so I was miss-led into thinking that these problems had been fixed some years back. The error_reporting 'fix' for `E_STRICT` errors was added back in 2009, and that was adding to my confusion this time around because my settings did not make sense because of the 5.4 change. A short term fix is to further bodge that override but I WOULD prefer to ACTUALLY fix the problems rather than just hide it again. SO my original question still applies, but for different reasons ... is there a crib sheet to help eliminate strict code errors in legacy code bases? -- 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// Firebird - http://www.firebirdsql.org/index.php --- ## #59010 — Lester Caine — 2012-03-18T17:55:36+00:00 URL: https://externals.io/message/58998#59010 · In reply to: #59008 Johannes Schlüter wrote: > This list is not for user support. This list is for future development. > Please help all here to keep it productive. Thanks. And hopefully to educate developers to understand some of the problems that they are creating by their actions? -- 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// Firebird - http://www.firebirdsql.org/index.php --- ## #59012 — Nikita Popov — 2012-03-18T18:00:23+00:00 URL: https://externals.io/message/58998#59012 · In reply to: #59009 > [...] SO my original question still applies, but for different > reasons ... is there a crib sheet to help eliminate strict code errors in > legacy code bases? Uhm, I'm not sure whether I am completely stupid and miss something obvious: But what exactly is the problem with just reading the error messages and fixing the errors they report? I mean, you get the reason for the error and the line which causes it, so what is the problem with going to that line and fixing that error? Nikita --- ## #59013 — Reindl Harald — 2012-03-18T18:03:37+00:00 URL: https://externals.io/message/58998#59013 · In reply to: #59009 Am 18.03.2012 18:53, schrieb Lester Caine: > Ferenc Kovacs wrote: > > […] > > This yet another example of subtle problems being created by not understanding when > settings get overriden without it being obvious! for you, yes > My 5.3 servers are set up to ( `E_ALL` | `E_STRICT` ), and I was checking THAT in phpinfo, but a > 'fix' for the strict errors had been applied elsewhere in the codebase which simply > over-rid error_reporting one of the big DO NOT therefore exists in httpd > SO my original question still applies, but for different reasons ... > is there a crib sheet to help eliminate strict code errors in legacy code bases? damned DISABLE display_errors what should NEVER be enabled in prdouction and start reading your error-log - why the hell do you need any generic sheet if your logfile tells you existing problems? --- ## #59020 — Lester Caine — 2012-03-18T20:27:47+00:00 URL: https://externals.io/message/58998#59020 · In reply to: #59012 Forgot the pigging reply all :( Nikita Popov wrote: > > > […] > Uhm, I'm not sure whether I am completely stupid and miss something > obvious: But what exactly is the problem with just reading the error > messages and fixing the errors they report? I mean, you get the reason > for the error and the line which causes it, so what is the problem > with going to that line and fixing that error? Nikita and others ... Yes I can quite happily go through and fix each error as it appears and over a few weeks the errors will have reduced, but that is not fixing the problem that 'modern' strict rules on coding style is somewhat different to how code WAS written 10 years ago. I'd rather FIX the code base so that it follows how `E_STRICT` expects the code to be written which I think needs a fairly major rewrite of some of the core code base. I think ADOdb needs a rework as well as other major libraries I am using which just adds to the hassle. The alternative is simply to bury my head again as has been suggested and force `E_STRICT` off in 5.4. But if I can't simply write code that IS 'complaint' in the first place because I don't have any guide to work to how do we expect newcomers to get their heads around the subtleties. They simply follow samples from old tutorials which have exactly the same problems I'm trying to solve myself :( ( I'll move the problem of how the heck one fixes the dozens of "Array to string conversion in" notices to the general list ... I'm seeing hundreds of reports of these on the net now that 5.4 is rolling out .. ) -- 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// Firebird - http://www.firebirdsql.org/index.php --- ## #59065 — Richard Lynch — 2012-03-19T21:07:27+00:00 URL: https://externals.io/message/58998#59065 · In reply to: #59002 > > > Am 18.03.2012 10:14, schrieb Lester Caine: > > […] I once worked with a team that didn't believe in E_NOTICE... I turned it on, and flooded the logs on a shard DEV. I turned it off. Copied the source to my own box, ran it with E_NOTICE, did some grep/sed/awk mumbo-jumbo to find the most common messages, fixed those, and committed them. And found, corrected, and closed about 5 long-standing bugs in the process. They started to think maybe I was on to something here... :-) We turned `E_NOTICE` back on at that point, as it was only an odd script once in a while that went to the logs. Or new code from that one guy who still didn't quite "get" it for awhile... He came around after we fixed a couple of his newly-introduced bugs that were triggering E_NOTICE... -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE