# Existing emoji tags appear as new in the composer; new emoji tags disappear after posting

**URL:** <https://meta.discourse.org/t/existing-emoji-tags-appear-as-new-in-the-composer-new-emoji-tags-disappear-after-posting/414846>\
**Category:** Bug\
**Tags:** emoji\
**Created:** [October 16, 2026, 6:28am UTC](https://meta.discourse.org/t/existing-emoji-tags-appear-as-new-in-the-composer-new-emoji-tags-disappear-after-posting/414846 "2026-10-16T06:28:45Z")\
**Posts on this page:** 1\
**Showing post:** 1

<div class="post-metadata">

**Author:** ![scavin](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/scavin/32/115938_2.png) [@scavin](https://meta.discourse.org/u/scavin)\
**Post date:** [October 16, 2026, 6:28am UTC](https://meta.discourse.org/t/existing-emoji-tags-appear-as-new-in-the-composer-new-emoji-tags-disappear-after-posting/414846/1 "2026-10-16T06:28:45Z")

</div>

I found inconsistent behavior with emoji tags in the topic composer and reproduced it on unmodified `main` at `802125b979b5bb848a7cfc52409ef3176ffd4d82`.

For an **existing** emoji tag, typing its name can show **Create** instead of the existing tag and its usage count. Selecting that option and posting still attaches the existing tag. A **genuinely new** emoji tag is a separate case: it can be selected in the composer, but disappears after posting.

To reproduce the existing-tag issue:

1. Use a site with an existing emoji tag, such as `😊`, and other, more frequently used tags.
2. Open the topic composer and enter the emoji tag name.
3. If that tag is outside the returned popular-tag limit, the dropdown shows a creation option and unrelated popular tags, without the existing tag’s usage count.
4. Select the creation option, publish, and refresh. The topic still uses the original tag record.

In an isolated browser test, I used an existing emoji tag with a count of 17, an unrelated tag with a count of 100, and a search limit of 1. The dropdown showed `Create: '😊'` and `popular x100`; after posting, the existing emoji tag was correctly reused. With no existing `😊` record, the same operation returned HTTP 200 but saved no tag.

The cause is in `DiscourseTagging.clean_tag`, which is used for both search terms and saving new names. It removes emoji characters. Search then falls back to popular results, while saving can still find an existing tag by its original name before cleaning new names.

I have a small patch that preserves complete emoji graphemes recognized by the existing `Emoji.unicode_replacements` data. It keeps the existing ASCII filtering and removes invalid characters from non-emoji text. It also lets disabled-tag suggestions match the start of a name, since the current word-boundary expression misses emoji-leading names such as `😊-restricted`.

The patch changes two implementation files and adds regression coverage in three test files. It does not add a database migration, frontend changes, a new API, or another emoji cache.

Local validation: 572 related backend examples and 8 browser examples passed. The browser tests check that an existing emoji tag shows `x17`, and that both it and a genuinely new `😊` remain after publishing and refreshing.

Patch branch:

> **[GitHub - scavin/discourse at fix/emoji-tag-search-and-saving](https://github.com/scavin/discourse/tree/fix/emoji-tag-search-and-saving)**
>
> fix/emoji-tag-search-and-saving

Related reports and discussion:

- [Emoji in tag names](https://meta.discourse.org/t/emoji-in-tag-names/44555)
- [Search does not seem to work for tags with emoji](https://meta.discourse.org/t/search-does-not-seem-to-work-for-tags-with-emoji/141458)
- [How to create a tag "🎥"?](https://meta.discourse.org/t/how-to-create-a-tag/337534)

These reports describe earlier emoji-tag limitations. This patch addresses the composer search and saving failures reproduced above; it does not claim to resolve every emoji-tag issue.

---

_[View the full topic](https://meta.discourse.org/t/existing-emoji-tags-appear-as-new-in-the-composer-new-emoji-tags-disappear-after-posting/414846)._