Problem/Motivation
PHP default assertion handling has been changed in 7. The time has arrived to move to a PHP 7 conformant setup.
Proposed resolution
First we must remove calls to the assert_options() function. This allows for runtime manipulation of assertion activity, and we have unit tests that manipulate it as well as the PHP 5/7 compat shim in the Assertion\Handle library. These need to go. Relevant from the PHP docs:
While assert_options() can still be used to control behaviour as described above for backward compatibility reasons, PHP 7 only code should use the two new configuration directives to control the behaviour of assert() and not call assert_options().
I read this with a strong possibility that assert_options() might find itself deprecated and removed at some point in the future.
Since the .htaccess file does not affect the PHPUnit tests ran from the command line it becomes incumbent on the environment files to set this functionality up correctly. References to assertions will be removed from .htaccess as they set up a false expectation that this file alone can control them.
assert.exception
This flag determines whether exceptions are thrown on assert failure (1) or if a warning is emitted (0). The default is 0, errors, and this is the PHP 5 compatible behavior. The PHP default is 0, and Drupal should have this setting set to 1.
zend.assertions
There are three possible values as detailed in the PHP docs. They are:
- 1: generate and execute code (development mode)
- 0: generate code but jump around it at runtime
- -1: do not generate code (production mode)
1 is the default. 0 is an emulation of PHP 5 behavior for backwards compatibility and shouldn't be considered as a possible candidate. -1 should be the production default.
Performance Concerns
Since PHP ships with assertions on by default leaving it to the site admins to turn them off will incur a performance hit for those who fail to do so. If we are to follow the PHP Group recommendation though we have no choice. Also, there are advantages to this approach - we can run the tests with runtime assertions turned on or off at our leisure so long as all unit tests which check to see if an assertion was tripped are skipped when assertions are turned off.
Whither PHP 5?
Once the parent ticket to this one is implemented PHP 5 will always run assertion related code, it just won't check to see if the return was true or false. So if there's a site breaking bug in that code under PHP 5 it will be found when the test fails to run because of the bug. In effect we are taking advantage of PHP 5's bad design of running assertions at all times.
Remaining tasks
Resolve:
📌
Improve assertion test failures with bad zend.assertions value
Needs work
None for this ticket. There is a child issue ticket for the status report change.
User interface changes
The status report will include zend.assertions current setting and mark it as a potential problem if it isn't the production value of -1.
API changes
None.
Data model changes
None.