My file has 2805+ bad words, but its only allowed 2000 bad words, how can i add more words? If i want to add 10,000 bad words, from a text file, how to do it? as right now it allows me only to add max 2000 entries.
There are no plans to increase this limit at the moment. If this is a deal breaker you should look into writing, or commissioning, a plugin for it.
2 « J'aime »
Je me vois potentiellement atteindre cette limite en utilisant des mots surveillés pour combattre le spam répétitif, et j’ai eu quelques réflexions sur ce qui pourrait être utile à l’avenir pour d’autres, sinon pour l’OP.
Une façon de gérer cela sans aucun changement de code est de passer à Using Regex with Watched Words et de combiner de nombreux mots en une seule expression régulière. Il est facile de se tromper si vous n’êtes pas familier avec les expressions régulières, mais c’est techniquement faisable. (C’est la direction que je vais probablement prendre, car je connais les expressions régulières.)
De plus, je m’attendrais à ce qu’il y ait deux façons d’écrire un plugin ici.
La raison de la limite de 2000 est que l’algorithme ne s’adapte pas très bien et est exécuté de manière synchrone, mais c’est une limite arbitraire. Je m’attendrais à ce qu’un simple plugin puisse “monkey-patcher” la limite de 2000 mots pour accepter le ralentissement des performances. Mais je ne ferais pas cela pour 10000 entrées, moi-même !
L’autre approche, potentiellement complémentaire, serait d’avoir une liste séparée spécifiquement pour le signalement, et de le faire de manière asynchrone à partir d’un travail Sidekiq qui est déclenché pour chaque création/modification de message.
1 « J'aime »
Comme d’autres, j’ai suivi ce chemin :
- Commencer par une liste, peut-être téléchargée à partir d’un dépôt GitHub actuel.
- Atteindre immédiatement la limite de 2000 entrées.
- Oh, je peux utiliser les expressions régulières (Regex) - génial !
- Les expressions régulières complexes dépassent facilement 100 caractères.
- Les diviser.
- Affiner une expression régulière, oops, elle a également dépassé 100 caractères.
- La diviser encore plus.
Jouer avec les limites n’est pas prohibitif, c’est juste agaçant, surtout lorsque les limites sont artificielles. Cela dit, je comprends que ce filtrage est synchrone et que le traitement prolongé peut créer des problèmes de performance, et j’apprécie la difficulté d’établir des limites qui conviennent au plus grand public possible. Donc, même si je lutte avec les limites, je ne peux pas raisonnablement être en désaccord avec elles.
Je vois le code de filtrage ici dans word_watcher.rb. En tant que développeur, je serais heureux d’essayer d’écrire un plugin, mais ce code ne semble pas extensible. Je n’aurais aucune idée de la manière de connecter JavaScript dans un plugin pour augmenter les processus Ruby… ou si cela est possible avec la façon dont le code de word_watcher est écrit.
Voici une idée d’amélioration pour alléger le fardeau du traitement de listes étendues.
Plutôt que de traiter la liste entière pour chaque type de liste de surveillance, envisagez une boucle à travers différents blocs de filtres. Par exemple, nous pouvons placer les filtres les plus courants et abusifs dans le bloc1 et les autres dans les blocs2-n. Le processus de filtrage synchrone ne traitera qu’un seul bloc à la fois, et ne fera une boucle complète à travers tous les filtres que lors de l’opération d’enregistrement finale. Les blocs peuvent fonctionner sur des listes existantes, il n’est donc pas nécessaire que qui que ce soit apporte une modification. Les listes existantes seront divisées en blocs de 1000 entrées, donc le bloc1 est 1-1000, le bloc2 est 1001-2000, etc. Les administrateurs qui souhaitent optimiser peuvent maintenant choisir de déplacer leurs filtres prioritaires plus haut dans la liste.
Un avantage est que la liste entière n’a pas besoin d’être traitée pour détecter un problème. Les problèmes les plus probables seront détectés avec un bloc plus petit et le processus synchrone pourra se terminer plus tôt après le traitement du bloc plus petit. Bien sûr, si le texte à surveiller n’est pas trouvé dans le premier bloc, un autre bloc devra être traité. Cela représente une légère surcharge pour détecter des abus moins probables. Il s’agit d’une question de réglage optionnel - si quelqu’un s’en soucie jamais.
Une option supplémentaire serait que l’administrateur choisisse la taille des blocs. En réduisant la taille des blocs, peut-être à 500 entrées par cycle de boucle, chaque processus synchrone sera plus rapide, mais il pourrait y avoir plus de blocs à traiter. Cela dépend du type d’abus présent et de la façon dont la liste est priorisée. Encore une fois, ce type de réglage serait facultatif, et franchement, je doute que de nombreux administrateurs effectuent beaucoup de réglages de ce type.
Notez que le réglage fin implique que nous ayons des métriques quantifiables : combien de temps passons-nous dans le traitement des mots à surveiller et combien de problèmes capturons-nous réellement ? Cette quantité de détails nerdy devrait être laissée pour une amélioration ultérieure ou un plugin si c’est vraiment souhaitable.
En fin de compte, si le « traitement par blocs de mots à surveiller » est implémenté comme décrit ici, le nombre d’éléments dans la liste peut être étendu au-delà de 2000. Oui, il y aura une certaine surcharge à lire des listes plus longues et à les diviser. Encore une fois, si nous avons des métriques sur le temps consommé dans ce processus, les administrateurs peuvent déterminer leur propre seuil d’optimisation… mais je doute que beaucoup de gens s’y plongent profondément. La ligne directrice publiée pourrait être quelque chose comme « La limite reste de 2000 mots à surveiller sans traitement par blocs de mots à surveiller. Avec le traitement par blocs, il n’y a pas de limite spécifique, mais la limite pratique pourrait être estimée à environ 5000, avec une dégradation notable des performances augmentant avec le nombre d’entrées. »
Y a-t-il une chance ici ?
Au final, si nous faisons cela sur le serveur, nous pouvons avoir une taille « infinie », diviser le message en mots, puis une seule requête contre une table de « blocs », ce qui au pire est un scan de table.
Je pense que si ce dont vous avez besoin, ce sont des listes de blocs GIGANTESQUES, je recommanderais de créer un plugin personnalisé.
2 « J'aime »
Parmi les plus de 20 langages et dialectes de code que j’ai appris, Ruby n’en fait pas partie. Donc, un plugin à partir de zéro est un défi que je ne pense pas pouvoir relever. Je le ferais volontiers dans une autre langue… ou j’attendrais que quelqu’un d’autre s’en charge. 
Merci.
Je viens de rencontrer un problème similaire : Hit the blocklist limit for blocking words on the forum
Je pense que cette limite pourrait être augmentée à 10 000 ou personnalisable en fonction du nombre de mots dont vous avez besoin.