[wp-trac] [WordPress Trac] #61680: is_utf8_charset() undefined when called by code in compat.php

[WordPress Trac]

#61680: is_utf8_charset() undefined when called by code in compat.php
-------------------------------------------+---------------------
 Reporter:  dmsnell                        |       Owner:  (none)
     Type:  defect (bug)                   |      Status:  new
 Priority:  high                           |   Milestone:  6.6.1
Component:  General                        |     Version:  6.6
 Severity:  normal                         |  Resolution:
 Keywords:  has-patch dev-reviewed commit  |     Focuses:
-------------------------------------------+---------------------

Comment (by dmsnell):

 > However, the other problem that I just noticed when looking at this
 again, is that now any time the _mb_substr() and _mb_strlen() polyfills
 are used, they will not be able to make use of the site's option setting,
 even though in a majority of cases, the need to avoid the get_option()
 call is unnecessary and unexpected. That seems like a bigger problem. That
 does seem like something we want to avoid.

 @joemcgill thanks for sharing more. please note, however, that this patch
 does not change the behavior of the polyfills for `blog_charset`. In
 `compat.php` they make the call directly if no charset is provided. Before
 and after this change, the behavior is identical: if no charset is
 provided before `functions.php` is loaded, the call will crash; otherwise
 it will default to calling `get_option()`.

 > Splitting the implementation into two different functions which exist in
 two separate files could be a bit confusing for future maintainers.

 I hear this. It was difficult for me to see a clear dominant solution
 among the options. Even leaving things as they were was obviously a
 maintenance issue and the motivation for the function was that Core
 maintained multiple sets of differing rules for the same intention.

 The wrapper now is at least a single line where the only thing it does is
 default to trying to infer the blog charset. If we can deprecate non-UTF-8
 charsets inside of WordPress (ignoring any data stored in the database for
 now), then we can eliminate far more of these things which are scattered
 all over.

 > We need to figure out a way to prevent issues like this in the future
 …follow-up ticket

 Thanks @jorbin - this was my plan as well. I think that a CI job would be
 most capable here of detecting these things. Even though I still support
 adding documentation at the top of some file, I've seen a very low
 effectiveness of that guard, as developers tend to jump into the middle of
 the file and never look at the top.

 ----

 Thanks all for taking care of merging this and getting it into the
 release.

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