We could simply convert the utf8 encoding to utf8mb4 like was done with utf8 in Tiki, but there is a slight performance penalty when using utf8mb4 over utf8.
One must also take into consideration that information stored in MySQL is stored in multibyte variable format, (when varchar is used) but not when char is, so chars (currently taking 3bytes) will need 4 under utf8mb4. Using ascii encoding only requires one byte. It might be a good idea if we start choosing encoding in Tiki based on the need for basic text (ascii) multi language (utf8) and emoji support (utf8mb4), that would ensure the smallest and fastest database footprint. -drsassafras
In preparation for using this encoding, and also for good general database practices, we should cut down on the log indexes that occasionally occur. These were likely introduced by mistake by coders who didn't understand the optimal size of MySQL indexes anyhow. Index are not stored in variable encoding, so the addition of an extra byte per character in converted utf8mb4 encoding could (and does in a few places) exceed MySQL maximum index size. -drsassafras
Another barrier to implementation is that utf8mb4 is supported from MySQL 5.5.3 (early 2010) . Right now our current minimum MySQL version is 5.0. The easiest way to deal with this is likely to bump the minimum version number to 5.5.3. Almost all MySQL servers are at least this version at this point, I'm relatively sure. Might need to change the MySQL version checks etc. -drsassafras
drsassafras: Post-LTS versions are a great time to bump requirements. Just after Tiki 18 LTS is released, we can do so, and everyone who can't yet follow can stay on Tiki18 LTS for 5 years. See Versions. I think we should move to PHP7.1 or 7.2 as well.