Element::smartDescription does not handle render arrays

Confirm: danjdewhurst's patch works.

But I've done it little bit less intrusive:

if(is_array($string))
  $string_clone = print_r($string, true);
else
  $string_clone = (string) $string;

Recently I came across the same notices and patch in #2 worked for me as well.
But then today I tried to login into my site by opening the /user/login page and my browser started to hang. In my PHP error log I found following message:

PHP Fatal error:  Maximum execution time of 300 seconds exceeded in /<path to my drupal root>/themes/contrib/bootstrap/src/Utility/Unicode.php on line 88

This led me to believe there are cases where $string actually is a string or an object as stated in the comment above in the bootstrap code. That's why I made a small modification which fixed it at my end. But I'm not a seasoned developer so it's better if someone (more skilled than me) reviewed my patch.

I hope it helps.

+1 The bug.

Patch #4 resolved it for me.

I'm not entirely sure if this error is due to the changes with typecasting

AFAIK, there haven't been any changes to typecasting in PHP 7.1.

I'm less inclined to believe this is a typecast bug, but perhaps it is a bug with how it might handle values other than strings or objects?

I need to know the value being passed when it encounters the line that throws the error.

This may also be a side effect of bad contrib module code that makes it way into the theme.

Well for me this bug occurs, because sometimes the $string is actually an array of 2 elements:

array (
  '#markup' => 'If project is the existing website, please specify the link.',
  '#allowed_tags' => 
  array (
    0 => 'a',
    1 => 'abbr',
    2 => 'acronym',
    ... ... ...
    78 => 'label',
    79 => 'fieldset',
    80 => 'legend',
  ),
)

I can debug it more if everybody else has this same issue. Forcing it into a string doe snot explain why we have it as an array in the first place. Technically, it should be the responsibility of the function that passes the variable to assure it's a string.

Technically, it should be the responsibility of the function that passes the variable to assure it's a string.

The only place this is really used currently is in Element::smartDescription.

This is used to determine if an element's #description can be converted into a tooltip.

It would appear that some contrib module is passing an array of #allowed_tags in conjunction with #markup. This would suggest that they have wrapped this on purpose, perhaps in an effort to circumvent SafeMarkup, even though this actually has no tags to "allow".

That being said, it is very uncommon for any contrib module to abuse #description in this way.

I'll post a patch shortly that should "fix" (a.k.a. simply account for render arrays) before sending it to this method.

Can anyone confirm/RTBC the above patch in #10? Thanks!

In my case, it does not resolve. Description is still being passed as an array. Attaching a debugger screenshot so you could see whats happening.

Whoops, forgot to replace the code below with the new $description variable. Try this one now.

Reviewed. Works. Thanks for all your work Mark!