[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:
                                                 |  SergeyBiryukov
     Type:  task (blessed)                       |      Status:  accepted
 Priority:  normal                               |   Milestone:  6.9
Component:  General                              |     Version:  6.0
 Severity:  normal                               |  Resolution:
 Keywords:  2nd-opinion php82 dev-feedback has-  |     Focuses:  coding-
  patch has-unit-tests                           |  standards
-------------------------------------------------+-------------------------

Comment (by dmsnell):

 I’ve proposed a polyfill in [https://github.com/WordPress/wordpress-
 develop/pull/10011 WordPress/wordpress-develop#10011]. I believe it
 addresses most of the raised concerns for this ticket:

  - the polyfills are conditionally-defined and so are safe to deploy to
 older and newer versions of PHP.
  - the polyfills carry a deprecation notice to alert developers to
 refactor code calling these functions. however, it does not immediately
 force them to do so.
  - the polyfills are identical in behavior to the native PHP functions,
 relying on `mbstring` if the extension is available, otherwise relying on
 Core’s new UTF-8 pipeline.

 These polyfills are tested against the `mbstring` and against the UTF-8
 pipeline for accuracy.

 Core’s current use of these functions should be updated independently of
 any polyfilling, and polyfilling should not obstruct efforts to update
 Core’s use of these functions. However, I favor polyfilling for one
 central reason: **someone’s WordPress site should not inexplicably break
 when their host updates the version of PHP**. If plugins are calling these
 functions, that is what will happen without a polyfill.

 Ideally every developer across the ecosystem would update their code in
 time for the updates, but since we can’t control their code and many
 plugins are abandoned or already backlogged on updates, this approach
 protects those WordPress installations. I never want someone to wake up
 and find that their webpage is broken and they have no ability to diagnose
 or resolve it.

 Would really like to hear peoples’ thoughts on this and if it doesn’t
 address any of the concerns about polyfilling (other than the idea that if
 we prevent breakage it will remove the incentive for developers to update
 their code). We could merge this for 6.9.0 still and resolve half of this
 issue (or the whole thing depending on perspective — the use of
 `utf8_encode()` in Core is problematic even if replaced by
 `mb_convert_encoding()`)

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