В моём файле более 2805 запрещённых слов, но разрешено только 2000. Как я могу добавить больше слов? Если я хочу добавить 10 000 запрещённых слов из текстового файла, как это сделать? Сейчас система позволяет добавлять максимум 2000 записей.
На данный момент планов по увеличению этого лимита нет. Если это является для вас критическим ограничением, стоит рассмотреть возможность написания или заказа плагина для решения этой задачи.
2 лайка
Я вижу, что потенциально могу столкнуться с этим ограничением при использовании отслеживаемых слов для борьбы с повторяющимся спамом, и у меня возникли некоторые идеи о том, что могло бы быть полезно другим в будущем, даже если не для автора оригинального поста.
Способ обойти это без изменения кода — перейти по ссылке Using Regex with Watched Words и объединить множество слов в одно регулярное выражение. Это легко сделать неправильно, если вы не знакомы с регулярными выражениями, но технически это возможно. (Я, скорее всего, выберу этот путь, так как знаком с регулярными выражениями.)
Кроме того, я предполагаю, что здесь есть два способа написать плагин.
Причина ограничения в 2000 слов заключается в том, что алгоритм плохо масштабируется и выполняется синхронно, но это произвольное ограничение. Я ожидаю, что простой плагин может изменить (monkey-patch) лимит в 2000 слов, чтобы принять удар по производительности. Но я бы сам не стал делать это для 10 000 записей!
Другой, возможно, дополнительный подход — иметь отдельный список специально для флагирования и выполнять это асинхронно через задание Sidekiq, которое запускается при создании или редактировании каждого поста.
1 лайк
Как и многие другие, я проходил этот путь:
- Начинал со списка, возможно, скачанного из текущего репозитория GitHub.
- Сразу упирался в лимит в 2000 записей.
- О, можно использовать регулярные выражения — отлично!
- Сложные регулярные выражения легко превышают 100 символов.
- Разбиваешь их на части.
- Уточняешь регулярное выражение, и о нет — оно снова вышло за 100 символов.
- Приходится разбивать его ещё мельче.
Игра с ограничениями не является запретительной мерой, она просто раздражает, особенно когда эти ограничения искусственны. Тем не менее, я понимаю, что фильтрация происходит синхронно, и расширенная обработка может создавать проблемы с производительностью. Я также ценю сложность задачи по установлению ограничений, которые подойдут максимально широкой аудитории. Поэтому, хотя мне и приходится бороться с этими ограничениями, я не могу разумно с ними не согласиться.
Я вижу код фильтрации здесь: word_watcher.rb. Как разработчик, я с радостью попытался бы написать плагин, но этот код выглядит не расширяемым. Я не представляю, как подключить JavaScript в плагине для дополнения процессов на Ruby… или вообще возможно ли это с учётом того, как написан код word_watcher.
Вот идея улучшения, которая поможет снизить нагрузку при обработке обширных списков.
Вместо обработки всего списка для каждого типа списка наблюдения, рассмотрим цикл по различным блокам фильтров. Например, самые распространённые и абьюзивные фильтры можно поместить в блок1, а остальные — в блоки2–n. Синхронный процесс фильтрации будет обрабатывать только один блок за раз и выполнять полный проход по всем фильтрам только при финальной операции «Сохранить». Блоки могут работать с существующими списками, поэтому никому не нужно что-то менять. Существующие списки будут разбиты на блоки по 1000 записей: блок1 — это записи 1–1000, блок2 — 1001–2000 и так далее. Администраторы, желающие оптимизировать процесс, смогут переместить фильтры более высокого приоритета выше в списке.
Преимущество этого подхода в том, что для обнаружения проблемы не нужно обрабатывать весь список целиком. Наиболее вероятные проблемы будут выявлены в небольшом блоке, и синхронный процесс сможет завершиться быстрее. Конечно, если «watch-text» не найден в первом блоке, потребуется обработать следующий блок. Это создаёт небольшие дополнительные накладные расходы для обнаружения менее вероятных нарушений. В итоге это становится вопросом опциональной настройки — если кто-то захочет этим заняться.
Дополнительная опция здесь — возможность для администратора выбирать размер блоков. Уменьшив размер блоков, например, до 500 записей за цикл, каждый синхронный процесс будет выполняться быстрее, но может потребоваться обработка большего количества блоков. Это зависит от типа нарушений и того, насколько хорошо список отсортирован по приоритету. Опять же, такая настройка будет опциональной, и, честно говоря, я сомневаюсь, что многие администраторы будут заниматься подобной тонкой настройкой.
Обратите внимание: тонкая настройка подразумевает наличие измеримых метрик: сколько времени мы тратим на обработку watch-word и сколько проблем мы фактически обнаруживаем? Такой детальный «ботанический» уровень анализа лучше оставить для будущего улучшения или плагина, если это действительно потребуется.
В конечном счёте, если «обработка блоков watch-word» будет реализована так, как описано здесь, количество элементов в списке можно будет увеличить за пределы 2000. Да, при чтении более длинных списков и их разбивке возникнут некоторые накладные расходы. И снова: если у нас будут метрики о времени, затрачиваемом на этот процесс, администраторы смогут сами определить свой порог оптимизации… но я всё же сомневаюсь, что многие углубятся в это так сильно. Опубликованное руководство может звучать примерно так: «Лимит остаётся 2000 слов наблюдения без обработки блоков watch-word. При использовании обработки блоков конкретного лимита нет, однако практический предел можно оценить примерно в 5000 записей, при этом производительность будет заметно снижаться по мере увеличения количества записей».
Есть ли здесь что-то, что может вызвать интерес?
В конечном счете, если мы реализуем это на сервере, мы сможем обрабатывать «бесконечный» размер: разбивать посты на слова и выполнять один запрос к таблице «блоков», что в худшем случае будет полным сканированием одной таблицы.
Я думаю, что если вам нужны ОГРОМНЫЕ списки блокировок, я бы рекомендовал создать собственный плагин.
2 лайка
Из 20+ языков и диалектов программирования, которые я изучил, Ruby в их число не входит. Поэтому создание плагина с нуля — задача, за которую я, полагаю, не смогу взяться. Я с радостью сделаю это на другом языке… или подожду, пока кто-то другой возьмётся за это. 
Спасибо.
Только что столкнулся с такой проблемой: Hit the blocklist limit for blocking words on the forum
Полагаю, этот лимит можно увеличить до 10 000 или сделать настраиваемым в зависимости от количества необходимых слов.