Remove mentions of assert.active from .htaccess

at CLI side

/var/www/html/web $ php -v
PHP 8.3.0RC5 (cli) (built: Oct 24 2023 23:57:57) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.3.0RC5, Copyright (c) Zend Technologies
    with Zend OPcache v8.3.0RC5, Copyright (c), by Zend Technologies
/var/www/html/web $ php -dassert.active=0 -r 'echo 1;'
PHP Deprecated:  PHP Startup: assert.active INI setting is deprecated in Unknown on line 0
1

Searched for assert.active in .htaccess and 1 instance has been replaced.

Tagging for release notes because this should go in 'changes to site owner managed files'.

Also tagging for a change record update because the one linked doesn't explicitly mention .htaccess yet.

I agree with removing assert.active, but not with removing the documentation for adding PHP settings. I relied heavily on this documentation to get my sites working when I started out with Drupal.

I restored the PHP settings documentation to the 11.x branch. I don't think assertions should be enabled by default in 10.x because they are used in contrib projects, so I added a merge request for 10.x that replaces assert.active with zend.assertions.

Don't see any issue with leaving the comments. Think this missed 10.2 though.

Darren Oh → changed the visibility of the branch 3398033-remove-assert.active to hidden.

I don't think a default setting for assertions should be removed in Drupal 10. I switched the merge request for 10.2.x to 11.x and changed zend.assertions to a value that can be overridden in settings.local.php. Also updated the change record.

Think 10.3 should be fine. But MR has a test failure now.

Didn't realize files in the sites folder were scaffolded.

Not sure it makes sense to have this sessions in .htaccess and setting.php as well

I'd just removed this lines

settings.local.php has a different value for development environments.

Left a comment on the MR

We should just replace the deprecated setting with the correct setting and stop trying to remove something that helps users set up a development environment correctly. Recommending a correct setting for php.ini is compatible with showing how to override it temporarily in the example settings.local.php.

assert.active takes precedence over zend.assertions. Does it mean all tests running on Apache does not check for assertions? If so I would consider this as a bug.

Chi, we have always disabled checking for assertions in Apache by default, with the option to enable checking in settings.local.php. Please review.

If zend_assertions is set to prod mode, in php.ini this statement in .htaccess

+ php_value zend.assertions 0

causes the following warning in Apache error log

[php:warn] [pid 176] [client 172.29.0.254:50836] PHP Warning: zend.assertions may be completely enabled or disabled only in php.ini in Unknown on line

The default value is 1, so if an administrator sets it to -1 they can also remove the line from .htaccess.

The default value is 1

The default value may be set by Linux distributions or hosting providers. They don't know much about Drupal requirements.

The recommended php config for production has zend.assertions at -1, and I think this will be pretty commonly installed. And so you have that warning message logged for every request. My 2 cents is that setting zend.assertions is something that should be documented for developers to do, rather than happening out-of-the-box

Looks ready to go, comments make sense, thank you!

I think the change record needs updating. We're no longer setting in .htaccess and we appear to be recommending managing this in your php.ini. The Cr should explain the intricacies here.

Analysis: assertions enabled until you update to the latest example.settings.local.php👻

This caused hours of wasted time, due to assertions no longer being enabled automatically if you opt in to using settings.local.php.

1. #3186524: Fix htaccess files for PHP 8 → added
   

   <IfModule mod_php.c>
     php_value assert.active                   0
   </IfModule>
   

   which worked fine in tandem with example.settings.local.php at the time

2. but then 📌 Fix deprecated assert_options() function usage for PHP 8.3 Needs review reverted the assertion-enabling logic in example.settings.local.php, because it used the PHP 8.3+ deprecated assert.active, without changing the .htaccess to match
3. #3375693's CR ( https://www.drupal.org/node/3391611 → ) tells you to enable assertions by manually adding ini_set('zend.assertions', 1); to settings.local.php (requiring to do this manually is a DX regression FWIW) … BUT THIS DOES NOT WORK due to the assert.active=0 in the .htaccess 🤪🙈 It has no effect, because while assert.active is deprecated, it does have an effect! IOW: the CR is broken.

This required over an hour of falling down the rabbit hole, culminating in #3500110-5: PHP asserts not running in CI/during tests → , and caused a significant disruption to Experience Builder.

I did not notice this for a long time because I had carried over my own settings.local.php until very recently … 👻 … because while PHP 8.3 might have deprecated using assert_options(…), it totally worked fine!

Manual test: 👍

I manually tested this MR and can confirm this restores the original, expected DX: enabling settings.local.php.

… and AFAICT

📌 Fix deprecated assert_options() function usage for PHP 8.3 Needs review also removed this from DrupalKernel:

        // Web tests are to be conducted with runtime assertions active.
        assert_options(ASSERT_ACTIVE, TRUE);
        // Force assertion failures to be thrown as exceptions.
        assert_options(ASSERT_EXCEPTION, TRUE);

… does that mean that currently GitLab CI is running the test suite without assertions enabled too? https://git.drupalcode.org/project/gitlab_templates has zero matches for the keyword "assert" 😱 I'm afraid that's the case…

RE: AFAICT in #31: I can now confirm that

<IfModule mod_php.c>
  php_value assert.active                   0
</IfModule>

disables assertions during tests in a way that cannot actually be restored by the recommended settings.local.php when running tests locally using Apache as the web server! You actually need to bring back assert.active 😅

This is not a problem when developing or testing Drupal in a non-Apache web server, because .htaccess has no effect on those.

Potential work-arounds:

1. Add a </code> to the <code>.module file of your contrib module for whose test runs you want to enable assertions (thanks @longwave!) — see #3500110-10: PHP asserts not running in CI/during tests →
2. Append this to .htaccess:
   

   <IfModule mod_php.c>
     php_value zend.assertions                   1
     # Revert this part when https://www.drupal.org/project/drupal/issues/3398033 is fixed in Drupal core.
     php_value assert.active                   1
   </IfModule>
   

   (should be doable in .gitlab-ci.yml, too)

Should we add

if (ini_get('zend.assertions') !== -1) {
  ini_set('zend.assertions', 1);
}

and even though it's deprecated maybe even

ini_set('assert.active', 1);

back to DrupalKernel::bootEnvironment() when we detect we are running in a test environment? This would attempt to force a more consistent environment in tests.

This lead me to finding 🐛 \Drupal\Tests\system\Kernel\MenuAccessControlHandlerTest::testAccessProvider Active for trivial patch of the month.

ini_set('zend.assertions', 1);ini_set('zend.assertions', 1);

This settings can be changed only starting PHP https://www.php.net/manual/en/ini.core.php#ini.zend.assertions

@andypost I read that as: if it's -1 you cannot change it, but otherwise you can swap between 0 and 1 at runtime?

Re #36. That's correct. And if we should probably emit some notice when assertions are in production mode when running tests.