[D7 PHP 8.1] strpos(): Passing null to parameter #1 ($haystack) of type string is deprecated in text_summary()

Because there are multiple calls in text_summary() which can potentially cause deprecation warnings if $text will be null I chose the way of returning the empty $text at the very beginning if it is empty.

Yes, that is a good point, thanks. It will be better to focus only on the NULL issue in the patch and don't change behavior for other possible variable types. I am attaching updated patch.

Adding test.

@gbirch, there are lot of functions where your mentioned approach could be used, if we decide to go this way (drupal_strtoupper(), drupal_strtolower(), ...). But preferably we try to fix reported issues where they originated. We have made few exceptions in functions, where multiple contrib modules (and probably also core modules) were sending NULL instead of a string data. But the official policy for core is not babysit broken contrib code.

I am not sure if there are any open issues about the drupal_strlen() PHP 8 warning somewhere (except this fixed one). If yes, we can check the issue and the root cause of the problem and decide about the fix. If not, then I am not sure about fixing something, that is not an issue now. Thanks!

The documentation of the drupal_strlen() function is as follows:

/**
* Counts the number of characters in a UTF-8 string.
*
* This is less than or equal to the byte count.
*
* @param $text
* The string to run the operation on.
*
* @return integer
* The length of the string.
*
* @ingroup php_wrappers
*/

So it specifies, that the input has to be a string (in the parameter description), but it is not enforced like in D10. So yes, you were able to pass NULL to these functions prior to PHP 8 without problems, but only because the underlaying strlen() function allowed that. Here are the reasons for this change in PHP: https://php.watch/versions/8.1/internal-func-non-nullable-null-deprecation.

Finally, the whole POINT of those functions is to provide a wrapper around different PHP implementations, character sets, etc. This would be just one more compatibility wrapper.

Yes, this is true. But as I have mentioned earlier, we cannot fix non-existing problems. So either there is an open issue about another problem with drupal_strlen() in PHP 8+, and we can take a look at options here, or someone need to create such issue, so that we can consider this change. We are not going to do anything else in this issue, as it is closed (fixed). Thanks!

@gbirch There is a new issue #3362238: _form_validate sends null to drupal_strlen triggering deprecation notice, which looks valid and we can discuss the potential global fix for drupal_strlen() there. Thanks.