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