I really appreciate if you can add the feature such that editing can also trigger “require approval” or suspending accounts. There is one troll in our forum who found out that he can bypass the requirement by editing, and is trolling all the time with a new account each time. I don’t think blocking some words can stop him, because he can always know which words are blocked by testing, therefore he can just change a word and then post it. During his testing, admins know nothing. I want to have some hidden list of words to trigger “require approval” even if he is just editing, and whichever user used these words by editing should be suspended immediately.
AI-generated summary
The discussion addresses a significant security gap in Discourse: the Require Approval and Silence watched word filters do not trigger on post edits, allowing spammers and trolls to bypass initial moderation by posting clean content and immediately editing it to include spam links or prohibited words. physixfan highlights how a troll exploits this to evade word blocks, while mcdanlj explains that forcing edits to go back to the approval queue for lower trust levels (TL0/TL1) is a desired feature to combat necro-bumping spam. This issue is confirmed by multiple users, including j127, bartv, and SailReal, who report active spam waves leveraging this vulnerability.
Community members discuss workarounds. bartv shares an external n8n workflow to flag edited posts containing watched words. Moin notes that while Require Approval doesn’t track edits, the Flag action does, though mcdanlj points out that watched words cannot exist in multiple categories (e.g., both Require Approval and Flag) simultaneously. Moin suggests using the Flag post on Words automation from the Discourse Automation plugin to circumvent this limitation, which mcdanlj confirms is effective without requiring a rebuild.
Regarding native solutions, RGJ and irreplaceable.span569 discuss the Discourse AI spam detection plugin, which does analyze significant edits. While some users find it resource-intensive or complex, irreplaceable.span569 reports success after correctly configuring the AI decision model to catch edit-based spam that slipped past basic watched words. The consensus is that while the lack of edit-based approval is a known limitation, combining automation plugins or AI spam detection provides viable mitigation strategies until the feature is natively supported.
This has cropped up in conversation a couple of times between me and @fzngagan recently, and we think it could be useful too. ![]()
There is the option to lock a post from further editing, and an admin setting to do that automatically after a staff edit[1], but they don’t do quite the same thing. Having the option to send edits back for re-approval feels in keeping with the protection of having the content initially approved in the first place.
However, in your case, it sounds like you could make use of some of the other existing watched word features, like flagging and silencing, to achieve some of the things you suggest. Have you checked out those options?
staff edit locks post↩︎
Yes, we have tried a lot of things. However, watched word features do not work on editing (except blocked word), so he was able to bypass those settings. Flagging (by other users) works, but usually there is a time delay, and the troll generally posts 10 replies before any user flags him.
We have spammers who necro old posts with anodyne comments and then edit with spam links. We intentionally do not close old posts because it is generally contextually legit for our purpose. We use Require Approval words to try to block common spam.
I’d love if edits went back to the queue for users below a configurable trust level.
Because watched words aren’t applied to edits, and most spammers are at TL0, we’ve had to turn off post edits for TL0. This has been a frustration for a lot of legitimate new forum users who join us looking for help with a problem. So I end up wasting a lot of time explaining why they can’t edit.
I’m looking for this feature too. At least one user has started abusing this regularly. So far nothing problematic has been posted, but now I’m not sure what might slip through.
+1 from me for applying the watched words filter to post edits. Spammers have figured this out and it’s causing harm on our forum.
Edit: In case anyone’s interested, I have set up a workflow in n8n to handle this. Whenever a post edit occurs, it fetches the list of watched words from Discourse and checks them against the new text. When it matches, it flags the post as spam, pushing it into the review queue (I couldn’t figure out which post_action_type_id I needed to flag a post as requiring approval, so
). I’m happy to share this code - DM me if you want a copy.
We would also love this feature because we’re currently hit by a spam wave as mentioned in https://meta.discourse.org/t/blocking-recent-wave-of-spam and those bots do regular create posts with random content and then edit it to the actual content to bypass the “Require for Approval” list. We added a lot of the expressions we would like to have in this list to the “Block” list but this is risky in regards to over blocking.
We’re getting an huge amount of spam doing this simple technique of creating a post and editing it afterwards to bypass the “watched words” filter.
But even worse, it looks like “watched words” filters are not applied to the post title, so I’m not sure if that is a bug.
The KiCad forums (https://forum.kicad.info/) are also getting a steady stream of edit spam like this. The exact same spam (fake customer service phone number SEO pollution) has apparently also basically killed https://neovim.discourse.group/ and is affecting a PHP forum: https://discourse.thephp.foundation/
You can see many examples of the edit being made:
I was about to suggest the spam detection of the ai plugin as that also checks edits for spam and does a great job here on Meta. Someone recently shared some impressive numbers, but I think the topic was deleted or unlisted (or I am really bad at searching today).
But I am not sure if knowing that this plugin exists or telling you about other features added in the past year to handle massive spam waves is any help to you, as it looks like the version of that forum is quite outdated (October 2023).
Short term solutions: if users’ first few posts have to go through moderation, it might stop those bots. Cloudflare’s Super Bot Fight Mode might also help.
I still have to fight this, same fake customer support number scam SEO noise. Stop Forum Spam has helped stem the tide a little bit.
The fact that it’s not applied to edits really reduces the utility of watched words.
I think the “flag” option of watched words tracks edits. At least that’s what I wrote about it a year ago
Thank you! Watched Words Reference Guide isn’t clear on the behavior for edits for many of the categories. But, unfortunately, that doesn’t help much; as far as I can tell, you can’t have the same word in two categories of watched words (at least, any time I’ve tried, the word has disappeared from the first list when I add it to the second), so anything I have in Require Approval or Silence can’t also be in Flag. So even if I wanted to do duplicate work to put words in both places, I’m out of luck, I think.
I understand that Require Approval is harder to apply to edits because it would require a whole infrastructure around approving post edits that just doesn’t exist. I think that’s the feature request here.
Hmm. Maybe you can use the Flag post on Words automation from the automation plugin for flagging edits. That could fix the problem with duplicate watched words ![]()
Thank you!
It’s now a bundled plugin, so I don’t even need to rebuild to install it to enable it!
I’m giving this a try. I haven’t moved all my hundreds of Require Approval words over yet, but I’ve added some of the most generic ones typically used recently. ![]()
I can’t add anything in terms of a solution here, but I second this observation:
Being able to send edits of TL0 (and maybe also TL1) users through the watch words filter and approval queue would increase the usefulness of said filter significantly.
We’re now also suffering from this on our discourse instance. Is there any way to raise awareness for this issue? It seems like such a simple thing to fix.
My advice is to start using AI spam detection instead. That does work on significant edits and it is much more flexible and better anyway: Discourse AI - Spam detection

