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 Mi Piace
Mi vedo potenzialmente incorrere in questo limite dall’uso di parole monitorate per combattere lo spam ripetitivo, e ho avuto alcune idee su ciò che potrebbe essere utile in futuro per altri, se non per l’OP.
Un modo per affrontare questo problema senza alcuna modifica al codice è passare a Using Regex with Watched Words e combinare molte parole in un’unica espressione regolare. È facile sbagliare se non si ha familiarità con le espressioni regolari, ma è tecnicamente fattibile. (Questa è la direzione che probabilmente prenderò, perché conosco le espressioni regolari.)
Inoltre, mi aspetterei che ci siano due modi per scrivere un plugin qui.
Il motivo del limite di 2000 è che l’algoritmo non scala molto bene e viene eseguito in modo sincrono, ma è un limite arbitrario. Mi aspetterei che un semplice plugin possa “monkey-patchare” il limite di 2000 parole per accettare il calo di prestazioni. Ma io stesso non lo farei per 10000 voci!
L’altro approccio, possibilmente complementare, sarebbe quello di avere un elenco separato specificamente per il flagging, ed eseguirlo in modo asincrono da un job di sidekiq che viene attivato per ogni creazione/modifica di post.
1 Mi Piace
Come altri, ho seguito questo percorso:
- Inizia con un elenco, magari scaricato da un repository GitHub corrente.
- Raggiungi immediatamente il limite di 2000 voci.
- Oh, posso usare le espressioni regolari - fantastico!
- Le espressioni regolari complesse superano facilmente i 100 caratteri.
- Suddividile.
- Affina un’espressione regolare, oops è andata oltre i 100 caratteri.
- Suddividila ancora di più.
Giocare con i limiti non è proibitivo, è solo fastidioso, soprattutto quando i limiti sono artificiali. Detto questo, capisco che questo filtraggio è sincrono e che un’elaborazione prolungata può creare problemi di prestazioni, e apprezzo la difficoltà di cercare di stabilire limiti che funzionino per il pubblico più ampio possibile. Quindi, anche se lotto con i limiti, non posso ragionevolmente dissentire da essi.
Vedo il codice per il filtraggio qui in word_watcher.rb. Come sviluppatore sarei felice di provare a scrivere un plugin, ma quel codice non sembra estensibile. Non avrei idea di come agganciare JavaScript in un plugin per aumentare i processi Ruby… o se ciò è possibile con il modo in cui è scritto il codice di word_watcher.
Ecco un’idea per un miglioramento per alleviare parte del carico di elaborazione di elenchi estesi.
Invece di elaborare l’intero elenco per ogni tipo di lista di controllo, considera un ciclo attraverso diversi blocchi di filtri. Ad esempio, possiamo inserire i filtri più comuni e abusivi nel blocco1 e altri nei blocchi2-n. Il processo di filtro sincrono elaborerà solo un blocco alla volta e farà un ciclo completo attraverso tutti i filtri solo all’operazione di salvataggio finale. I blocchi possono operare sugli elenchi esistenti, quindi non è necessario che nessuno apporti modifiche. Gli elenchi esistenti verranno suddivisi in blocchi da 1000 voci, quindi il blocco1 è 1-1000, il blocco2 è 1001-2000, ecc. Gli amministratori che desiderano ottimizzare possono ora scegliere di spostare i loro filtri a priorità più alta più in alto nell’elenco.
Un vantaggio di ciò è che l’intero elenco non deve essere elaborato per catturare un problema. I problemi più probabili verranno catturati con un blocco più piccolo e il processo sincrono potrà restituire prima l’elaborazione del blocco più piccolo. Certo, se il testo da monitorare non viene trovato nel primo blocco, sarà necessario elaborare un altro blocco. Ciò comporta un leggero sovraccarico aggiuntivo per catturare abusi meno probabili. Questa diventa una questione di ottimizzazione opzionale, se qualcuno mai si preoccupa di farlo.
Un’ulteriore opzione qui sarebbe che l’amministratore scelga la dimensione dei blocchi. Riducendo la dimensione dei blocchi, magari a 500 voci per ciclo di loop, ogni processo sincrono andrà più veloce, ma potrebbero esserci più blocchi da elaborare. Ciò dipende dal tipo di abuso presente e da quanto bene è prioritizzato l’elenco. Ancora una volta, questo tipo di ottimizzazione sarebbe opzionale e, francamente, dubito che molti amministratori farebbero molta ottimizzazione di questo tipo.
Nota, la messa a punto implica che abbiamo metriche quantificabili: quanto tempo stiamo impiegando nell’elaborazione delle parole da monitorare e quanti problemi stiamo effettivamente catturando? Questa quantità di dettagli nerd dovrebbe essere lasciata per un miglioramento successivo o per un plugin se è davvero desiderabile.
In definitiva, se “l’elaborazione dei blocchi di parole da monitorare” viene implementata come descritto qui, il numero di elementi nell’elenco può essere esteso oltre 2000. Sì, ci sarà un certo sovraccarico nella lettura di elenchi più lunghi e nella loro suddivisione. Ancora una volta, se abbiamo metriche su quanto tempo viene consumato in questo processo, gli amministratori possono determinare la propria soglia di ottimizzazione… ma dubito che molte persone approfondiranno questo aspetto. La linea guida pubblicata potrebbe essere qualcosa del tipo “Il limite rimane 2000 parole da monitorare senza elaborazione di blocchi di parole da monitorare. Con l’elaborazione di blocchi non c’è un limite specifico, ma il limite pratico potrebbe essere stimato intorno a 5000, con un notevole degrado delle prestazioni che aumenta all’aumentare del numero di voci”.
Qualche progresso qui?
Alla fine della giornata, se lo facciamo sul server, possiamo avere una dimensione “infinita”, dividere il post in parole, quindi un’unica query contro una tabella “block”, che nel peggiore dei casi è una scansione di 1 tabella.
Penso che se ciò di cui hai bisogno sono enormi elenchi di blocchi, consiglierei di creare un plugin personalizzato.
2 Mi Piace
Delle oltre 20 lingue e dialetti di codice che ho imparato, Ruby non è una di queste. Quindi un plugin da zero è una sfida che non credo di poter affrontare. Lo farei volentieri in un’altra lingua… o aspetterei che qualcun altro se ne occupasse. 
Grazie.
Ho appena riscontrato un problema simile a questo: Hit the blocklist limit for blocking words on the forum
Credo che questo limite potrebbe essere aumentato a 10.000 o personalizzabile a seconda di quante parole sono necessarie.