[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):

 While this ticket covers a broad set of concerns, it is my plan to **merge
 the polyfills** in [https://github.com/WordPress/wordpress-
 develop/pull/10011 wordpress/wordpress-develop#10011] after setting the
 `@since` versions to 6.9.

 As there has been some contention about this option I want to propose the
 following rationale:
  - Conditionally polyfilling the functions will not stand in the way of
 resolving this ticket. I will not close this ticket in the merge, but
 rather incorporate it into the independent work in #63863. PHP is losing
 functions that a variety of plugins and even Core currently calls. The
 polyfill will prevent unexpected site crashes; these crashes will be
 triggered in most cases by people who are not the direct site owners, so
 those affected will likely have little knowledge of how to fix the problem
 or agency to do it. The polyfills will keep WordPress reliable in the
 presence of a changing environment.
  - The polyfill functions are marked as deprecated. Whether calling PHP’s
 native deprecated functions or calling WordPress’ polyfilled functions,
 the warning instructs developers to update their code.
  - Preventing sites from crashing will not obstruct any efforts to update
 code. What //does// hamper refactoring is that most existing uses of these
 functions is wrong, as the functions were built from the start with a
 contextual and confusing nuance. There is usually no simple refactor to
 replace `utf8_encode()` with something inside of the `mbstring` extension.
 Decisions have to be made in most cases on how and what to break when
 refactoring. For example, a common use of these functions is to determine
 if a string is //already encoded as UTF-8// and then convert it if not.
 Fundamentally that it is an unsound judgement. Refactors will need to
 determine if they want to preserve the defects or reject unsupported
 inputs, or make some other adjustment.
  - Having polyfills does not speak to the question of requiring `mbstring`
 and having `mbstring` does not resolve the legacy use of `utf8_encode()`
 and `utf8_decode()`. In other words, these are two independent issues.

 Hopefully today or tomorrow I will merge the conditional polyfills, and
 then we can hopefully remove this small piece of the much bigger and more
 complicated issue being discussed here.

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