PHP 7.4 Compatibility with WP 5.4.1 – problem with seems_utf8()

[fohly]

Since I updated to PHP 7.4 I with the newest WordPress version 5.4.1 I am getting error notices when seems_utf8() from formatting.php is called with an integer as parameter. (This seems to happen when something around Buddypress (v 5.2) leads to calling this function and passes some integer id. I have not found the origin of this yet).

PHP 7.3 still seems to accept that and will still interpret $str[ $i ] in line 904.
From 7.4 this will lead to an error notice “Trying to access array offset on value of type int …”. In addition, after the error notice all special characters on the page rendered are not displayed correctly anymore.
Can you please prevent this from happening? A line in the beginning of the function like
$str = (string) $str;
can fix this error notice.
Maybe there is a more elegant way to prevent this, but I right now I don’t find it …

Best regards
Florian

[SergeyBiryukov]

Hi there, welcome to WordPress Trac! Thanks for the the report.

The docs for ​seems_utf8() clearly say that it accepts a string. If something passes an integer to it, that seems like a developer error, so the notice is appropriate. I don't think we should silently hide developer errors.

[afragen]

I've seen this error in my logs on occasion. The difficulty lies in figuring out what caused it. Any way to add a stack trace to the error message?

I've come across the issue of integers passed to '_seems_utf8_' for validation and as a result PHP outputs a warning.

To preface the solution, I agree that seems_utf8 shouldn't be responsible for string conversions.

The function '_sanitize_file_name_' that is calling it though (in my case) is already making string conversions to normalize the param. This param is supposed to be a filename so making sure it is a string to begin with is only reasonable.

Trac ticket: https://core.trac.wordpress.org/ticket/50197