Moetwemoji: Lightweight Animated Emojis (AVIF) - Bring your forum to life

PixPin_2026-01-04_22-04-17

Hi everyone! :waving_hand:

I created a new plugin to bring more energy and dynamic expressions to Discourse communities. Moetwemoji introduces a set of animated emojis that make interactions more lively and fun.

:rocket: Key Features

  • Super Lightweight: All emojis are encoded in AVIF format.

  • High Performance: The average file size is only around 10KB, ensuring your forum loads fast while looking great.

  • Flexible Deployment: I offer two different versions depending on your needs (Override or Supplement).


:package: Choose Your Version

I have prepared two separate repositories depending on how you want to integrate these emojis into your forum.

Option 1: The Override Version (Total Replacement)

If you want to completely replace the default static Twemoji set with these animated ones, use this version. It overrides the system defaults, making the animation the standard experience.

Option 2: The Pack Version (Supplement)

If you prefer to keep the standard emojis and simply add these as an extra ā€œPackā€ in the emoji picker, use this version. It adds a new tab to your emoji selector without touching the defaults.


16 Likes

Thanks for sharing :+1:

I wanted to test it but it doesn’t work despite adding the repository in the app.yaml file

Is there a setting to configure?

Thanks

OK please try Manual Install

Manual Installation Guide (Override Version)

This guide explains how to manually install and apply the
discourse-moetwemoji-twemoji-fakepng-override plugin inside a running Discourse container, and clarifies why a full rebuild is not strictly required for the override version.


1. Enter the Discourse Container

On your server, go to the Discourse Docker directory (usually /var/discourse) and enter the running container:

cd /var/discourse
./launcher enter app

You should now be inside the container shell.


2. Clone the Override Plugin Manually

Navigate to the plugins directory and clone the repository:

cd /var/www/discourse/plugins
git clone https://github.com/constansino/discourse-moetwemoji-twemoji-fakepng-override.git

Verify that the directory exists:

ls discourse-moetwemoji-twemoji-fakepng-override


3. Apply the Emoji Override

Go back to the Discourse root directory:

su - discourse
cd /var/www/discourse

Check the current status (optional but recommended):

RAILS_ENV=production bundle exec rake moetwemoji_twemoji:status

Apply the override:

RAILS_ENV=production bundle exec rake moetwemoji_twemoji:apply

If the command finishes without errors, the Twemoji PNG files have been replaced by Moetwemoji.


4. Important Notes About Rebuilds (Persistence)

:red_exclamation_mark: No rebuild is required to make the override work

This override version works by directly replacing files in the running container.
Therefore:

  • :white_check_mark: You do NOT need to run ./launcher rebuild app

  • :white_check_mark: Changes take effect immediately after running the rake task

:warning: But the change is NOT persistent

Because this is done inside the container filesystem:

  • Any future ./launcher rebuild app

  • Or container recreation / upgrade

will wipe the changes, and the emoji override will be lost.

:backhand_index_pointing_right: If you need persistence across rebuilds, you must install the plugin via app.yml hooks and rebuild properly.


5. Clear CDN and Browser Cache (Very Important)

After applying the override, emoji may still appear unchanged due to caching.

5.1 Clear CDN Cache (e.g. Cloudflare)

If you are using a CDN such as Cloudflare:

  • Purge cache for:

    • /images/emoji/*

    • or perform a full cache purge if necessary

Otherwise, the old Twemoji PNG files may still be served.

5.2 Clear Browser Cache

On the client side:

  • Hard refresh the page (Ctrl + F5 / Cmd + Shift + R)

  • Or clear browser cache

  • Or test in an incognito/private window

Until both CDN and browser caches are cleared, emoji changes may not be visible.


6. Summary

  • This override plugin can be installed and applied without rebuilding

  • Manual installation is useful for:

    • Testing

    • Temporary usage

    • Debugging

  • The downside is lack of persistence

  • Always clear CDN cache + browser cache after applying emoji overrides


Did you run the task as described in the README?

This README provides two installation methods:

  1. The first method requires a rebuild.
  2. The second method is to manually enter the container and download it from GitHub.

There’s no difference between the two methods; the former is simply more persistent. If the download fails when rebuilding using the first method, consider trying the second method, which involves directly installing within the container. This is because it essentially downloads and replaces existing emoji images.

I noticed that the Readme explains 2 installation methods, but it also mentions:

cd /var/discourse
./launcher enter app

su - discourse
cd /var/www/discourse

RAILS_ENV=production bundle exec rake moetwemoji_twemoji:status
RAILS_ENV=production bundle exec rake moetwemoji_twemoji:apply

which is not mentioned in the first post here on Meta. Just like the information about caching. That’s why I thought someone might miss that.


By the way, both of your links in the first post contain a Google search. Is there a reason why you did not link to GitHub directly?

1 Like

Why is it called ā€œmoetwemojiā€, and the emoji folder called ā€œtwemojiā€ when the animated emojis are official animated Google Noto emojis?

This is however mentioned in this file, where the attribution is incomplete. The file is said to be work in progress but I’d expect an attribution to be complete before distributing your theme component :face_with_tongue:

4 Likes

Sorry, my post may not have been comprehensive enough. I will revise it later. Thank you for your correction.

2 Likes

Thanks for pointing this out — you’re absolutely right.

The naming is historical and comes from Discourse’s default emoji
structure, but the actual animated assets are from Google Noto Emoji,
not Twemoji. I agree this is confusing and needs to be clarified.

I’m currently:

  • Updating the attribution to fully comply with the Noto Emoji license
  • Clarifying the asset source in the README
  • Reviewing naming / folder structure to reduce confusion

Thanks for the review and for catching this.

2 Likes

I will wait because despite the manipulations it does not work, however my Discourse is on a standalone server on my Ubuntu server. I don’t know if I have an extra manipulation to do concerning the cache?

just try
https://ā€œyourdomainā€/images/emoji/twemoji/hugs.png?v=15

and

https://ā€œyourdomainā€/images/emoji/twemoji/hugs.png?v=15&cache=0

Both urls give very stable and motionless emoji. So, based of that I don’t see any reasons install this. A device question?

I think those links are for testing the plugin after installing it. As long as you don’t use the plugin, you are going to see the emoji which the plugin would replace.

I actually installed it, and I don’t see anything. Perhaps I should use another emojies on Discourse settings or something else, I don’t know [1]


  1. plus I personally think moving elements are echoes from 90’s :squinting_face_with_tongue: So I’m not so motivated to start dig this deeper. ā†©ļøŽ

Sorry, because you said you don’t see a reason to install it, I assumed you did not.

Did you run the rake task that is explained in the readme of the plugin’s repo? I think that’s what puts the animated emoji where you tried to access them with the links

1 Like

My bad. I’m on phone and I was/am lazy to write then.

No, I didn’t do.

Edit.

I never red the readme, because OP offers only (useless) link to google search. Now I did extra steps to original repo to find info that should or could be in OP.

1 Like

I can see the animated emojis with ā€œhttps://ā€œyour_domainā€/images/emoji/twemoji/hugs.png?v=15ā€ but when I try to select an emoji in the chat, for example, it doesn’t work :thinking:

To reduce complexity I recommend you remove everything related to not rebuilding and entering the container to clone. This is unnecessary and not the standard way to manage plugins.

Almost all admins will be rebuilding periodically and persistence is the most important aspect, so the app.yml method is best.

You can also link to standard instructions and just detail steps that are unique.

3 Likes