💾 Archived View for danq.me › posts › wordpress-stop-emoji-images captured on 2023-11-04 at 11:21:48. Gemini links have been rewritten to link to archived content

-=-=-=-=-=-=-

Stopping WordPress Emoji 'Images' in Feeds

2023-09-04

After sharing that Octopuns has started posting again after a 9½-year hiatus earlier today, I noticed something odd: where I'd written "I ❤️ FreshRSS", the heart emoji was huge when viewed in my favourite feed reader.

Screenshot from a web-based RSS reader application, showing recent repost "Groundhog Day". The final line contains a link with the text "I ❤️ FreshRSS", but the red heart emoji seems to be enormous compared to the next adjacent to it.

It turns out that by default, WordPress replaces emoji in its feeds (and when sending email) with images of those emoji, using the Tweemoji set, and with the alt-text set to the original emoji. These images are hosted at https://s.w.org/images/core/emoji/...-based URLs.

For example, this heart was served with the following HTML code (the number 2764 refers to the codepoint of the emoji):

<img src="https://s.w.org/images/core/emoji/14.0.0/72x72/2764.png"
     alt="❤"
   class="wp-smiley"
   style="height: 1em; max-height: 1em;"
/>

I can see why this functionality was added: what if the feed reader didn't support Unicode or didn't have a font capable of showing the appropriate emoji?

But I can also see reasons why it might not be desirable to everybody. For example:

Downloading an image will always be slower than rendering an emoji.
The code to include an image is always more-verbose than simply including an emoji.
As seen above: a feed reader which imposes a minimum size on embedded images might well render one "wrong".
It's marginally more-verbose for screen reader users to say "Image: heart emoji" than just "heart emoji", I imagine.
Serving an third-party image when a feed item is viewed has potential privacy implications that I try hard to avoid.
Replacing emoji with images is probably unnecessary for modern feed readers anyway.

I opted to remove this functionality. I briefly considered overriding the emoji_url filter (which could be used to selfhost the emoji set) but I discovered that I could just un-hook the filters that were being added in the first place.

Here's what I added to my theme's functions.php:

remove_filter( 'the_content_feed', 'wp_staticize_emoji' );
remove_filter( 'comment_text_rss', 'wp_staticize_emoji' );

That's all there is to it. Now, my feed reader shows my system's emoji instead of a huge image:

Screenshot from a web-based RSS reader application, showing recent repost "Groundhog Day". The final line contains a link with the text "I ❤️ FreshRSS" shown correctly, with a red heart emoji at the appropriate font size.

I'm always grateful to discover that a piece of WordPress functionality, whether core or in an extension, makes proper use of hooks so that its functionality can be changed, extended, or disabled. One of the single best things about the WordPress open-source ecosystem is that you almost never have to edit somebody else's code (and remember to re-edit it every time you install an update).

Want to hear about other ways I've improved WordPress's feeds?

Links

My note sharing that Octopuns has started publishing again

My blog post about my FreshRSS addiction

FreshRSS - my favourite feed reader

RSS feed for DanQ.me

Tweemoji

Compart.com page about codepoint U+2764

WordPress developer documentation for the emoji_url filter

WordPress source code on GitHub: default-filters.php, line 250, on which wp_staticize_emoji is added as a filter to the_content_feed

My blog post: "Better WordPress RSS Feeds"