Confirmed [Bug / UX] Smilie import shows misleading error when emoji cannot be stored due to fullUnicode being disabled

[Eris Greyrat]

Affected version

2.3.9

When fullUnicode is disabled in config.php, the database uses utf8 (3-byte) instead of utf8mb4 (4-byte), which cannot store emoji characters. When a smilie with an emoji replacement is imported, the emoji is silently stripped by the database layer, and the smilie validator then shows:

Please enter a valid emoji short-name or image URL.

This error is misleading. The field was filled correctly, but the emoji was lost before validation could see it. The user has no idea that the real cause is their charset configuration.

Steps to reproduce:​

1. Set 'fullUnicode' => false in config.php (database using utf8 charset).
2. Go to AdminCP > Content > Smilies > Import.
3. Import any smile that uses a native emoji character as its replacement for the default Smile
4. Click Import.

Expected behaviour:​

XenForo should detect that the emoji replacement field contains a 4-byte Unicode character that cannot be stored under the current charset, and display a clear, actionable error such as:

Emoji characters cannot be stored because fullUnicode is disabled in your configuration. Please choose one of the following:

1. Enable fullUnicode in config.php and convert your database to utf8mb4.
2. Replace the emoji with an image URL instead by doing one of the following:
   • Use XenForo's built-in smilie images: Enter a relative path to the default smilie sprites already included with XenForo, e.g. styles/default/xenforo/smilies/smile.png. These are located in your forum's /styles/default/xenforo/smilies/ directory.
   • Use an external image URL: Host your smilie image on any publicly accessible server and enter the full URL, e.g. https://example.com/smilies/smile.png. The image should be in PNG, GIF, or WebP format and ideally 22×22px or larger for HiDPI support.
   • Use a 2x HiDPI image: Optionally provide a second image at double resolution (e.g. 44×44px) in the 2x image replacement URL field so the smilie renders sharply on retina displays.
   • Use sprite mode: If your smilies share a single sprite sheet image, enable Sprite mode and configure the sprite dimensions and position instead of individual image URLs.
   Note: If fullUnicode is disabled, image-based smilies are the only supported replacement method. Emoji short-names such as :smile: may also be stripped depending on your database charset.

Actual behaviour:​

The emoji is silently stripped at the database layer. The validator then sees an empty emoji field and no image URL, and returns:

Please enter a valid emoji short-name or image URL.

This error would not indicate that the root cause is the fullUnicode configuration, sending the user completely in the wrong direction.

Root cause:​

• fullUnicode => false > The database charset is utf8 (3-byte max)
• Emoji characters require 4-byte encoding (utf8mb4)
• The emoji is silently stripped before it reaches the validator
• The validator sees an empty field and returns a generic, unhelpful error

Fix:​

Before or during smilie save/import, XenForo should detect whether:

• The emoji_replacement field contains a 4-byte Unicode character, and fullUnicode is false

If both conditions are true, surface a specific error explaining the charset limitation and offering the two actionable options above. This prevents user confusion and makes the platform's behaviour transparent.

Any XenForo install with fullUnicode => false (which is the default in many setups) will cause this confusing error when working with emoji-based smilies, without a clear path to resolution.