Jump to:
| Project: | Troll |
| Version: | 5.x-1.3 |
| Component: | User interface |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (won't fix) |
Issue Summary
Unfortunately there are lots of folks with dynamic IP addresses who might want to be using forms legitimately but who the last person who had their IP was sending out tonnes of spam with it. So, rather than providing a dead end error message like "our data submission was ignored because you are visiting from a blacklisted location." it would be beneficial to provide users with some more detail in case they would like to appeal this judgement. So about here:
41 if ($req_mod == 'notice_post_drop' && !empty($_POST)) {
42 $_POST = array();
43 drupal_set_message(t('Your data submission was ignored because you ar
e visiting from a blacklisted location. For more information see our FAQ.'));
44 }
Would be great if it were customizable so that you could send it to a FAQ like this one:
http://prax.ca/about#n5074
Btw, I am sucking in the IP address for the blocked user by doing:
<?php
echo $_SERVER['REMOTE_ADDR'];
?>We're hitting quite a few now who have been banned (but who aren't spammers).
Mike
Comments
#1
The text in the message sent in the code above is able to be changed
by you. If you are not sure about how to do that I suggest you look into
these pages:
http://drupal.org/project/stringoverrides
http://drupal.org/node/24593
#2
Yes, but wouldn't the module just be better and more user friendly if something as critical and unique as custom instructions for non-trolls who are unfortunate enough to have inherited a bad IP address were just built in? Sure I could load another couple hundred lines of code by installing yet another module, hack the module or create something funky in template.php.
But shouldn't it just be there? Is there a reason why having it be customizable in the settings would be bad?
#3
How many of the modules that you use for Drupal have the text
that is used in messages or in links or other user or admin facing
areas exposed to site administrators on settings pages? What about
the case where there are multiple languages in use? Do you then
have to deal with admin settings for text strings per language?
There is a mechanism for customizing text and for handling
multilingual sites already in Drupal and I'm simply pointing that
out. There's no need to reimplement something that is already
in place.