Sur notre site, nous utilisons le paramètre review_media_unless_trust_level pour examiner les publications du forum des utilisateurs d’un certain niveau de confiance contenant des images. Cela fonctionne très bien, mais le filtre est à mon avis trop strict car il provoque également un examen des publications ne contenant que des emojis et du texte brut.
Il est très bien que le filtre se déclenche dans des cas autrement « non liés aux images », comme dans le cas des liens intégrés, il est donc formidable de garder le filtre généralement très sensible. Mais comme tous les emojis sur le site sont, à ma connaissance, hébergés et déterminés par le forum lui-même, je ne vois aucun danger à permettre aux gens de publier les emojis qu’ils aiment.
Serait-il possible de faire en sorte que ce paramètre ignore les publications ne contenant que des emojis et du texte brut ?
[Edit : Je n’ai pas pu utiliser le nom correct du paramètre dans le titre de cette publication, utilisant des underscores entre les mots. Le forum m’a dit que le titre de la publication semblait vague et avec des « mots trop longs ».]
Pire, je pense que les publications pourraient être retenues pour des caractères unicode non-ASCII — j’en ai une qui vient d’entrer dans ma file d’attente de révision et la seule chose que je puisse voir qui pourrait être la cause est l’utilisation de “ et ” pour les guillemets.
Eh bien, et aussi ã dans le cadre du nom de quelqu’un. J’espère que ce n’est pas ça !
Désolé pour ma réponse tardive. Je viens de tester cela sur mon site de test et j’ai pu le déclencher sur un emoji, ce qui semble en effet trop sensible. Je ne sais pas s’ils sont inextricablement liés, mais je vais voir ce que je peux découvrir.
Cependant, je n’ai pas pu le déclencher pour des guillemets ou un ã. Y a-t-il quelque chose qui m’échappe ?
Je ne pense pas que ce puisse être le cas, en regardant :
Nous exigeons que la taille de l’image soit présente… malheureusement, les emojis sont considérés comme des images car ils ont des tailles, donc ils sont déclenchés.
Cela devrait être relativement simple à corriger, mais nous allons devoir introduire un suivi interne qui sépare les images des emojis lorsqu’il détermine les tailles.
(excuses auprès des non-membres du personnel pour avoir mis un lien privé dans un sujet public — comme il contient le nom de quelqu’un, je le traite comme sensible)
Ce serait donc l’avatar dans la citation (qui est caché dans votre capture d’écran car il pourrait être sensible _
Même problème, mais une famille différente. Nous allons également le résoudre. Le travail est en file d’attente pour les 20 prochains jours ouvrables.
Ne pas compter les images d’emoji
Ne pas compter les images d’avatar d’utilisateur dans les citations
Nous devrions plutôt nous fier au serveur pour effectuer la vérification et faire quelque chose de similaire à ceci :
Avant de vérifier les médias que l’utilisateur a ajoutés à son message.
Je ne sais pas si nous avons accès à une version « nokogiri-ée » du message cuit dans le NewPostManager et, si ce n’est pas le cas, quel pourrait être l’impact sur les performances
Il y a de la place pour une refonte majeure ici, mais en attendant, nous pouvons simplement exclure les emojis et les avatars de l’envoi de leurs imageSizes à la charge utile. J’ai vérifié et les tailles d’image ne sont pas du tout utilisées pour les emojis et les avatars, donc cela semble sûr de le faire : FIX: Don't send image sizes for emojis/avatars by pmusaraj · Pull Request #20589 · discourse/discourse · GitHub
Comme indiqué dans la description du PR, les images onebox enverront également le message à la file d’attente de révision, mais lorsque ce paramètre est activé, cela semble être un effet secondaire souhaitable pour moi.
Le lien ne contient pas de nom, mais le contenu lié en contient un. 
_