Make WordPress Core

Opened 4 years ago

Last modified 22 months ago

#50197 new defect (bug)

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

Reported by: fohly's profile fohly Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version: 5.4.1
Component: Formatting Keywords: close 2nd-opinion has-patch
Focuses: Cc:


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

Change History (3)

#1 @SergeyBiryukov
4 years ago

  • Component changed from General to Formatting
  • Keywords close 2nd-opinion added

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.

#2 @afragen
4 years ago

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?

This ticket was mentioned in PR #3040 on WordPress/wordpress-develop by tracend.

22 months ago

  • Keywords has-patch added

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:

Note: See TracTickets for help on using tickets.