Uses UTF8MB4 everywhere #8425

Sesquipedalian · 2025-01-30T23:05:58Z

Fixes #7938
Fixes #7173
Closes #6409
Closes #6406

Use InnoDB and dynamic rows for MySQL. This makes a whole lot of things easier. (See discussion in Use UTF8MB4 everywhere #7938.)
When installing, require utf8mb4 support for MySQL, for obvious reasons.
Create tables using utf8mb4 by default for MySQL and Always use utf8mb4 input/output for MySQL, also for obvious reasons.
Autodetects $this->character_set and $this->mb4 in DB APIs. This means we no longer need to set those values in Settings.php.
Rewrites the ConvertUtf8 upgrader step for mb4 support. This is probably the most important part to test in multiple environments and with multiple datasets. It works for me, but I would really appreciate it if @sbulen could use that comprehensive test suite of his to test it.
Removes obsolete character set variables and related logic, because we don't need them anymore.
Moves Utils::fixUtf8Mb4() to DatabaseApi::fix_mb4() and Transparently decodes entities for four-byte Unicode, because only the database API layer should know or care about whether the database supports 4-byte UTF-8. The rest of the application can and should work with the full UTF-8 character set without worrying about the details of the database's storage character set.

Signed-off-by: Jon Stovell <jonstovell@gmail.com>

jdarwood007 · 2025-02-01T15:16:15Z

Looks like 90% of this is just removing and hardcoding UTF-8 on everything. InnoDB is a fairly safe conversion. Just may take longer for larger forums on certain tables, but nothing can be avoided in timeout protections for that. It looks good from what I see.

Signed-off-by: Jon Stovell <jonstovell@gmail.com>

sbulen · 2025-02-03T00:04:51Z

I'll run some test upgrades. Merge conflicts need to be resolved first, though.

Or is there a per-requisite PR?

Signed-off-by: Jon Stovell <jonstovell@gmail.com> # Conflicts: # Sources/Db/APIs/MySQL.php

Sesquipedalian · 2025-02-03T00:13:29Z

I'll run some test upgrades. Merge conflicts need to be resolved first, though.

Great! Thank you. 🙂 Merge conflict has been resolved.

Or is there a per-requisite PR?

Nope.

sbulen · 2025-02-03T02:51:40Z

First test was an upgrade of a new, vanilla 2.1.4 forum to 3.0, via CLI.

I followed the old 2.1.x protocol, where I would copy the upgrade files over from the /other folder, then run upgrade.php.

DB: MySQL, version 8.4.0
php: 8.4.2

Had a few errors, here is the complete output:

Updating Settings.php... Successful.
Error: Undefined variable $file_substrsteps File: D:\wamp64\www\van2130\upgrade.php Line: 2403 * +++ Updating old values done.
+++ Changing default values done.
. Successful.

+++ Removing all karma data, if selected done.
Successful.

+++ Emptying error log, if selected done.
Successful.

+++ Adding login history... done.
+++ Copying the current package backup setting... done.
+++ Copying the current "allow users to disable word censor" setting...Error: Trying to access array offset on null File: D:\wamp64\www\van2130\upgrade.php(2521) : eval()'d code Line: 7 done.
+++ Converting collapsed categories... done.
+++ Parsing board descriptions and names done.
+++ Dropping "collapsed_categories" done.
+++ Adding new "topic_move_any" setting done.
+++ Adding new "enable_ajax_alerts" setting done.
+++ Adding new "alerts_auto_purge" setting done.
+++ Adding new "minimize_files" setting done.
+++ Collapse object done.
+++ Adding new "DEFAULTMaxListItems" setting done.
+++ Adding new "loginHistoryDays" setting done.
+++ Enable some settings we ripped from Theme settings done.
+++ Adding new "httponlyCookies" setting done.
+++ Adding new "samesiteCookies" setting done.
+++ Calculate appropriate hash costError: Passing E_USER_ERROR to trigger_error() is deprecated since 8.4, throw an exception or call exit with a string message instead File: D:\wamp64\www\van2130\Sources\Db\APIs\MySQL.php Line: 2527Error: Invalid data structure sent to the database.(upgrade.php(2521) : eval()'d code-1) File: D:\wamp64\www\van2130\Sources\Db\APIs\MySQL.php Line: 2527
Fatal error: Uncaught TypeError: array_combine(): Argument 2 ($values) must be of type array, string given in D:\wamp64\www\van2130\Sources\Db\APIs\MySQL.php on line 430

TypeError: array_combine(): Argument 2 ($values) must be of type array, string given in D:\wamp64\www\van2130\Sources\Db\APIs\MySQL.php on line 430

Call Stack:
0.0079 1402080 1. {main}() D:\wamp64\www\van2130\upgrade.php:0
0.4792 5966336 2. DatabaseChanges() D:\wamp64\www\van2130\upgrade.php:371
0.4833 5967968 3. parse_sql($filename = 'D:\wamp64\www\van2130/upgrade_2-1_MySQL.sql') D:\wamp64\www\van2130\upgrade.php:1869
2.3360 6283880 4. eval('D:\wamp64\www\van2130\upgrade.php(2521) : eval()'d code') D:\wamp64\www\van2130\upgrade.php:2521
3.0980 6781696 5. SMF\Db\APIs\MySQL->insert($method = 'replace', $table = '{db_prefix}settings', $columns = ['variable' => 'string', 'value' => 'string'], $data = [0 => 'bcrypt_hash_cost', 1 => 14], $keys = [0 => 'variable'], $returnmode = ???, $connection = ???) D:\wamp64\www\van2130\upgrade.php(2521) : eval()'d code:1
3.0982 6782016 6. array_combine($keys = [0 => 'variable', 1 => 'value'], $values = 'bcrypt_hash_cost') D:\wamp64\www\van2130\Sources\Db\APIs\MySQL.php:430

sbulen · 2025-02-03T03:26:13Z

I repeated the above test via browser, & get this error. Note the 2.1 environment being upgraded is using the default, English.

This may help understand the CLI errors:

Sesquipedalian · 2025-02-03T04:43:22Z

Okay, so it looks like we have some unrelated upgrader bugs to fix before you can even get to the point of testing the new ConvertUtf8() logic in this PR.

Oh, the joys of the upgrader never cease. 😒

sbulen · 2025-02-03T06:55:07Z

Looks like 2 things here...

8.4 ([3.0] & [2.1]: Deprecated: Passing E_USER_ERROR to trigger_error() is deprecated since 8.4 #8402)
Different language identifiers from 2.1 to 3...

sbulen · 2025-02-03T19:45:42Z

Probably the same issues in a different form... But I attempted an install in the same environment.

This comes up after entering the DB credentials, etc. Same issues in php 8.3 & 8.4:

Warning: Undefined array key 0 in D:\wamp64\www\van2130\Sources\Db\APIs\MySQL.php on line 915

Warning: Trying to access array offset on null in D:\wamp64\www\van2130\Sources\Db\APIs\MySQL.php on line 915

Fatal error: Uncaught TypeError: SMF\Db\APIs\MySQL::detect_charset(): Return value must be of type string, null returned in D:\wamp64\www\van2130\Sources\Db\APIs\MySQL.php:934 Stack trace: 0 D:\wamp64\www\van2130\Sources\Db\APIs\MySQL.php(2195): SMF\Db\APIs\MySQL->detect_charset('messages', 'body') 1 D:\wamp64\www\van2130\Sources\Db\DatabaseApi.php(331): SMF\Db\APIs\MySQL->__construct(Array) # D:\wamp64\www\van2130\install.php(904): SMF\Db\DatabaseApi::load(Array) 3 D:\wamp64\www\van2130\install.php(172): DatabaseSettings() 4 {main} thrown in D:\wamp64\www\van2130\Sources\Db\APIs\MySQL.php on line 934

sbulen · 2025-02-03T20:35:49Z

Same errors occur in unix.

Signed-off-by: Jon Stovell <jonstovell@gmail.com>

sbulen · 2025-02-16T23:45:50Z

3.0 Install 🍻 OK
2.1 => 3.0 - a few issues....

The upgrader wouldn't run in CLI mode. No error, no nothing, immediate exit.

In browser mode, I get an error:

The upgrader could not find the "Install" language file for your selected language, . Upgrade will continue with the forum default, en_US.

If I ignore & attempt to proceed, it immediately WSOD's with:

Unknown column 'uid' in 'field list'

Signed-off-by: Jon Stovell <jonstovell@gmail.com>

Sesquipedalian · 2025-02-17T00:08:35Z

The upgrader wouldn't run in CLI mode. No error, no nothing, immediate exit.

98dab02 fixes that.

In browser mode, I get an error:

The upgrader could not find the "Install" language file for your selected language, . Upgrade will continue with the forum default, en_US.

If I ignore & attempt to proceed, it immediately WSOD's with:

Unknown column 'uid' in 'field list'

Hm. I'm not sure about that one yet. I'll look into it next.

Signed-off-by: Jon Stovell <jonstovell@gmail.com>

Sesquipedalian · 2025-02-17T01:02:01Z

Okay, @sbulen, ready for another round. All upgrader errors introduced since merging from release-3.0 have been fixed according my tests. Here's hoping that it passes your tests, too.

sbulen · 2025-02-17T02:16:34Z

MySQL 8.4, PHP 8.4.2.

3.0 install was fine.

Just attempted a 3.0 => 3.0 upgrade & got the same as before - CLI produces an mmediate exit; when run from the browser you get a "try again" link that doesn't work.

Also attempted a 2.1 => 3.0 upgrade & got this (partial log; 2.1 was in utf8mb3):

.Converting table smf_boards to utf8mb4... done.
Converting table smf_calendar to utf8mb4...
Fatal error: Uncaught ValueError: mb_convert_encoding(): Argument 3 ($from_encoding) contains invalid encoding "utf8mb3" in D:\wamp64\www\van2130\upgrade.php on line 3793

ValueError: mb_convert_encoding(): Argument 3 ($from_encoding) contains invalid encoding "utf8mb3" in D:\wamp64\www\van2130\upgrade.php on line 3793

Call Stack:
0.0078 1397320 1. {main}() D:\wamp64\www\van2130\upgrade.php:0
17.5674 8419496 2. serialize_to_json() D:\wamp64\www\van2130\upgrade.php:371
17.5674 8419496 3. ConvertUtf8() D:\wamp64\www\van2130\upgrade.php:3968
20.5053 8440984 4. mb_convert_encoding($string = '\000', $to_encoding = 'UTF-8', $from_encoding = 'utf8mb3') D:\wamp64\www\van2130\upgrade.php:3793

Sesquipedalian · 2025-02-17T04:05:36Z

Just attempted a 3.0 => 3.0 upgrade & got the same as before - CLI produces an mmediate exit; when run from the browser you get a "try again" link that doesn't work.

I cannot reproduce that. I've tried both the CLI and in browser repeatedly on an existing 3.0 database.

What output do you see if you make the following temporary change in QueryString and then try again using CLI?

Find:

	/**
	 * Checks to see if we're forcing SSL, and redirects if necessary.
	 */
	protected static function sslRedirect(): void
	{

Replace:

	/**
	 * Checks to see if we're forcing SSL, and redirects if necessary.
	 */
	protected static function sslRedirect(): void
	{
		echo $_SERVER['REQUEST_URL'] ?? 'derp';
		die();

Signed-off-by: Jon Stovell <jonstovell@gmail.com>

Sesquipedalian · 2025-02-17T04:08:38Z

ValueError: mb_convert_encoding(): Argument 3 ($from_encoding) contains invalid encoding "utf8mb3" in D:\wamp64\www\van2130\upgrade.php on line 3793

Odd. I was also testing 2.1 → 3.0 using a database in utf8mb3, and I never saw that. Still, dc702ae should fix that.

Signed-off-by: Jon Stovell <jonstovell@gmail.com>

sbulen · 2025-02-17T18:01:02Z

Hmmm... I'm still seeing this on a 2.1 => 3.0 upgrade:

...
Converting table smf_calendar to utf8mb4...
Fatal error: Uncaught ValueError: mb_convert_encoding(): Argument 3 ($from_encoding) contains invalid encoding "utf8mb4" in D:\wamp64\www\van2130\upgrade.php on line 3795

ValueError: mb_convert_encoding(): Argument 3 ($from_encoding) contains invalid encoding "utf8mb4" in D:\wamp64\www\van2130\upgrade.php on line 3795

Call Stack:
0.0078 1401488 1. {main}() D:\wamp64\www\van2130\upgrade.php:0
17.6087 8423960 2. serialize_to_json() D:\wamp64\www\van2130\upgrade.php:371
17.6087 8423960 3. ConvertUtf8() D:\wamp64\www\van2130\upgrade.php:3970
22.3724 8445480 4. mb_convert_encoding($string = '\000', $to_encoding = 'UTF-8', $from_encoding = 'utf8mb4') D:\wamp64\www\van2130\upgrade.php:3795

sbulen · 2025-02-17T18:12:04Z

I believe MySQL is still in a kind of limbo... For DB functions, I don't think we should ever use 'utf8', only 'utf8mb3' and 'utf8mb4'.

My understanding is that the very definition of 'utf8' will change. In 'older' versions of MySQL it means 'utf8mb3'. At some point it will mean 'utf8mb4'. I don't know when that cutoff will be. But the point is that, across mysql versions, utf8 is an ambiguous term.

I am running MySQL 8.4. I believe that in 8.4, 'utf8' as an alias for 'utf8mb3' is deprecated.
https://dev.mysql.com/doc/refman/8.4/en/charset-unicode-utf8.html

This kinda sorta explains that 'utf8' only appears in SHOW statements, etc:
https://www.percona.com/blog/the-power-of-utf8mb4-in-mysql-8-0-unleashing-the-full-potential-of-multilingual-data/

Signed-off-by: Jon Stovell <jonstovell@gmail.com>

Sesquipedalian · 2025-02-17T18:17:23Z

Hmmm... I'm still seeing this on a 2.1 => 3.0 upgrade:

...
Converting table smf_calendar to utf8mb4...
Fatal error: Uncaught ValueError: mb_convert_encoding(): Argument 3 ($from_encoding) contains invalid encoding "utf8mb4" in D:\wamp64\www\van2130\upgrade.php on line 3795
ValueError: mb_convert_encoding(): Argument 3 ($from_encoding) contains invalid encoding "utf8mb4" in D:\wamp64\www\van2130\upgrade.php on line 3795
Call Stack:
0.0078 1401488 1. {main}() D:\wamp64\www\van2130\upgrade.php:0
17.6087 8423960 2. serialize_to_json() D:\wamp64\www\van2130\upgrade.php:371
17.6087 8423960 3. ConvertUtf8() D:\wamp64\www\van2130\upgrade.php:3970
22.3724 8445480 4. mb_convert_encoding($string = '\000', $to_encoding = 'UTF-8', $from_encoding = 'utf8mb4') D:\wamp64\www\van2130\upgrade.php:3795

Please try b7db1fe.

I believe MySQL is still in a kind of limbo... For DB functions, I don't think we should ever use 'utf8', only 'utf8mb3' and 'utf8mb4'.

My understanding is that the very definition of 'utf8' will change. In 'older' versions of MySQL it means 'utf8mb3'. At some point it will mean 'utf8mb4'. I don't know when that cutoff will be. But the point is that, across mysql versions, utf8 is an ambiguous term.

I am running MySQL 8.4. I believe that in 8.4, 'utf8' as an alias for 'utf8mb3' is deprecated. https://dev.mysql.com/doc/refman/8.4/en/charset-unicode-utf8.html

This kinda sorta explains that 'utf8' only appears in SHOW statements, etc: https://www.percona.com/blog/the-power-of-utf8mb4-in-mysql-8-0-unleashing-the-full-potential-of-multilingual-data/

The issue we are hitting right now (and that b7db1fe should solve properly) is not with the database but rather with mb_convert_encoding(). Most of the character set names that MySQL uses are recognized by mb_convert_encoding(), but not utf8mb3 and utf8mb4.

Sesquipedalian · 2025-02-17T18:38:37Z

Actually, wait. I have an even better idea than b7db1fe.

Signed-off-by: Jon Stovell <jonstovell@gmail.com>

Sesquipedalian · 2025-02-17T18:42:49Z

Okay, 6952030 should be a better solution than b7db1fe. The reason it is better is that if $from_charset is already some variant of UTF-8 then the byte-level conversion is entirely unnecessary.

Sesquipedalian · 2025-02-17T18:44:49Z

Sorry if I'm doing that thing again where I change stuff while you are in the middle of testing. 🤪

sbulen · 2025-02-17T19:12:15Z

No prob - I was doing some reading...

Just a couple notes on the old logic, since the code doesn't look very familiar to me anymore...

The old 2.1 logic did the check & the conversion column by column, in case things choked & the user had to restart. Keep reruns/restarts in mind.
The old 2.1 logic, I believe, avoided using mb_convert_encoding because it is prone to double-encoding (do a quick search on mb_convert_encoding() & double encoding...). Doing this 100% within MySQL helped, because MySQL is simply better at conversion than php. That's why it's bounced off of binary, to force MySQL to detect the source charset - which it does very well.

The problem is some of the old MySQL versions were horrible at enforcing charsets. So, there is a lot of utf8 data stuffed into old latin1 DBs. Just running a simple utf8 conversion double-encoded everything. The bounce-it-off-of-binary approach addresses that.

Yes, I'm always kicking the posts on Chesterton's fence...

Sesquipedalian · 2025-02-18T20:26:49Z

I don't think I said this clearly above, but this is ready for another round of testing whenever you are, @sbulen.

Sesquipedalian · 2025-02-18T20:43:32Z

The old 2.1 logic did the check & the conversion column by column, in case things choked & the user had to restart. Keep reruns/restarts in mind.

I don't think that's an issue. Since database transactions are always atomic, changing the whole table at once whenever possible is actually better and safer. When we do one column at a time using the method where we change the column to a binary encoding and then back, an interruption at an inopportune moment can leave the column sitting there in a binary encoding. If anything, we should probably build more safety checks around the column-based method in the new upgrader code.

The old 2.1 logic, I believe, avoided using mb_convert_encoding because it is prone to double-encoding (do a quick search on mb_convert_encoding() & double encoding...). Doing this 100% within MySQL helped, because MySQL is simply better at conversion than php.

I don't think that's accurate. The old logic was inherited from SMF 2.0, when the mbstring extension was not required by SMF and therefore the upgrader couldn't rely on it.

Regarding double encoding, all that I found on the matter was a single StackOverflow discussion in which the original poster was trying to do something different than we are (and didn't seem to understand what they were doing very well). Perhaps your searches turned up something mine didn't, though, so if there's something more, please share the link. I am often wrong, after all, and always glad to discover a better understanding. 🙂

Signed-off-by: Jon Stovell <jonstovell@gmail.com>

Sesquipedalian · 2025-02-18T21:08:22Z

For DB functions, I don't think we should ever use 'utf8', only 'utf8mb3' and 'utf8mb4'.

I was just looking over the code again and noticed the spot that you were probably referring to; 14ea6ae should fix it.

Again, ready for testing whenever you are. 🙂

Sesquipedalian added 8 commits January 30, 2025 14:54

Use InnoDB and dynamic rows for MySQL

3a55544

Signed-off-by: Jon Stovell <jonstovell@gmail.com>

When installing, require utf8mb4 support for MySQL

9cce008

Signed-off-by: Jon Stovell <jonstovell@gmail.com>

Create tables using utf8mb4 by default for MySQL

d7c25ff

Signed-off-by: Jon Stovell <jonstovell@gmail.com>

Always use utf8mb4 input/output for MySQL

8a9edc8

Signed-off-by: Jon Stovell <jonstovell@gmail.com>

Autodetects $this->character_set and $this->mb4 in DB APIs

2957e71

Signed-off-by: Jon Stovell <jonstovell@gmail.com>

Rewrites the ConvertUtf8 upgrader step for mb4 support

4f21987

Signed-off-by: Jon Stovell <jonstovell@gmail.com>

Removes obsolete character set variables and related logic

c5e5ce9

Signed-off-by: Jon Stovell <jonstovell@gmail.com>

Moves Utils::fixUtf8Mb4() to DatabaseApi::fix_mb4()

5578ae9

Signed-off-by: Jon Stovell <jonstovell@gmail.com>

Sesquipedalian added Installer Upgrader MySQL Database Charset/Encoding UTF8 & mb4 encoding related issues Server settings labels Jan 30, 2025

Sesquipedalian added this to the 3.0 Alpha 3 milestone Jan 30, 2025

Sesquipedalian requested a review from jdarwood007 January 30, 2025 23:06

Sesquipedalian mentioned this pull request Jan 31, 2025

Mysql mb4 #6409

Closed

jdarwood007 approved these changes Feb 1, 2025

View reviewed changes

Transparently decodes entities for four-byte Unicode in Db\APIs\MySQL

a5b106f

Signed-off-by: Jon Stovell <jonstovell@gmail.com>

Merge branch 'release-3.0' into 3.0/utf8mb4

5c86307

Signed-off-by: Jon Stovell <jonstovell@gmail.com> # Conflicts: # Sources/Db/APIs/MySQL.php

Handles non-existent databases in Db::detect_charset()

28b8f46

Signed-off-by: Jon Stovell <jonstovell@gmail.com>

Only redirect to HTTPS if $_SERVER['REQUEST_URL'] starts with http://

98dab02

Signed-off-by: Jon Stovell <jonstovell@gmail.com>

Don't reconvert to utf8mb4 unnecessarily

747066a

Signed-off-by: Jon Stovell <jonstovell@gmail.com>

Sesquipedalian added 3 commits February 16, 2025 17:25

Don't get stuck waiting for conversion to utf8mb4 to complete

8e5735a

Signed-off-by: Jon Stovell <jonstovell@gmail.com>

Fixes user language lookup in upgrader

974367a

Signed-off-by: Jon Stovell <jonstovell@gmail.com>

Populates calendar table's uid column in the SQL files

e4690d3

Signed-off-by: Jon Stovell <jonstovell@gmail.com>

Sesquipedalian force-pushed the 3.0/utf8mb4 branch from 795fdda to e4690d3 Compare February 17, 2025 00:43

Sesquipedalian added 2 commits February 16, 2025 17:48

Don't get stuck waiting for ConvertToUtf8(), for real this time

9fc4a2a

Signed-off-by: Jon Stovell <jonstovell@gmail.com>

Fixes error when there are security warnings but not about files

df11e46

Signed-off-by: Jon Stovell <jonstovell@gmail.com>

Changes 'utf8mb3' to 'UTF-8' in param for mb_convert_encoding()

dc702ae

Signed-off-by: Jon Stovell <jonstovell@gmail.com>

Sesquipedalian added 2 commits February 16, 2025 21:14

Don't clobber the privacy policy when upgrading to 3.0

4eb2a2d

Signed-off-by: Jon Stovell <jonstovell@gmail.com>

Don't set spurious previousCharacterSet during 3.0 → 3.0 upgrades

acd7a9c

Signed-off-by: Jon Stovell <jonstovell@gmail.com>

Changes all utf8* variants to UTF-8 in param for mb_convert_encoding()

b7db1fe

Signed-off-by: Jon Stovell <jonstovell@gmail.com>

Don't perform byte-level conversion if already in UTF-8

6952030

Signed-off-by: Jon Stovell <jonstovell@gmail.com>

Be explicit about utf8mb3 in $charset_maps

14ea6ae

Signed-off-by: Jon Stovell <jonstovell@gmail.com>

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uses UTF8MB4 everywhere #8425

Uses UTF8MB4 everywhere #8425

Sesquipedalian commented Jan 30, 2025 •

edited

Loading

jdarwood007 commented Feb 1, 2025

sbulen commented Feb 3, 2025

Sesquipedalian commented Feb 3, 2025

sbulen commented Feb 3, 2025

sbulen commented Feb 3, 2025 •

edited

Loading

Sesquipedalian commented Feb 3, 2025

sbulen commented Feb 3, 2025

sbulen commented Feb 3, 2025 •

edited

Loading

sbulen commented Feb 3, 2025

sbulen commented Feb 16, 2025

Sesquipedalian commented Feb 17, 2025

Sesquipedalian commented Feb 17, 2025

sbulen commented Feb 17, 2025 •

edited

Loading

Sesquipedalian commented Feb 17, 2025

Sesquipedalian commented Feb 17, 2025 •

edited

Loading

sbulen commented Feb 17, 2025 •

edited

Loading

sbulen commented Feb 17, 2025 •

edited

Loading

Sesquipedalian commented Feb 17, 2025

Sesquipedalian commented Feb 17, 2025

Sesquipedalian commented Feb 17, 2025

Sesquipedalian commented Feb 17, 2025

sbulen commented Feb 17, 2025

Sesquipedalian commented Feb 18, 2025

Sesquipedalian commented Feb 18, 2025 •

edited

Loading

Sesquipedalian commented Feb 18, 2025 •

edited

Loading

Uses UTF8MB4 everywhere #8425

Are you sure you want to change the base?

Uses UTF8MB4 everywhere #8425

Conversation

Sesquipedalian commented Jan 30, 2025 • edited Loading

jdarwood007 commented Feb 1, 2025

sbulen commented Feb 3, 2025

Sesquipedalian commented Feb 3, 2025

sbulen commented Feb 3, 2025

sbulen commented Feb 3, 2025 • edited Loading

Sesquipedalian commented Feb 3, 2025

sbulen commented Feb 3, 2025

sbulen commented Feb 3, 2025 • edited Loading

sbulen commented Feb 3, 2025

sbulen commented Feb 16, 2025

Sesquipedalian commented Feb 17, 2025

Sesquipedalian commented Feb 17, 2025

sbulen commented Feb 17, 2025 • edited Loading

Sesquipedalian commented Feb 17, 2025

Sesquipedalian commented Feb 17, 2025 • edited Loading

sbulen commented Feb 17, 2025 • edited Loading

sbulen commented Feb 17, 2025 • edited Loading

Sesquipedalian commented Feb 17, 2025

Sesquipedalian commented Feb 17, 2025

Sesquipedalian commented Feb 17, 2025

Sesquipedalian commented Feb 17, 2025

sbulen commented Feb 17, 2025

Sesquipedalian commented Feb 18, 2025

Sesquipedalian commented Feb 18, 2025 • edited Loading

Sesquipedalian commented Feb 18, 2025 • edited Loading

Sesquipedalian commented Jan 30, 2025 •

edited

Loading

sbulen commented Feb 3, 2025 •

edited

Loading

sbulen commented Feb 3, 2025 •

edited

Loading

sbulen commented Feb 17, 2025 •

edited

Loading

Sesquipedalian commented Feb 17, 2025 •

edited

Loading

sbulen commented Feb 17, 2025 •

edited

Loading

sbulen commented Feb 17, 2025 •

edited

Loading

Sesquipedalian commented Feb 18, 2025 •

edited

Loading

Sesquipedalian commented Feb 18, 2025 •

edited

Loading