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 curtidas
Eu me vejo potencialmente atingindo esse limite ao usar palavras observadas para combater spam repetitivo e tive algumas ideias sobre o que pode ser útil no futuro para outras pessoas, se não para o OP.
Uma maneira de lidar com isso sem nenhuma alteração de código é mudar para Using Regex with Watched Words e combinar muitas palavras em uma única regex. É fácil errar se você não estiver familiarizado com expressões regulares, mas é tecnicamente viável. (Esta é a direção que provavelmente seguirei, porque conheço expressões regulares.)
Além disso, eu esperaria que houvesse duas maneiras de escrever um plugin aqui.
O motivo do limite de 2000 é que o algoritmo não escala muito bem e é executado de forma síncrona, mas é um limite arbitrário. Eu esperaria que um plugin simples pudesse “monkey-patch” o limite de 2000 palavras para aceitar o impacto no desempenho. Mas eu não faria isso para 10000 entradas!
A outra abordagem, possivelmente complementar, seria ter uma lista separada especificamente para sinalização e fazer isso de forma assíncrona a partir de um job do sidekiq que é acionado para cada criação/edição de postagem.
1 curtida
Como outros, já passei por isso:
- Comece com uma lista, talvez baixada de um repositório atual do GitHub.
- Imediatamente atinja o limite de 2000 entradas.
- Ah, posso usar Regex - incrível!
- Regex complexas facilmente ultrapassam 100 caracteres.
- Divida-as.
- Refine uma Regexp, ops, ela ultrapassou 100 caracteres também.
- Divida-a ainda mais.
Lidar com limites não é proibitivo, é apenas irritante, especialmente quando os limites são artificiais. Dito isso, entendo que essa filtragem é síncrona e que o processamento estendido pode criar problemas de desempenho, e aprecio a dificuldade de tentar estabelecer limites que funcionem para o maior público possível. Portanto, embora eu lute com os limites, não posso discordar razoavelmente deles.
Vejo o código para filtragem aqui em word_watcher.rb. Como desenvolvedor, ficaria feliz em tentar escrever um plugin, mas esse código não parece extensível. Eu não teria ideia de como conectar JavaScript em um plugin para aumentar os processos Ruby… ou se isso é possível com a forma como o código word_watcher é escrito.
Aqui está uma ideia para uma melhoria para aliviar parte do fardo de processar listas extensas.
Em vez de processar a lista inteira para cada tipo de lista de observação, considere um loop através de diferentes blocos de filtros. Por exemplo, podemos colocar os filtros mais comuns e abusivos no bloco1 e outros nos blocos2-n. O processo de filtro síncrono processará apenas um bloco por vez e fará um loop completo por todos os filtros apenas na operação Salvar final. Os blocos podem operar em listas existentes, portanto, não há necessidade de ninguém fazer uma alteração. As listas existentes serão divididas em blocos de 1000 entradas, então o bloco1 é 1-1000, o bloco2 é 1001-2000, etc. Administradores que gostariam de otimizar agora podem optar por mover seus filtros de maior prioridade mais para cima na lista.
Uma vantagem disso é que a lista inteira não precisa ser processada para capturar um problema. Os problemas mais prováveis serão capturados com um bloco menor e o processo síncrono poderá retornar mais cedo do processamento do bloco menor. Claro, se o texto de observação não for encontrado no primeiro bloco, outro bloco precisará ser processado. Isso se torna uma questão de ajuste opcional - se alguém se importar em fazer isso.
Uma opção adicional aqui seria o Administrador escolher o tamanho dos blocos. Ao reduzir o tamanho dos blocos, talvez para 500 entradas por ciclo de loop, cada processo síncrono será mais rápido, mas pode haver mais blocos para processar. Isso depende do tipo de abuso presente e de quão bem a lista é priorizada. Novamente, esse tipo de ajuste seria opcional e, francamente, duvido que muitos Administradores fariam muito ajuste como esse.
Observe que o ajuste fino implica que temos métricas quantificáveis: Quanto tempo estamos gastando no processamento de palavras de observação e quantos problemas estamos realmente capturando? Essa quantidade nerd de detalhes deve ser deixada para uma melhoria posterior ou um plugin, se for realmente desejável.
Em última análise, se o “processamento de blocos de palavras de observação” for implementado como descrito aqui, o número de itens na lista pode ser estendido além de 2000. Sim, haverá alguma sobrecarga na leitura de listas mais longas e na divisão delas. Mais uma vez, se tivermos métricas sobre quanto tempo é consumido neste processo, os Administradores podem determinar seu próprio limite para otimização… mas duvido que muitas pessoas se aprofundem nisso. A diretriz publicada pode ser algo como “O limite permanece em 2000 palavras de observação sem processamento de blocos de palavras de observação. Com o processamento de blocos, não há limite específico, mas o limite prático pode ser estimado em cerca de 5000, com degradação notável de desempenho aumentando à medida que o número de entradas aumenta.”
Algum progresso aqui?
No final do dia, se fizermos isso no servidor, podemos ter um tamanho “infinito”, dividir a postagem em palavras e, em seguida, fazer uma única consulta em uma tabela de “blocos”, que, na pior das hipóteses, é uma varredura de tabela.
Acho que, se o que você precisa são listas de blocos GIGANTES, eu recomendaria criar um plugin personalizado.
2 curtidas
Das mais de 20 linguagens e dialetos de código que aprendi, Ruby não é uma delas. Portanto, um plugin do zero é um desafio que não acredito que conseguiria assumir. Eu faria isso com prazer em outra linguagem… ou esperaria até que outra pessoa o fizesse. 
Obrigado.
Acabei de ter um problema como este: Hit the blocklist limit for blocking words on the forum
Acredito que este limite possa ser aumentado para 10.000 ou personalizável, dependendo de quantas palavras você precisa.