Assert failure in ChainedPlaceholderStrategy.php

Could you include the stack trace that triggers this? (I think if xdebug is enabled it will print with the warning.)

The reason the assert is in quotes is so it doesn't execute any code in a production environment.

Agreed, STR would be great. #2's analysis is spot-on.

Very curious how you're triggering this :D I can't reproduce for sure.

Yeah, $protected is not a problem in asserts, see https://3v4l.org/WDoHQ

Just got it on today's 8.2.x

* Drupal version 6448749
* NO contrib (not even devel/kint)
* MacOS X
* php -v

PHP 7.1.0beta1 (cli) (built: Jul 29 2016 07:50:40) ( NTS )
Copyright (c) 1997-2016 The PHP Group
Zend Engine v3.1.0-dev, Copyright (c) 1998-2016 Zend Technologies
with Zend OPcache v7.1.0beta1, Copyright (c) 1999-2016, by Zend Technologies

Page worked a moment ago on PHP 7.0. Upgraded to 7.1 and got this. Drush command work normally. Drush cr does not fix it.

The problem disappears when reverting to 7.0.

Confirming #6, php 7.1 gives me assertion failures on drush and page loads.

It seems the example linked to by dawehner actually shows that HHVM and PHP7.1 differ from PHP5.x and 7.0 on that example, which could explain this observation:

- Older versions fail the assert()
- Newer ones succeed it.

Could be related to the "expectations" change for assert() in 7.1: http://php.net/manual/fr/function.assert.php#function.assert.expectations.

With 7.1, if zend.assertions is 0 or -1, the bug does not trigger. If zend.assertions is 1, it appears, whether assert.options is 0 or 1.

As mentioned in the issue summary, the problem goes away if the assertion is not quoted: since assert() is a language construct in PHP 7.1 (and possible HHVM), the assertion is not evaluated anyway.

Pending further investigation, the somewhat dubious patch attached addresses the issue for now. Let's run the bot (but it doesn't have 7.1 anyway).

Just hoping this won't mean revisiting #2408013: Adding Assertions to Drupal - Test Tools. and #2492225.

Just checked and the problem is also present in 8.1.x HEAD, as expected.

Do you still have the issue when applying the patch I suggested ?

Not sure whether this PHP-Version-dependent condition is the right approach to fix the cause, but patch in #9 seems to fix the warning (at least in my instance).

Thanks, @fgm !

Judging from the PHP 7.2 deprecation RFC, we could just as well start removing our "assert(string)" optimizations for 8.3.0

https://wiki.php.net/rfc/deprecations_php_7_2

See this Twitter conversation with Nikita Popov, who proposed that RFC: https://twitter.com/nikita_ppv/status/800800944804036608.

(@fgm triggered it, so he's aware of it. But I think anybody following this issue and looking at #14 should be aware of it.)

#2824745: WSOD on home page with PHP 7.1.0RC5, RC6

patch #9 work for me. Thx.

Ran into the same issue while running some tests with PHP 7.1.0RC3. After upgrading to PHP 7.1.1, the assertion no longer fails.

Might be caused by/related to Bug #73303 - Scope not inherited by eval in assert() (if that's the case, I assume this issue can be closed?)

I propose #2853503: Remove all assert('string') calls from Drupal core because deprecated in PHP 7.2 as alternative solution to this.

The issue definately needs revisiting. PHP 7 lets us turn assertions off entirely, PHP 5 forces us to use a now deprecated approach unless we want a slow down. Perhaps the following approach would be best, though it is nuanced.

For trivial operations, like this particular one, just don't use the eval method. The code becomes:

<?php
assert(!empty($this->placeholderStrategies), '...');

BTW, why are we merely asserting !empty here? Can't we assert the interface?

<?php
assert($this->placeholderStrategies instanceof PlaceholderStrategyInterface );

Anyway, in the event that we have an assertion that is time consuming to execute, we put it in an assertion method in the same class and guard against accidental execution in that function like so

<?php
public function foo() {
  assert($this->assertValidStartStateOfFoo(), '');
}

private function assertValidStartStateOfFoo() {
  if (assert_options(ASSERT_ACTIVE) == 0) {
    return TRUE;
  }
  // rest of test here
}

This isn't idea, but better than the alternative for PHP 5. I don't know if PHP 7 can be put into the nonsensical state of zend.assertions = 1 and assert.active = 0 -- that's something to be alert for if this solution is used.

EDIT: It can for BC reasons.

The Needs Review Queue Bot tested this issue. It either no longer applies to Drupal core, or fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

Apart from a re-roll or rebase, this issue may need more work to address feedback in the issue or MR comments. To progress an issue, incorporate this feedback as part of the process of updating the issue. This helps other contributors to know what is outstanding.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.