When an edit matches the spam blacklist, the following texts appear in the
message: MediaWiki:Spamprotectiontext, MediaWiki:Spamprotectionmatch with the
matching link as $1, and MediaWiki:Returnto with the Main page as $1. The last
one is wrong, and can result in lost edits. There should be a
javascript:history.go(-1) link, if any, so that the editor gets back to the text
he entered but couldn't save yet.
Version: unspecified
Severity: normal
ayg wrote:
Why doesn't the message just appear above an edit form with the entered text, as for failing to
enter an edit summary or whatnot?
robchur wrote:
(In reply to comment #2)
This might require altering how MediaWiki provides filter hooks for extensions,
but I think it would be worth it.
Shouldn't require altering, since that's already how the captcha works.
The old spam blacklist was originally meant to be as vague and mysterious as
possible so spambots would find it hard to tell what happened, but that just
annoys people.
ui2t5v002 wrote:
This is causing people to lose work. See http://en.wikipedia.org/wiki/MediaWiki_talk:Spam-whitelist#Without_warning.21
(Yes, the actual problem here is using the spam filter to block sites for editorial reasons, but that's beside the point...)
What *should* happen:
If you enter a "spam" link, and press "preview" or "save", it should just give you the normal edit window with the spam warning above it, so you can remove the offending link and continue.
Another problem that would be solved by handling spam filter hits similar to edit conflocts is when the user edits a section, and the spamlink is in another one. Even if he uses the back button, he won't be able to find the link he was warned about; the only solution is to copy his changes to a text editor, return to the article, open the whole for editing, find and remove the spam and copy the changes back from the text editor... confusing even for regular editors.
mike.lifeguard+bugs wrote:
Is there any reason this is technically difficult to implement, or is it simply that nobody has bothered?
lastword wrote:
I concur with this issue; people with poor browsers that don't keep form fields on the back button are losing work over this. Displaying the edit window would at least allow them to copy what they tried to add to a text editor and save it, if nothing else.
Why just the other day I added this
message where I mention to the poor user to use his BACK key, and then save his work elsewhere,
lest he follow the link which will appear below this, and blow away his work.
$wgFilterCallback='JidanniTitleFilter';
function JidanniTitleFilter($mTitle){
if (preg_match("/^\d/", $mTitle->getText()) && $mTitle->getNamespace() <= NS_TALK) {
EditPage::spamPage(
'***請退（"←"鍵），另存所打的字，然後見「首頁」=>「使用說明」中之「頻率編入其單位」。謝謝。***');
return true;} return false;}(In reply to comment #10)
Is there any reason this is technically difficult to implement, or is it simply
that nobody has bothered?
It's been almost a year since that comment, and noone has clarified the situation. I'm interested on that answer too, and I believe many other commenters are as well. For reference, here's another discussion about the user-unfriendliness of this behavior: [[MediaWiki talk:Spam-blacklist#We should be able to point to blocked links in talk pages]].
(In reply to comment #17)
(In reply to comment #10)
Is there any reason this is technically difficult to implement, or is it simply
that nobody has bothered?It's been almost a year since that comment, and noone has clarified the
situation. I'm interested on that answer too, and I believe many other
commenters are as well. For reference, here's another discussion about the
user-unfriendliness of this behavior: [[MediaWiki talk:Spam-blacklist#We should
be able to point to blocked links in talk pages]].
Two years now.
Another user has also reported on Portuguese Wikipedia the need of such error message during preview:
http://pt.wikipedia.org/wiki/WP:CP?oldid=23748093#Defeito.3F
This is now worse due to VisualEditor:
There should be an option not to lose the work.