[wp-trac] [WordPress Trac] #55603: PHP 8.2: address deprecation of the utf8_encode() and utf8_decode() functions

[WordPress Trac]

#55603: PHP 8.2: address deprecation of the utf8_encode() and utf8_decode()
functions
--------------------------------------------+------------------------------
 Reporter:  jrf                             |       Owner:  hellofromTonya
     Type:  task (blessed)                  |      Status:  assigned
 Priority:  normal                          |   Milestone:  6.5
Component:  General                         |     Version:  6.0
 Severity:  normal                          |  Resolution:
 Keywords:  2nd-opinion php82 dev-feedback  |     Focuses:  coding-
                                            |  standards
--------------------------------------------+------------------------------

Comment (by dmsnell):

 @hellofromTonya my apologies for not clarifying in my first comment.

 > As far as I know, no PHP native function has ever been polyfilled due to
 it being removed from PHP.

 I'm not following how this is a con rather than a simple observation. What
 is the con?

 > As most uses of these functions are likely to be incorrect usage
 (especially in plugins), these "bugs" will remain and not be reviewed or
 addressed, undercutting the improvement PHP is trying to make.

 To me this is about priority, and what I meant in my earlier comment was
 that if we attempt to start requiring the internationalization extensions
 now that seems like a fairly large project in its own right and will
 potentially leave all of these existing cases broken anyway, because now
 while we technically don't support their use on platforms without the
 extensions, those existing sites will simply break.

 The goals of the PHP community are great: there's a never-ending supply of
 ways we could improve PHP by removing misleading and/or buggy functions
 that have been around for decades. Does that translate into a demand on
 WordPress to update existing code //right at the moment PHP decides to?//

 So the only "con" I interpreted was that this juncture, //which forces us
 to do something//, does not also force us to clean up existing code that
 wasn't on our radar to address. If we agree that all of this existing code
 needs refactoring, then we can take this moment to do that, though we'll
 still be racing against an external clock. Polyfilling doesn't make it any
 harder to find these instances, because they only require searching for
 [https://wpdirectory.net/search/01HQKJXJPT9ZRNTKPKT6P4W37G
 \butf8_(?:en|de)code\(].

 In other words, I don't see this con to carry much weight because it
 leaves things as they are without making them worse and it leaves control
 in our hands for how to prioritize our time. "Fixing" the existing code is
 inevitably going to introduce new bugs and raise questions we didn't
 realize we have to answer, and if we want to do that, we will need to form
 a plan to do so, and the only difference between polyfilling and requiring
 extensions is the artificial deadline and a large community thrust to add
 new requirements.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/55603#comment:58>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform