Emojis in plugin titles render in front of text characters

[slimndap]

If the plugin title contains an emoji, eg. myplugin❤️wordpress, the plugin name looks like this on the WordPress plugins admin page: ❤️mypluginwordpress.

This is caused by the following CSS:

.plugins .plugin-title .dashicons, .plugins .plugin-title img {
    float: left;
}

To reproduce:

1. Create myplugin❤️wordpress.php in the plugins folder.
2. Add the following header:

     <?php
     /**
      * Plugin Name: myplugin❤️wordpress
      */
   

3. Go to wp-admin/plugins.php

The plugin name is presented as ❤️mypluginwordpress.

[slimndap]

Screenshot

[audrasjb]

Thanks for reporting this.
Adding good-first-bug as this ticket would be a great opportunity for a new contributor to contribute a first patch.

[ankitkumarshah]

Hi @audrasjb and @slimndap,

I tried to replicate the issue but was not able to. I followed the following steps in both 6.7.2 and the latest trunk:

I created a plugin with file name: myplugin❤️wordpress.php and following header:

 <?php
  /**
   * Plugin Name: myplugin❤️wordpress
   */

TRUNK:

6.7.2:

Please guide me if I am doing something wrong.

[slimndap]

I am not sure how emojis inside WordPress work, but the HTML markup appears to be manipulated by javascript, after rendering the page. All emojis are replaced by an image:

 HTML
<strong>myplugin<img draggable="false" role="img" class="emoji" alt="❤️" src="https://s.w.org/images/core/emoji/15.0.3/svg/2764.svg">wordpress</strong>

I don't see this in your screenshot, where it looks like the system emoji is still used.

I am on Chrome 134 on MacOS.

[sabernhardt]

With Firefox and Chrome in Windows 11, I did not experience the floating emoji either, but it apparently can happen when the emoji script replaces the character with an image. I tried these in addition to the heart: 🐦‍🔥🙂‍↕️

The float rule is there for plugin icons in the updates table (#30186), where the icon and plugin name are inside a paragraph tag. The plugin name is inside a strong element on both admin screens. I think that restricting it with the child combinator would prevent floating emoji images in the updates table, and adding the .updates-table class could be an extra way to prevent applying those styles on other screens.

.updates-table .plugins .plugin-title p > img,
.plugins .plugin-title .dashicons

[slimndap]

Apparently, this only happens if your browser fails the emoji feature detection test, as mentioned in ticket:57301.

[debarghyabanerjee]

I attempted to replicate the issue by adding multiple emojis, but I was unable to reproduce it in my testing environment.

• MacOS: 15.3.2
• WordPress version: 6.7.2, 6.8 Beta 3
• Google Chrome Version: 134
• Firefox Version: 136

Trac ticket: #63120

## What
When a plugin title contains an emoji (e.g., myplugin❤️wordpress), the emoji incorrectly appears before the text on the WordPress plugins admin page, showing as ❤️mypluginwordpress.

[slimndap]

I am seeing this on MacOS 12.7.6, which might explain why the emoji feature detection test fails.

[ankitkumarshah]

Ok, so I manually failed the emoji feature detection test and found the issue. I also opened the PR with a fix. My current HTML after emoji feature detection test failing is:

<strong>My<img draggable="false" role="img" class="emoji" alt="😀" src="https://s.w.org/images/core/emoji/15.0.3/svg/1f600.svg">Plugin</strong>

Would really appreciate @slimndap and @sabernhardt if you could test the fix. Thank You!

[slimndap]

Yes, this fixes the issue for me.
The plugin icons in the updates table also still look fine.

[devsahadat]

I tested the proposed fix on MacOS 12.7.6 and Chrome 134, manually failing the emoji feature detection test.
The patch successfully resolves the issue, ensuring emojis in plugin titles no longer appear before the text.

Additionally, plugin icons in the updates table remain unaffected, maintaining their intended layout. ✅

[nusrat21]

Reproduced on macOS 12.7.6/Chrome 134 with forced emoji fallback (.emoji class present). Confirmed the float: left rule causes emojis to precede text in plugin titles.

Fix Validation
Tested PR #8534 across multiple environments:
Pass: Chrome 134 (macOS 12.7.6) with emoji fallback active
Pass: Firefox 136 (Windows 11) with native emoji rendering
Verified: Updates table icons remain properly aligned

Fixes #63120.

This changeset updates the plugin title styling in the WordPress Admin Plugin List Table.

• Applied white-space: nowrap, word-break: normal, and inline-flex display to .plugin-title a.
• Ensures that emojis in plugin titles render correctly without breaking text layout.
• Fixes visual misalignment issues when plugin names start with emoji characters.

Hi, I did try this PR in playground and it worked, but I tried with a classic playgournd (not including the PR) it also worked.
Are you sure this does not come from something else in your install?

Hi @ant1sg,
Thank you for testing the PR!

In your case, it seems that the system fonts are being used for rendering emojis. WordPress includes a fallback mechanism where, if the emoji feature detection test fails, emojis are loaded from ​https://s.w.org/images/core/emoji/15.0.3/svg/.

However, since your browser successfully uses system emojis, this fallback behavior isn’t triggered—hence, the issue doesn’t occur on your end.

Hello @Infinite-Null yes I just noticed all the comments on Trac, I had not seen them. Sorry about that. I'll try to rerun the test properly

[sandeepdahiya]

Patch

[sandeepdahiya]

I tried and this patch submitted in this PR ​https://github.com/WordPress/wordpress-develop/pull/8534 is working perfectly.

I tried and this patch submitted and it is working perfectly. Thanks.

[SirLouen]

Test Report

Description

✅ This report validates that the indicated patch works as expected.

Patch tested: ​https://github.com/WordPress/wordpress-develop/pull/8534.diff

Environment

• WordPress: 6.9-alpha-60093-src
• PHP: 8.2.28
• Server: nginx/1.27.5
• Database: mysqli (Server: 8.4.5 / Client: mysqlnd 8.2.28)
• Browser: Chrome 137.0.0.0
• OS: Windows 10/11
• Theme: Twenty Eleven 4.9
• MU Plugins: None activated
• Plugins:
  • Test Reports 1.2.0

Actual Results

1. ✅ Issue resolved with patch.

Additional Notes

• Why @dilip2615 has sent another ​PR8716 (that doesn't even work) when we already had PR8534 that seemed to be working? Mysteries of Trac.

[wpfy]

Reproduction Report

Description

This report validates whether the issue can be reproduced.

Environment

• WordPress: 6.9-alpha-60093-src
• PHP: 8.2.28
• Server: nginx/1.25.4
• Database: mysqli (Server: 8.0.42 / Client: mysqlnd 8.2.28)
• Browser: Chrome 137.0.0.0
• OS: macOS
• Theme: Twenty Twenty-Five 1.2
• MU Plugins: None activated
• Plugins:
  • Test Reports 1.2.0

Actual Results

1. ❌ Unable to reproduce the issue.
2. The reported behavior did not occur under the tested conditions.

Additional Notes

• I followed the exact steps provided in the ticket.

Supplemental Artifacts

Add Inline: ​https://share.cleanshot.com/KnklzsTr
​https://share.cleanshot.com/8FSVmZ5J

[hmbashar]

Test Report

Description

Hi, I tried this without any PR or changes, and it worked. Are you sure this issue does not stem from something else in your installation?

Environment

• WordPress: 6.9-alpha-60093-src
• PHP: 8.2.28
• Server: nginx/1.25.4
• Database: mysqli (Server: 8.0.41 / Client: mysqlnd 8.2.28)
• Browser: Chrome 136.0.0.0
• OS: macOS
• Theme: Hello Elementor 3.4.3
• MU Plugins: None activated
• Plugins:
  • Revix Reviews ❤️ – All-in-One Business Review Manager 1.2.3
  • Test Reports 1.2.0

[ankitkumarshah]

Hi @hmbashar 👋,

Thank you for testing,

In your case, it looks like system fonts are being used to render emojis. WordPress includes a fallback mechanism that loads emojis from ​https://s.w.org/images/core/emoji/15.0.3/svg/ when the emoji feature detection test fails.

However, since your browser is successfully rendering emojis using system fonts, the fallback isn’t triggered — which is why the issue doesn’t occur on your end.

[klevismiho]

Just tested it from my Mac and I confirm the issue is happening on WordPress: 6.8.1

This is the code it is outputting:

<strong>myplugin<img draggable="false" role="img" class="emoji" alt="❤️" src="https://s.w.org/images/core/emoji/15.1.0/svg/2764.svg">wordpress</strong>

This is the css that breaks it:

.plugins .plugin-title .dashicons,.plugins .plugin-title img {
    float: left;
    padding: 0 10px 0 0;
    width: 64px;
    height: 64px
}

On another Mac I tested, the code looks like this and it works fine.

<strong>myplugin❤️wordpress</strong>

[SirLouen]

Replying to ankitkumarshah:

Hi @hmbashar 👋,

Thank you for testing,

In your case, it looks like system fonts are being used to render emojis. WordPress includes a fallback mechanism that loads emojis from ​https://s.w.org/images/core/emoji/15.0.3/svg/ when the emoji feature detection test fails.

However, since your browser is successfully rendering emojis using system fonts, the fallback isn’t triggered — which is why the issue doesn’t occur on your end.

Do you know how the people can avoid system fonts to ha a more consistent testing instructions that can just anyone replicate?

[ankitkumarshah]

Manually Trigger WordPress Emoji Fallback

Hi everyone,

If you’d like to manually disable emoji detection and allow WordPress to use its fallback emoji rendering, you can do so by updating your session storage:

1. Open DevTools in your browser.
2. Navigate to Application > Session Storage.
3. Look for your WordPress site URL — for me it is: http://localhost:8889.
4. Under that, locate the key named wpEmojiSettingsSupports.
5. You’ll see a value like this:

   {"supportTests":{"flag":true,"emoji":true},"timestamp":1749454141039}
   

6. Update it to the following to simulate no emoji support:

   {"supportTests":{"flag":false,"emoji":false},"timestamp":1749454141039}
   

This change will trigger the fallback emoji rendering provided by WordPress.

Before:

After:

cc: @hmbashar, @wpfy, @SirLouen

[tomdevisser]

Hi everyone,

Thank you all for your hard work on this bug so far.

There are many ways to “fix” this bug, but to make the best decision, it would be helpful to first understand why the float CSS rule is applied to images here.

The given patch adds an extra class and a more specific selector, but it’s difficult to determine what might be broken without knowing the purpose of the float rule.

For example, a more specific solution like the following might be a safer and more modern approach:

- .plugins .plugin-title img
+ .plugins .plugin-title img:not(.emoji)

I’ve tested this fix using the suggested method by @ankitkumarshah (thank you!).

If someone could enlighten me about the reason this CSS rule is here in the first place, we can decide on the best fix, which might even involve deleting the img selector entirely. I’ll then upload a patch.

[sabernhardt]

it would be helpful to first understand why the float CSS rule is applied to images here.

In comment:5, I pointed to #30186, which added the float style for plugin thumbnails on the Updates screen whenever their plugins have an update available. The current patch makes the selector target only the thumbnail images on the Updates screen.

That said, .plugins .plugin-title img:not(.emoji) could fix this specific bug with emoji replacement images and is worth considering too.

I removed the version again because it could happen before 6.8. The CSS goes back to 4.9, but the earliest I could reproduce it with the emoji script was 5.0.

[tomdevisser]

Replying to sabernhardt:

In comment:5, I pointed to #30186, which added the float style for plugin thumbnails on the Updates screen whenever their plugins have an update available. The current patch makes the selector target only the thumbnail images on the Updates screen.

I apologise for missing that. Thanks for bringing it to my attention.

That said, .plugins .plugin-title img:not(.emoji) could fix this specific bug with emoji replacement images and is worth considering too.

I still believe this would be the cleaner solution, as it’s more specific to this particular bug. What are your thoughts? Do you have a preferred solution?

[sabernhardt]

1. .updates-table .plugins .plugin-title p > img tells more precisely where to apply the style (perhaps excessively precise).
2. .plugins .plugin-title img:not(.emoji) could fix the emoji bug more simply.

I am a little biased toward the first option, but I suppose a major factor in choosing that is whether another (unidentified) type of image could still get the float styles if the selector only excludes .emoji.

However, to avoid increasing the CSS specificity level, which could override some ​styles from plugins, it seems easier to add :where() to the second option:
.plugins .plugin-title img:where(:not(.emoji))

[tomdevisser]

Replying to sabernhardt:

However, to avoid increasing the CSS specificity level, which could override some ​styles from plugins, it seems easier to add :where() to the second option:
.plugins .plugin-title img:where(:not(.emoji))

Wow, I didn’t know about WP Directory! I’m glad to learn about it.

I’m happy with both options and would like to follow your decision since you have more experience as a contributor. Please let me know if you’d like me to create a new patch or if you think the current one is ready for merging!

[sandeepdahiya]

Replying to sabernhardt:

I am a little biased toward the first option, but I suppose a major factor in choosing that is whether another (unidentified) type of image could still get the float styles if the selector only excludes .emoji.

The .updates-table .plugins .plugin-title targets the update section on dashboard while on plugins page, it is .wp-list-table.plugins .plugin-title. so updating

.plugins .plugin-title img:where(:not(.emoji))

seems like a better choice to target both the fields and avoid unnecessary layout shifts.

[sandeepdahiya]

Also, the entire plugin icon behaviour started here in this Changeset 41695.

I have create a patch with the necessary changes discussed here: https://core.trac.wordpress.org/ticket/63120#comment:31

Trac ticket: https://core.trac.wordpress.org/ticket/63120

[tomdevisser]

Replying to sandeepdahiya:

The .updates-table .plugins .plugin-title targets the update section on dashboard while on plugins page, it is .wp-list-table.plugins .plugin-title. so updating

.plugins .plugin-title img:where(:not(.emoji))

seems like a better choice to target both the fields and avoid unnecessary layout shifts.

That’s a good observation. This is why I instinctively leaned towards this solution, even though I didn’t have concrete proof. Also, the PR looks great. Thanks!

#63120- Emojis in plugin titles render in front of text characters

Trac ticket: https://core.trac.wordpress.org/ticket/63120

This PR addresses Trac Ticket #63120, which reports that if the plugin title contains an emoji, eg. myplugin❤️wordpress, the plugin name looks like this on the WordPress plugins admin page: ❤️mypluginwordpress.
🔍 Steps to Reproduce:
Create a plugin with an emoji in the Plugin Name header (e.g., Plugin Name: ❤️ My Plugin).

Activate the plugin and navigate to Plugins → Installed Plugins.

Emoji in the plugin title does not render correctly — instead, a fallback character appears.

🛠️ Fix Summary:
Updates rendering logic to preserve and correctly display Unicode characters including emojis.

Ensures consistent emoji rendering across supported browsers.

✅

Tested On:
WordPress trunk (latest 6.x nightly)

Browsers: Chrome (Win), Firefox (Win)

Local environment: wp-env

[sabernhardt]

#63767 was marked as a duplicate.

This PR fixes a layout issue in the WordPress admin plugin list screen where plugin titles containing emojis are displayed incorrectly.

The current CSS rule floats all <img> elements inside .plugin-title, which unintentionally affects emojis (as some browsers render them as images). This causes the emoji to be pulled out of the text and floated to the left.

What’s Fixed
Updated the CSS selector to target only actual icons and image elements meant for layout (e.g., .dashicons, icon classes, data URIs), ensuring emoji characters remain inline with the text.

Before
Plugin title: myplugin❤️wordpress
Rendered as: ❤️mypluginwordpress

After (With Fix)
Rendered correctly as: myplugin❤️wordpress

.plugins .plugin-title .dashicons,
.plugins .plugin-title img.dashicons,
.plugins .plugin-title img[class*="icon"],
.plugins .plugin-title img[src*="data:image"] {
    float: left;
    padding: 0 10px 0 0;
    width: 64px;
    height: 64px;
}

Trac Ticket : https://core.trac.wordpress.org/ticket/63120

This change improves visual consistency for plugin authors using emojis in their titles.

[jorbin]

Removing good-first-bug since there seems to be a good-proposed solution. Thanks everyone who worked on this.

@jackgona @harshitjha1430 and amoljadhavminiorange on github: If you are going to propose an alternative solution, please make sure to include a comment here with some justification about why an existing proposal is insufficient or why an alternative approach should be considered.

​https://github.com/WordPress/wordpress-develop/pull/8960/ (the where(:not(.emoji)) proposal) is looking good to me. The only thing I want to make sure is that if this issue is also present on the plugin installation screen, this patch fixes it there as well. I'm not able to find a plugin in the directory with emoji in its title, so I've reached out to the plugin team to see if they are aware of one.

[jorbin]

Props to @threadi, ​https://wordpress.org/plugins/story-show-gallery/ is an existing plugin that has an emoji in the title. I tested on the plugin install screen ( wp-admin/plugin-install.php?s=florcz&tab=search&type=author ) and this issue is not present there either with or without the patch.

I want to give the folks who supplied the alternative patches an opportunity to speak up, so not committing this yet but planning to next week if there is no reason presented not to.

This pull request is a duplicate of earlier work in ​https://github.com/WordPress/wordpress-develop/pull/8534 so I'll close it off to avoid confusion.

I made screenshots with ​Currency Converter Widget ⚡ PRO, which has the emoji in the middle of the name. By installing an older version, it appears on the Updates screen too.

In the plugin-install.php search results, the emoji in the plugin name displays the same both before and after the patch.

Before

With patch

On the Plugins screen, the emoji image in a plugin's name floated before the patch, but it appears in the middle of the name with the patch.

Before

With patch

On the Updates screen, the plugins list also had a floating emoji image before the patch, and it likewise appears in the middle of the name with the patch. The plugin thumbnails still float, as intended.

Before

With patch

[rollybueno]

Test Report

Description

This report validates whether the indicated patch works as expected.

Patch tested: ​https://github.com/WordPress/wordpress-develop/pull/8960/

Environment

• WordPress: 6.9-alpha-60093-src
• PHP: 8.2.29
• Server: nginx/1.29.0
• Database: mysqli (Server: 8.4.6 / Client: mysqlnd 8.2.29)
• Browser: Chrome 137.0.0.0
• OS: Linux
• Theme: Twenty Twenty-Five 1.2
• MU Plugins: None activated
• Plugins:
  • Test Reports 1.2.0

Actual Results

Giving this a try as well:

1. On default, I cannot reproduce same as other folks here
2. Try following https://core.trac.wordpress.org/ticket/63120#comment:27 and you should be able to.

✅ Issue resolved with patch

Additional Notes

• I created 3 test plugins with emojis on the name, in 3 different positions:

1. Before Title Text
2. In the middle of the title
3. At the end on the title

Supplemental Artifacts

Before patch:

After patch:

I've tested the patch and validated that it works as documented.

[jamesgiroux]

I've tested the patch and validated that it works as documented.

[whyisjake]

In 60673:

Plugins: Fix emoji positioning in plugin titles on plugins list table.

Prevents emojis in plugin titles from floating to the front of text when
WordPress uses emoji fallback rendering. When emoji feature detection fails,
WordPress replaces emoji characters with <img> elements that were incorrectly
affected by CSS float rules intended for plugin icons.

Updates CSS selectors to target specific icon types (dashicons, icon classes,
and data URI images) rather than all images, ensuring emoji images remain
inline with plugin title text while preserving proper layout for actual
plugin icons.

• Consolidates .plugins .plugin-title img and .plugins .plugin-title .dashicons rules
• Adds support for img.dashicons, img[class*="icon"], and img[src*="data:image"] selectors
• Maintains 64px sizing and left float for legitimate plugin icons
• Fixes visual issue where "myplugin❤️wordpress" displayed as "❤️mypluginwordpress"

Props slimndap, ankitkumarshah, sandeepdahiya, sabernhardt, tomdevisser,
debarghyabanerjee, nusrat21, SirLouen, wpfy, hmbashar, klevismiho,
rollybueno, jamesgiroux, jorbin, whyisjake.

Fixes #63120.

[sabernhardt]

Reopening to revert [60673] and then revisit committing PR 8960.

Most plugin images on the Updates screen do not have a class or a data URL, so the changes in PR 8931 did not apply the float and dimensions correctly.

[helen]

63120.2.diff​ is a little bit of a different approach and I think more correct - I'd like to avoid less-performant complex selectors like not() and partial matches if we don't have to use them, and since we can add a class we should do that. So this adds the plugin-icon class to those images which will be helpful semantically anyway, and updates the existing plugin-icon styles to be specific to plugin-card (install screen).

[helen]

In 60680:

Plugins: Ensure only plugin icons are floated.

There's no reason not to add a semantic class to the plugin icons on the update screen instead of making our CSS more complex, so let's do that and ensure that the existing .plugin-icon styles are scoped to .plugin-card on the install screen.

Partially reverts [60673].
Fixes #63120.

[matt]

At no point did anyone ask if we should even allow emojis in plugin names; it seems like a rabbit hole. There are overton windows for charsets, and opening them could inject a lot of data we don't want to deal with.

[sabernhardt]

I still want a full revert, even though it is more difficult now with two commits. The theme screenshots do not float anymore on the Updates screen, and continuing to patch the changes would be a rabbit hole.

[helen]

Replying to matt:

At no point did anyone ask if we should even allow emojis in plugin names

I did verbally at contributor day without yet coming back to the ticket; in the moment felt it more important to fix the breakage since it exists. I would agree that emoji in plugin titles are unnecessary but don't have opinions on whether they should be fully disallowed - IMO would be good to do some due diligence on how often that's been done so far, and identification of what problems are or could happen because of them (slugs, injection, etc.). Perhaps somebody would like to take on opening something like a meta.trac ticket for this?

@sabernhardt I disagree that this is a rabbit hole, theme screenshot positioning is a low effort repair and that breakage is a symptom of the real problem going on here: that we let theme updates inherit from plugin update styling. We should fix it regardless and I will, it is perfectly fine to have fast-follow fixes even when we strive not to have to do them often.

[helen]

In 60683:

Updates: Ensure theme screenshots are positioned correctly.

Underlying problem: the updates list tables inherit styles from classes named for plugins. This makes the intention much more explicit so we can actually maintain and make changes sanely going forward.

Fixes #63120.

[jorbin]

Reopening since the owner can't be changed on closed tickets.

[sabernhardt]

I'll attach before and after screenshots to show that both the plugin icon and emoji images display correctly in trunk.

• Before screenshots use 6.8.2.
• After screenshots use trunk as of [60690].
• The Updates page screenshots show plugin icons in multiple file types (annotated in the RTL screenshots):
  • SVG
  • PNG
  • JPEG
  • <canvas>, replacing the GIF because I turned off animations in Windows
• Similarly, the Updates page screenshots show theme thumbnail images for both JPEG and PNG file types.
• The Plugins listing screenshots demonstrate that the emoji image does not float anymore.
• The Add Plugins page displays the plugin icons the same way before and after the changes.

Also, some plugins should update their styles to account for the repurposed .plugin-icon class or the increased specificity, though the impact seems small.

• ​plugin directory search results
• ​spreadsheet of notes

[sabernhardt]

Updates page: before

[sabernhardt]

Updates page: after

[sabernhardt]

Updates page (RTL direction): before, identifying file types

[sabernhardt]

Updates page (RTL direction): after, identifying file types

[sabernhardt]

Plugins listing page: before

[sabernhardt]

Plugins listing page: after

[sabernhardt]

Plugins listing page (RTL direction): before

[sabernhardt]

Plugins listing page (RTL direction): after

[sabernhardt]

Add Plugin page: before

[sabernhardt]

Add Plugin page: after

[sabernhardt]

Add Plugin page (RTL direction): before

[sabernhardt]

Add Plugin page (RTL direction): after

Closing as merged (60680)https://core.trac.wordpress.org/changeset/60680