[wp-trac] [WordPress Trac] #55603: PHP 8.2: address deprecation of the utf8_encode() and utf8_decode() functions
WordPress Trac
noreply at wordpress.org
Mon Feb 26 20:16:00 UTC 2024
#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):
Coming in late to this thread, but I will note that in this particular
case a polyfill would be trivial.
Given that we know many invocations of these functions are wrong, a
polyfill would let us prioritize the efforts to move away from them above
efforts to start requiring a new extension that otherwise isn't required.
And it's purely //because// `utf8_encode()` and `utf8_decode()` are so
trivial and small and deceptive in their names that I'm sharing this
opinion. It would be a different matter if we had to support large
databases of character conversion or if these methods were generally
useful, but the polyfill amounts mostly to a check if a code point is
within a small range and the function is deceitful in its name: it sounds
like something one should use when usually it's not.
Polyfilling thus leaves the status quo, which seems fair because the code
calling these methods can and maybe should be addressed in their own time
and with their own priority, instead of artificially as a result of
support in the language being pulled out.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/55603#comment:56>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list