Closed (outdated)
Project:
Drupal core
Version:
9.2.x-dev
Component:
base system
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Reporter:
Created:
7 Jul 2011 at 14:13 UTC
Updated:
2 Jan 2022 at 04:35 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
sunI've to admit I don't think I've ever experienced a PHP compile-time error. What is this? And when does it happen? How is it possible for Drupal to trigger one?
Comment #2
mfbJust wanted to clarify that -1 has nothing to do with reporting compile-time errors. -1 is just a special value that means report all (really all :) errors. It's useful since PHP constants like E_ALL or E_STRICT aren't available in some contexts, like .htaccess.
PHP reports some errors during compile-time rather than during execution. To catch compile-time errors you need to have error reporting enabled before PHP starts executing, which means setting error_reporting in your PHP config, Apache config or .htaccess. By setting it to -1 in one of these places you will see all compile-time errors, including E_STRICT.
Drupal 7 had lots of E_STRICT compile-time errors during its development cycle that we patched in #348448: Always report E_STRICT errors (and maybe elsewhere). As far as I remember it was mostly incorrect method signatures.
Comment #3
mfbObligatory PHP manual reference: http://us2.php.net/manual/en/function.error-reporting.php
"Most of E_STRICT errors are evaluated at the compile time thus such errors are not reported in the file where error_reporting is enhanced to include E_STRICT errors (and vice versa)."
"Passing in the value -1 will show every possible error, even when new levels and constants are added in future PHP versions."
Comment #4
catchThis really feels like a development setting to me so it will need to be commented out by default for tagged releases at least (E_STRICT in bootstrap.inc probably too).
That partly makes me think we should just enable E_STRICT on the testing infrastructure and recommend it for development, I'm not sure how much is gained from a .htaccess flag given not all Drupal code runs through apache.
If we do add this, it'd be good to confirm either way whether it's possible to do the same in web.config. Doesn't matter if we can't, but good to keep them closer if we can.
Comment #5
jrchamp commentedIn the interest of seeing what happens, setting this to Needs Review so the test bot can show us the current behavior.
Comment #6
jrchamp commentedHere's an E_COMPILE_WARNING for comparison.
Comment #7
mfbI'd agree with catch that E_STRICT just needs to be set in the test bot environments and documented as recommended for development environments. This is in fact the same as PHP's recommendations in php.ini: Development Value: E_ALL | E_STRICT.
Comment #8
jrchamp commentedNote that #6 ignored the E_COMPILE_WARNING:
[11:05:03] Command [php -l -f './index.php' 2>&1] succeeded
Duration: 0 seconds
Directory: [/var/lib/drupaltestbot/sites/default/files/checkout]
Completion status: [0]
Output: [PHP Warning: Unsupported declare 'warning' in ./index.php on line 2
No syntax errors detected in ./index.php].
Comment #9
thedavidmeister commented#6: drupal_compile_warning-1211878-6.patch queued for re-testing.
Comment #10
alansaviolobo commentedif this is environment dependent, i guess we could put it in settings.php
Comment #13
marvil07 commentedThis may be related with #2019151.
Patches here does not add code but are proofs of concept, and as mentioned on comment 4 there is not a general solution since drupal does not always run on top of apache, back to "Active" since this is still in early agreement.
Comment #21
mfbI don't think this is relevant anymore.
In the ancient PHP versions, compile-time errors were often silently ignored, but nowadays many of these are now fatal errors. Problem solved :P
(This fact is why it was a good idea to make sure it was easy for developers to see them way back when :)