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
