Dragging page with emoji renders HTML in page title

[eddhurst]

Describe the bug

When reordering a page that has an emoji in the title, the page title is re-rendered to include the HTML tags that represent the emoji.

Refreshing or quick editing the page allows the title to correctly rerender and hides the HTML again.

Actual:

Expected:

Steps to Reproduce

1. Save a page with an emoji in the title
2. Drag and drop re-order page
3. See the title with HTML syntax
4. Refresh page
5. See HTML syntax removed

Screenshots, screen recording, code snippet

No response

Environment information

No response

WordPress information

WP 6.5.3
Simple Page Reordering 2.7.0

Code of Conduct

• I agree to follow this project's Code of Conduct

[jamesmorrison]

Hi @eddhurst - it's been a while, hope you're doing ok!

I've reviewed this, I'm not able to replicate an issue here on WP 6.8.2 with the default theme and no other plugins active; are you still seeing this issue?

If so, please could you confirm you're using v2.7.4 and provide step-by-step instructions to replicate?

Screen.Recording.2025-07-29.at.11.02.43.mov

[eddhurst]

Hi @jamesmorrison, thanks for reaching out.

I was able to replicate this, I believe on a pure vanilla install but happy to help drill this down if I can.

Reproduction

Using Local, set up a brand new site using preferred installation, giving us WP v6.8.2

Install Simple Page Ordering v2.7.4

Go to pages, rename one of the 2 default pages to include emoji, in this instance the 👋

Grab handle and reorder pages

This results in the html snippet rendering in the title until refreshing the page.

Curious why you don't see this tbh. The only meaningful difference I can imagine is that my environment was windows but when I'm back at a mac I can try to recreate this again.

[jamesmorrison]

@eddhurst I checked this again; the first time I was using this repo on the 2.7.4 tag, this time I installed from WP.org.

However, I'm still unable to replicate this, I do not expect this is a Windows vs Mac issue but it could relate to the browser / extensions.

I've been testing in Firefox, Chrome and Safari with no extensions (except 1Password) enabled, which browser(s) are you using here and do you see the issue in all or just some?

Where you see an error, do you see anything relevant in error logs or the browser console?

Thanks, I appreciate your help here!

[eddhurst]

Further Replication:

Chrome: Version 138.0.7204.168 (Official Build) (64-bit)
Edge: Version 138.0.3351.109 (Official build) (64-bit)
Firefox: 141.0 (64-bit)

Initially running on PHP 8.2.27 then bumped to PHP 8.4.10 just to validate.

WP 6.8.2, and as you mentioned - plugin installed from Plugin Directory at v2.7.4

Console: zero errors / warning shown

---

Investigating this somewhat haphazardly because I'm just editing the transpiled plugin code to test things out, but I notice here: https://github.com/10up/simple-page-ordering/blob/develop/assets/js/src/simple-page-ordering.js#L53 that we're using dom_row_title.textContent to set the post title.

It looks like the process for getting the data is to read the post title from the DOM post_title element, which is then storing the innerHTML - in this instance that would be the following:

Hey there <img draggable="false" role="img" class="emoji" alt="👋" src="https://s.w.org/images/core/emoji/16.0.1/svg/1f44b.svg">

This is then being run through decodeEntities, which in this instance is actually doing nothing because there are no entities for it to decode. This initially felt a little like a potential cause for the bug: https://github.com/WordPress/gutenberg/blob/trunk/packages/html-entities/src/index.ts#L20 because it feels like we should have encoded the html entities before making use of them. This tickled the thought that maybe the fact that we had HTML was the problem.

Following that train of thought I realised we take the resultant page_title value including the HTML and setting it as the textContent, however this is expected to be a string: https://developer.mozilla.org/en-US/docs/Web/API/Node/textContent

If we were to use innerHTML instead this fixes the issue, albeit we probably would want a way to sanitize the title properly before re-injecting it into the page. I couldn't see a way to from the block editor packages albeit I'm less familiar with this part of WP so undoubtedly there is a way.

[jamesmorrison]

Thanks Edd, that's really helpful and you may be right about the sanitising function here, I'll look into this further.

To set expectations; I'm away for a couple of weeks from Thursday this week, I'll keep working on this - but just wanted to ensure you don't think I've forgotten this!

[ivan-ivanic-cm]

@jamesmorrison I've managed to reproduce the issue on CachyOS in Waterfox. In Google Chrome it works as expected.

[jamesmorrison]

Thank you for taking a look at this @ivan-ivanic-cm - I can also replicate this with Waterfox!

[jamesmorrison]

@eddhurst Good news! I believe I've solved this in #248, if you have a chance please could you test this (steps are noted on the PR)?

The root cause was not the decodeEntities; in some cases the emoji had already been converted to HTML before this point was reached - so I've resolved this with a regex step to set emoji back to literally the image :)

I've also updated the tests here; the setup process now creates a page with emoji and does confirm this remains unchanged after being dragged and dropped; I also see the same (working) behaviour in Waterfox which was showing the issue.