[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.6
Component:  General                         |     Version:  6.0
 Severity:  normal                          |  Resolution:
 Keywords:  2nd-opinion php82 dev-feedback  |     Focuses:  coding-
                                            |  standards
--------------------------------------------+------------------------------

Comment (by jrf):

 Okay, I have a feeling this ticket is going off the rails, so let's see if
 we can get it back on track.

 This ticket has a dual purpose:
 1. Fix the 4 instances of `utf8[en|de]code()` in WordPress Core.
 2. Put the tools in place to make it more straight-forward for
 plugin/theme developers to fix ''their'' uses of these functions by making
 a PHP extension a requirement for WordPress.


 [1] can be addressed at any time prior to PHP 9.0, which is still nearly
 two years away, possibly longer.
 Remember: deprecation notices are not errors, nothing is broken and nobody
 should run with `E_DEPRECATED` enabled in production.
 So there is no urgency, other than an urgency to prevent the ''wrong''
 solution from being committed.

 [2] is - for WordPress Core - not essential to fix [1], but would:
 * ''inform'' whether an optimal/simple fix can be used for [1] or whether
 a slightly more complicated fix will need to be created for those four
 usages in WP Core.
 * Make it straight-forward for plugins/themes to fix ''their'' uses of
 `utf8[en|de]code()` as they can then rely on all solution directions, as
 outlined in the RFC, being available.
 * Allow for WordPress Core to fix other long-standing issues related to
 internationalization of websites.
 * Allow for removing some polyfills from WordPress Core.
 * Allow for preventing potential conflicts between plugins which both ship
 with MbString polfyfills (where the polyfill implementations could be
 different between plugins).
 * Allow for plugins, which need MbString, to simplify their code and rely
 on the extension being available.
 * etc etc

 As there is time - basically four years or more between the opening of
 this ticket and PHP 9.0 -, this deprecation was a good trigger to have a
 discussion about [2], which would allow for structural improvement.

 So far, this discussion has been going nowhere as nobody seems to dare to
 take a decision about this.

 WordPress Core can get by without MbString (only polyfilling select
 functionality from the extension) and can just continue to ignore those
 long-standing internationalization issues. It won't block fixing the uses
 of `utf8[en|de]code()` in Core and it would maintain the status quo
 without introducing new functions.
 It would just make life so much harder for the wider WP community if
 that's what ends up happening.


 > Keep in mind that the site counts for a 0.5% is not insignificant.

 I fully recognize that, but keep in mind that those 0.5% will be English-
 language installs only and declining the proposal to make MbString a
 requirement for WordPress Core is tantamount to prioritizing that 0.5% of
 English-language installs over the > 50% of non-English language WordPress
 installs in the world, which makes a telling and concerning statement
 about how WordPress leadership views non-English-language installs as
 second rate citizens.

 WordPress has already been recommending enabling the MbString extension
 for quite a while, polyfills select functions from the extension and both
 the [https://github.com/JamesHeinrich/getID3/blob/2.0/composer.json#L30
 GetID3] as well as the
 [https://github.com/simplepie/simplepie/blob/master/composer.json#L45
 SimplePie] external dependencies also have it as listed as a strongly
 suggested extension for their current versions.

 In other words, what is needed for this ticket is a decision within the
 next two years. With a preference for taking such a decision sooner rather
 than later as that will allow more plugins/themes to be ready for PHP 9.0
 in time.

 What we don't need is avoiding the issue altogether by putting an
 awkwardly named polyfill in place, which would effectively result in the
 incorrect uses of these functions never getting fixed, as technical debt
 never gets priority in Core (unless forced by PHP/PHPUnit).

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