Page MenuHomePhabricator

SpamRegex should provide a reason in the edit form when someone submits an edit but triggers the filter (in action=submit)
Open, Needs TriagePublic


Currently, if you trigger one of the filters from a list of phrases in SpamRegex, a result will pop up that says:

The text you wanted to save was blocked by the spam filter. This is probably caused by a link to a blacklisted external site.

The following text is what triggered our spam filter:


This is ambigious, and doesn't give an exact reason. It just gives a probability: "This is probably caused by a link to a blacklisted external site." This basically says: "Hey, this is blocked because it's on the blocked list." What it doesn't say is why, which is the important question that will arise when such a thing happens during editing, that needs to be answered.

I suggest providing the whole change, which is pulled from the reason of that change in Special:SpamRegex, or displaying the full log action if and when a log gets implemented (T152164). With the whole change being showed, it provides the person who added it so that the editor can shoot up a discussion (sometimes filters aren't specific enough, and will block something off even though it shouldn't be).

This is similar to how the delete core action works: when you view an old, deleted page on a wiki, a log action from Special:Log/delete will be displayed to explain to you why that page was deleted.

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptDec 3 2016, 12:13 AM
SamanthaNguyen added a project: SpamRegex.
SamanthaNguyen moved this task from Backlog to Feedback on the SpamRegex board.
SamanthaNguyen edited subscribers, added: ashley; removed: SpamRegex.

At the very least, it should say if this was an accident, please discuss with a wiki staff member" (or something along the lines of that). This gives the user they can do, if they can't perform an edit with the word triggering the filter (and makes it less intimidating).

Aklapper removed ashley as the assignee of this task.Jun 19 2020, 4:15 PM

This task has been assigned to the same task owner for more than two years. Resetting task assignee due to inactivity, to decrease task cookie-licking and to get a slightly more realistic overview of plans. Please feel free to assign this task to yourself again if you still realistically work or plan to work on this task - it would be welcome!

For tips how to manage individual work in Phabricator (noisy notifications, lists of task, etc.), see for available options.
(For the records, two emails were sent to assignee addresses before resetting assignees. See T228575 for more info and for potential feedback. Thanks!)