Making WordPress.org

Opened 12 months ago

Closed 2 days ago

#6964 closed defect (bug) (fixed)

Add some calming comment about spurious IMG tags from emojis leading to "links in reviews"

Reported by: tobifjellner's profile tobifjellner Owned by: dd32's profile dd32
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:

https://meta.trac.wordpress.org/browser/sites/trunk/wordpress.org/public_html/wp-content/plugins/support-forums/inc/class-ratings-compat.php?marks=365#L365

__( '<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' ),

https://meta.trac.wordpress.org/browser/sites/trunk/wordpress.org/public_html/wp-content/plugins/support-forums/inc/class-ratings-compat.php?marks=499#L499

__( '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.


12 months ago

#2 @tobifjellner
12 months ago

  • Component changed from International Forums to Support Forums

#3 @dd32
12 months ago

  • Owner set to dd32
  • Status changed from new to accepted

#4 @dd32
12 months ago

In 12566:

Support Forums: Consider links in reviews after the content filters have been applied.

The bbPress filter used for hooking this check to doesn't offer any context of the parsed reply/topic, which causes us to look at the raw POST fields.

This applies the bbPress filter to that content, as done within the new topic bbPress handler.

See #6964.

#5 @dd32
12 months ago

In 12567:

Support Forums: Blocks: Some browsers are inserting emoji with trailing </img>, which while unexpected can be handled here easily.

See #6964.

#6 @dd32
12 months ago

In 12568:

Support Forums: Blocks: When an emoji svg fallback is copied, Guteberg sometimes removes the img.emoji class, which causes the paste to break and the existing server-side fixes to fail to correct it.

See #6964.

#7 @dd32
12 months ago

In 12569:

Support Forums: Blocks: Reverse the twemoji on both new topic/reply and edits.

It looks like the majority of the cases of img.emoji instances within the forums are on topics that have been edited, this not filtering on the edit filter seems to make sense.

See #6964.

#8 follow-up: @azaozz
12 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 @dd32
12 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..

#10 @dd32
2 days ago

  • Resolution set to fixed
  • Status changed from accepted to closed

Closing as fixed, there hasn't been any reports for a while.

Note: See TracTickets for help on using tickets.