[wp-trac] [WordPress Trac] #55603: PHP 8.2: address deprecation of the utf8_encode() and utf8_decode() functions
WordPress Trac
noreply at wordpress.org
Fri Mar 1 18:12:25 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.6
Component: General | Version: 6.0
Severity: normal | Resolution:
Keywords: 2nd-opinion php82 dev-feedback | Focuses: coding-
| standards
--------------------------------------------+------------------------------
Comment (by dmsnell):
> Many WP site will be on PHP 8.2 and below for many years to come,
continuing to experience these deprecation warnings
I can understand where this would be a hassle, given that PHP will spit
out those messages on the console for sites that are essentially working
fine.
In that case, maybe we missed a silly third option, which is replace
Core's use of these functions with a differently-named polyfill. The
upsides of replacing calls to `utf8_encode` are clear, but the cost of
making those changes isn't. If we would still have interest in what is
essentially a zero-effort change, it seems like adding
`deprecated_utf8_encode()` and `deprecated_utf8_decode()` could defer the
maintenance work (valuable since the existing code //is working// more or
less) while eliminating the warnings and also making these uses standout
for more gradual and safe refactoring.
For transparency sake here I'm only sharing ideas that I think have
possibly-valuable tradeoffs in order to meet an //urgent// need without
forcing more costly and risky rewrites. I don't hold a strong opinion on
this or what everyone decides.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/55603#comment:65>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list