[wp-trac] [WordPress Trac] #63825: Creating a post containing UTF-8, then changing WP_CHARSET to "latin1", makes posts un-editable.

[WordPress Trac]

#63825: Creating a post containing UTF-8, then changing WP_CHARSET to "latin1",
makes posts un-editable.
-------------------------------+-----------------------------
 Reporter:  mcc111             |      Owner:  (none)
     Type:  defect (bug)       |     Status:  new
 Priority:  normal             |  Milestone:  Awaiting Review
Component:  Posts, Post Types  |    Version:  6.6.2
 Severity:  normal             |   Keywords:
  Focuses:  ui                 |
-------------------------------+-----------------------------
 Context: I have a very old (circa 2007) WordPress install which I have
 been dutifully updating for 18 years. I post infrequently (my last two
 posts were in 2024 and 2016 respectively). Apparently when I first set
 this blog up, my posts were being made with the latin1 charset. Somewhere
 around 2020, WordPress silently switched to a different charset (I assume
 UTF-8). As a result, my old posts (the 2016 one and before) had all
 special characters become "garbage", for example "…" became "…" (see
 attachment "mojibake1") whereas the unicode characters in my 2024 posts
 were displayed correctly. (This is not the problem.) In a bid to fix this,
 I today tried adding "define('DB_CHARSET', 'latin1');" to my wp-config.php
 and restarted apache. I then found the 2016-and-before posts had correct
 special characters, whereas the 2024 post, I guess unsurprisingly, now
 showed garbage for all unicode characters (see attachment "mojibake2").
 (This is still not the problem.)

 The problem: Once I had added "define('DB_CHARSET', 'latin1');" to wp-
 config.php, my 2024 ("UTF-8 containing") post became non-editable.
 Clicking "edit" on it brings up a blank white page in the block editor
 (see attachment "editor1"). With the DB_CHARSET unset, opening the 2024
 blog post shows me the block editor as expected (see "attachment editor2")
 and commenting the DB_CHARSET line out in wp-config restores block editor
 functionality. Oddly, if I install the "Classic Editor" plugin and try to
 edit the text of the 2024 post, even in text mode the classic editor shows
 only a blank window (see attachment "editor3"). In none of these scenarios
 is an error message shown.

 The problem is not the date at which the 2024 post was created; the
 problem is the actual presence of the UTF-8 character bytes. I know this
 because I did the following: I commented-out my DB_CHARSET line (ie reset
 DB_CHARSET to defaults). I edited my 2024 post in the block editor, and I
 edited out all Unicode symbols (¹²³…) replacing them with plain ASCII
 equivalents. I then turned "'DB_CHARSET', 'latin1'" back on. Going back
 into the backend, I now find that the 2024 post is entirely editable, even
 in latin1 mode, and both the 2024 and 2016 post appear correctly.
 Conclusion: The editor is seeing UTF-8 bytes while constructing the editor
 page and bailing out silently.

 Expected behavior: The post should be editable regardless of what the
 DB_CHARSET is set to. But if there is a technical reason why a post
 containing UTF-8 cannot be edited when DB_CHARSET is set to latin1, then I
 would expect a clear error message. I believe showing an error message is
 more important than the editor being functional, as a blank white page is
 *very* hostile and raises fears of data loss.

 This is not a support request. I have a workaround (which, as described
 above, I have already applied) and my blog is currently working. But I
 believe you should fix this bug.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/63825>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform