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 „Gefällt mir“
Ich sehe mich potenziell mit diesem Limit konfrontiert, wenn ich beobachtete Wörter verwende, um wiederkehrenden Spam zu bekämpfen, und hatte einige Gedanken dazu, was in Zukunft für andere nützlich sein könnte, wenn nicht für den OP.
Eine Möglichkeit, dies ohne Codeänderung zu lösen, besteht darin, zu Using Regex with Watched Words zu wechseln und viele Wörter zu einem einzigen Regex zu kombinieren. Es ist leicht, Fehler zu machen, wenn man mit regulären Ausdrücken nicht vertraut ist, aber es ist technisch machbar. (Dies ist die Richtung, die ich wahrscheinlich einschlagen werde, weil ich reguläre Ausdrücke kenne.)
Zusätzlich würde ich erwarten, dass es hier zwei Möglichkeiten gibt, ein Plugin zu schreiben.
Der Grund für das 2000er-Limit ist, dass der Algorithmus nicht sehr gut skaliert und synchron ausgeführt wird, aber es ist ein willkürliches Limit. Ich würde erwarten, dass ein einfaches Plugin das 2000-Wort-Limit per Monkey-Patching ändern könnte, um die Leistungseinbußen in Kauf zu nehmen. Aber ich würde das selbst nicht für 10000 Einträge tun!
Der andere, möglicherweise ergänzende Ansatz wäre, eine separate Liste speziell für die Kennzeichnung zu haben und dies asynchron von einem Sidekiq-Job aus durchzuführen, der für jede Beitragserstellung/-bearbeitung ausgelöst wird.
1 „Gefällt mir“
Wie andere auch, bin ich diesen Weg gegangen:
- Beginne mit einer Liste, vielleicht heruntergeladen aus einem aktuellen GitHub-Repo.
- Stoße sofort auf das 2000-Einträge-Limit.
- Oh, ich kann Regex verwenden – super!
- Komplexe Regexps überschreiten leicht 100 Zeichen.
- Teile sie auf.
- Verfeinere eine Regex, oh, sie ist auch über 100 Zeichen lang geworden.
- Teile sie noch weiter auf.
Das Tanzen mit Limits ist nicht hinderlich, es ist einfach nervig, besonders wenn die Limits künstlich sind. Dennoch verstehe ich, dass diese Filterung synchron ist und dass erweiterte Verarbeitung Leistungsprobleme verursachen kann, und ich schätze die Schwierigkeit, Limits festzulegen, die für die größtmögliche Zielgruppe funktionieren. Auch wenn ich mit den Limits kämpfe, kann ich ihnen vernünftigerweise nicht widersprechen.
Ich sehe den Code für die Filterung hier in word_watcher.rb. Als Entwickler würde ich gerne versuchen, ein Plugin zu schreiben, aber dieser Code sieht nicht erweiterbar aus. Ich hätte keine Ahnung, wie man JavaScript in einem Plugin einhakt, um die Ruby-Prozesse zu erweitern … oder ob das mit der Art und Weise, wie der word_watcher-Code geschrieben ist, möglich ist.
Hier ist eine Idee für eine Verbesserung, um die Last der Verarbeitung umfangreicher Listen zu verringern.
Anstatt die gesamte Liste für jeden Typ von Watchlist zu verarbeiten, ziehen Sie eine Schleife durch verschiedene Blöcke von Filtern in Betracht. Zum Beispiel können wir die häufigsten und missbräuchlichsten Filter in Block1 und andere in Blocks2-n legen. Der synchrone Filterprozess verarbeitet nur einen Block nach dem anderen und führt nur eine vollständige Schleife durch alle Filter beim endgültigen Speichern durch. Blöcke können auf vorhandenen Listen operieren, sodass niemand eine Änderung vornehmen muss. Vorhandene Listen werden in Blöcke von 1000 Einträgen aufgeteilt, sodass Block1 1-1000, Block2 1001-2000 usw. sind. Administratoren, die optimieren möchten, können nun wählen, ihre Filter mit höherer Priorität weiter nach oben in der Liste zu verschieben.
Ein Vorteil davon ist, dass nicht die gesamte Liste verarbeitet werden muss, um ein Problem zu erkennen. Die wahrscheinlichsten Probleme werden mit einem kleineren Block erkannt und der synchrone Prozess kann früher aus der Verarbeitung des kleineren Blocks zurückkehren. Sicher, wenn der zu überwachende Text nicht im ersten Block gefunden wird, muss ein anderer Block verarbeitet werden. Das ist ein geringfügig höherer Aufwand, um weniger wahrscheinlichen Missbrauch zu erkennen. Dies wird zu einer optionalen Abstimmung – wenn sich jemand dafür interessiert.
Eine zusätzliche Option wäre, dass der Administrator wählt, wie groß die Blöcke sind. Durch die Verringerung der Blockgröße, vielleicht auf 500 Einträge pro Schleifendurchlauf, wird jeder synchrone Prozess schneller, aber es können mehr Blöcke zu verarbeiten sein. Dies hängt von der Art des Missbrauchs ab und davon, wie gut die Liste priorisiert ist. Auch diese Art der Abstimmung wäre optional, und ehrlich gesagt bezweifle ich, dass viele Administratoren so viel abstimmen würden.
Beachten Sie, dass Feinabstimmung impliziert, dass wir quantifizierbare Metriken haben: Wie viel Zeit verbringen wir mit der Verarbeitung von Watch-Wörtern und wie viele Probleme fangen wir tatsächlich ab? Diese nerdige Detailtiefe sollte einer späteren Verbesserung oder einem Plugin überlassen werden, wenn sie wirklich wünschenswert ist.
Letztendlich, wenn die “Watch-Word-Block-Verarbeitung” wie hier beschrieben implementiert wird, kann die Anzahl der Elemente in der Liste über 2000 hinaus erweitert werden. Ja, es wird einen gewissen Mehraufwand beim Lesen längerer Listen und deren Aufteilung geben. Auch hier gilt: Wenn wir Metriken darüber haben, wie viel Zeit dieser Prozess in Anspruch nimmt, können Administratoren ihre eigenen Schwellenwerte für die Optimierung festlegen … aber ich bezweifle, dass viele Leute sich damit tiefgehend beschäftigen würden. Die veröffentlichte Richtlinie könnte lauten: “Das Limit bleibt 2000 Watch-Wörter ohne Watch-Word-Block-Verarbeitung. Mit Block-Verarbeitung gibt es kein spezifisches Limit, aber das praktische Limit könnte auf etwa 5000 geschätzt werden, wobei die Leistung mit zunehmender Anzahl von Einträgen merklich abnimmt.”
Gibt es hier Fortschritte?
Letztendlich, wenn wir dies auf dem Server tun, können wir eine „unendliche“ Größe haben, den Beitrag in Wörter aufteilen und dann eine einzelne Abfrage gegen eine „Block“-Tabelle ausführen, die im schlimmsten Fall 1 Tabellenscan ist.
Ich denke, wenn Sie RIESIGE Blocklisten benötigen, würde ich empfehlen, ein benutzerdefiniertes Plugin zu erstellen.
2 „Gefällt mir“
Von den über 20 Programmiersprachen und Dialekten, die ich gelernt habe, ist Ruby keine davon. Ein Plugin von Grund auf neu zu entwickeln, ist eine Herausforderung, der ich mich meiner Meinung nach nicht gewachsen fühle. Ich würde dies gerne in einer anderen Sprache tun … oder warten, bis jemand anderes es übernimmt. 
Danke.
Ich habe gerade ein Problem wie dieses bekommen: https://meta.discourse.org/t/hit-the-blocklist-limit-for-blocking-words-on-the-forum/345199\nIch glaube, dieses Limit könnte auf 10.000 erhöht oder anpassbar gemacht werden, je nachdem, wie viele Wörter Sie benötigen.