"review media unless trust level" setting causes reviews with emojis

On our site we use the setting review_media_unless_trust_level to review forum posts from users of a certain trust level containing images. This works great, but the filter is in my opinion too strong when it also causes a review of the posts only containing emojis and plain text.

It is very good that the review triggers on otherwise “non-image cases”, like in the case of embedded links, so keeping the filter generally very sensitive is great. But since all emojis on the site are as far as I know hosted and determined by the forum itself, I see no danger in allowing people to post whatever emojis they like. :rocket: :sunglasses:

Would it be possible to make this setting disregard posts that only contain emojis and plain text?


[Edit: I was unable to use the proper setting name in the title of this post, using underscores between the words. The forum told me that the title of the post seemed vague and with “too long words”.]


Worse, I think posts might be held for non-ASCII unicode characters — I have one that just went into my review queue and the only thing I can see that might be it is that uses and for quotes.

Well, and also ã as part of someone’s name. I hope that isn’t it!

Sorry for the belated response. I’ve just given this a run-through on my test site and I could get it to trigger on an emoji, which does seem overly sensitive. I’m not sure if they’re inextricably linked, but I’ll see what I can find out. :+1:

I couldn’t get it to trigger for quotes or an ã though. Is there something I’m missing?


Not sure – just that I had a post in the review queue where those are the only things I think it could be.

1 Like

I don’t think this can be the case, looking at:

We require that image sizes is present… sadly emojis are considered images cause they have sizes, so they get triggered.

Should be reasonably straight forward to fix, but we are going to need to introduce some internal tracking that splits off images from emojis when it is determining sizes.

Here’s my example where it happened:


(apologizies to non-staff for putting a private link in a public topic — since it contains someone’s name I am treating it as sensitive)

No it doesn’t. But what ever :wink:

Okay, yes, pedant points for you. :slight_smile: The link does not contain a name, but the linked-to content does. :slight_smile:

Oh that would be the avatar in the quote (which is hidden in your screenshot cause it could be sensitive :man_facepalming:_

Same issue, but different family. We will sort it as well. Work is queued for the upcoming 20 business days.

  • Don’t count emoji images
  • Don’t count user avatar images in quotes

Had a quick look at this and the issue seems to be from FEATURE: Review posts with media. (#10693) · discourse/discourse@f85f73b · GitHub because we’re using the imageSizes sent by the client to check for review media unless trust level.

We should instead rely on the server to do the checking and do something similar to this

Before checking for medias the user has added to their post.

I don’t know if we have access to a “nokogiri-ed” version of the cooked post in the NewPostManager though and if not, how big of a perf hit it could be :thinking:


It’s a little odd that we do this, and in the client we detect the “images” by querying the preview, which is also not ideal.

There’s room for a large refactor here, but in the meantime, we can just exclude emojis and avatars from sending their imageSizes to the payload. I checked and image sizes are not used at all for emojis and avatars, so it seems safe to do this: FIX: Don't send image sizes for emojis/avatars by pmusaraj · Pull Request #20589 · discourse/discourse · GitHub

As noted in the PR description, onebox images will also send the post to the review queue, but when this setting is enabled, that seems like a desirable side effect to me.