Opened 22 months ago
Closed 10 months ago
#6964 closed defect (bug) (fixed)
Add some calming comment about spurious IMG tags from emojis leading to "links in reviews"
Reported by: |
|
Owned by: |
|
---|---|---|---|
Milestone: | Priority: | normal | |
Component: | Support Forums | Keywords: | |
Cc: |
Description
If a user adds an emoji in a "blockified" forum, then this creates some spurious IMG tags. This problem is tracked in https://github.com/Automattic/blocks-everywhere/issues/135
However, until that gets solved, we have a situation with unclear communication, as a dependency:
It would be good to add a note in the following two strings about this:
__( '<strong>Error:</strong> Please <a href="%s">do not add links to your review</a>, keep the review about your experience in text only.', 'wporg-forums' ),
__( 'Please <a href="%s">do not add links to your review</a>, keep the review about your experience in text only.', 'wporg-forums' ),
Something along the lines: "In some cases, you may get a false report of this problem if you've been using emojis in your text."
Reported in Slack by abitofmind
Change History (10)
This ticket was mentioned in Slack in #forums by tobifjellner. View the logs.
22 months ago
#8
follow-up:
↓ 9
@
22 months ago
This is a long shot as the "needs emoji replacement" detection was updated in WP 6.2 and seems most browsers/OS do not need to do that now.
Wondering if this may have something to do with the JS that replaces emojis with images, and excludes nodes with the wp-exclude-emoji
class name. The problem might be that when using the mutationObserver the class name check may miss a parent node with that class as it may not propagate far enough on the DOM tree.
Shall I try adding a patch for emoji.js
in core? Would be nice if it could be tested whether it would make any difference on the forums.
#9
in reply to:
↑ 8
@
22 months ago
Replying to azaozz:
Wondering if this may have something to do with the JS that replaces emojis with images, and excludes nodes with the
wp-exclude-emoji
class name. The problem might be that when using the mutationObserver the class name check may miss a parent node with that class as it may not propagate far enough on the DOM tree.
I was thinking that the node may have been created outside of the parent node, had emoji transformation made to it, and then moved to be a child node... but the MutationObserver not picking up the far-parent node makes a little more sense.
Shall I try adding a patch for
emoji.js
in core? Would be nice if it could be tested whether it would make any difference on the forums.
We're running the latest trunk JS files on WordPress.org, so could definitely test it for you. I'd need to figure out a way to get some stats recorded of number of times it's actually transforming SVGs back to emoji and probably figure out which browsers are affected..
In 12566: