Automatically Reject Comments If Website Field Filled In?

[Planet13]

To cut down on human spammers, I have removed the Website field from the comments template in my theme. so when a post loads, it just shows the name, email, and comments fields. It doesn't display a field for website.

However, spammers (I am guessing robots) are still able to submit a website URL when they submit their comments.

So is there a way to modify one of the wordpress (or theme) files so that if the website form field is filled out it will automatically redirect it so some other page?

Thanks in advance.

^{(P.S., I get enough GOOD comments from people who don't feel a need to leave their website URL that I don't feel obliged to provide that Website form field.)}

[lorax]

See: [codex.wordpress.org...]

It depends upon how your theme is setup but you could remove the URL field from the theme.

[lucy24]

So is there a way to modify one of the wordpress (or theme) files so that if the website form field is filled out it will automatically redirect it so some other page?

Tangential query: Why would you want to redirect? If your form response includes information that a human has no way to give, it can only have come from a robot. I'd be asking if the code can be modified to flat-out reject comments containing spurious fields.

:: memo to self: fine-tooth-comb own Contact forms to make sure they don't allow unwanted stuff into e-mail ::

[lorax]

>> reject comments containing spurious fields

Therein lies the issue. What constitutes a spurious field - or rather data? Akismet does a pretty good job of identifying comment spam but it's not applied to forms. You're sort of left to fend for yourself on them. And once the bots determine your form accepts their URLs, word gets out and suddenly you're inundated with spam.

While there are plenty of whitelists, blacklists, and learning apps out there, none of them are foolproof. They all have varying degrees of success. Some of it depends upon the topic of your website (some targets lend themselves to bigger bullseyes) and some of it depends upon how well your website appears to be defensible (think about survival skills - making yourself look big and scary even though you're not).

The only sure way nip the spammers is to hand check every submission (which is rather daunting). I'm not suggesting you throw your hands up in the air and give up but I honestly don't know of a better solution. Nothing that is automated will ever work very well. The best you can do is to either check the submitted data AND/OR remove the temptation altogether.

[Planet13]

Thanks for the input everyone.

Just to reiterate / clarify:

I have removed the Website input form field, so NO HUMAN USER VIEWING WITH A BROWSER WILL ENTER IN A WEBSITE ADDRESS (because the website input form field won't be displayed).

Hence, if a comment is submitted with a value for the website input field, it MUST be a bot.

That makes sense, right guys?

So I want to automatically reject anything that has a website value.

I know it won't eliminate ALL spam - and I do have akismet to catch spam, too. I just want to eliminate as much spam as possible BEFORE it gets to akismet because I check the spam comments to see if there are false positives.

Thanks in advance.

[lorax]

Got it. So bots are submitting form data to the handler even though the field does not exist on the form.

Did you remove the field using a filter? Like so:

add_filter('comment_form_default_fields', 'url_filtered');
function url_filtered($fields)
{
 if(isset($fields['url']))
 unset($fields['url']);
 return $fields;
}

You could look for the HTTP Post/Get commands that don't come from your webserver and then redirect them though I haven't thought through how best to execute this without breaking your upgrade path.

[lucy24]

What does the request look like when it passes through your server?

:: quick detour here to experiment, with unhelpful discovery that it comes through in my case as POST to the mail-handling page-- but the form fields aren't visible to the naked eye as parts of a query string ::

:: further detour to php page ::

I've got a series of lines containing
$_REQUEST["email"]
$_REQUEST["subject"]
etc. So in that format I'd check for $_REQUEST[anything-not-on-the-approved-list]. Or at least $_REQUEST[specific-bad-things-here].

It would be a ### of a lot easier if it came through as a POST request with everything in plain sight in the query string. Then you could just check the request in htaccess, before even getting near the page, and slam a 403 on anything with an unwanted parameter.

[Planet13]

@ Lorax:

"Got it. So bots are submitting form data to the handler even though the field does not exist on the form."

Yes, correct.

"Did you remove the field using a filter? "

I don't think I used a filter. If memory serves, I think I just commented out the section that displays the Website form field.

Whatever I did, I am pretty sure that it was low-tech...

"You could look for the HTTP Post/Get commands that don't come from your webserver and then redirect them though I haven't thought through how best to execute this without breaking your upgrade path."

Hmm... something to mull over. I will probably have to ask my host how to do that though... that kind of technology is way above my head.

[Planet13]

@ lucy24

You kind of lost me there... for a while I thought you had stopped writing in English...

But now I THINK I get what you are saying.

Can I ask WHICH PHP PAGE you came across the code for:

$_REQUEST["email"]
$_REQUEST["subject"]

Was it a template page or a wordpress page?

Thanks in advance.

[lucy24]

Was it a template page or a wordpress page?

Neither, unfortunately-- I'm looking at my own mail-processing form. But since I originally made it by cribbing code from, er, ahem, w3schools dot com, I'm assuming that any boilerplate code is similar. Someone who speaks php will have to step in, though; there are probably several ways of doing the same thing. In php there usually are.

Disclaimer: Obviously I don't speak WordPress. But I'm here assuming that although everything can happen with no human involvement, you've also got the option of looking at your raw php and making adjustments. If I'm mistaken on this, stop reading right here because I'll just be giving you a lot of disinformation :( In fact, moderators may want to bring out the scissors.

ONE:
The contact system I've got uses two pages. The first one has the form your users fill in. It's an html form whose crucial line looks like this:
<form name = "mailform" id = "mailform" action = "sendmail.php" method = "post">
You can look at your own contact page via View Source in your browser and see if there's anything like that. The exact names will be different, but there has to be a 'method="post"' element. Then, the second page-- the one here called sendmail.php-- contains all the _REQUEST business. That's where you look at the values of the various fields and stomp on users who give an impossible e-mail address or leave the Content area blank. In a CMS this is where the site picks between "Thanks for your input" and "Sorry, there was a problem". (At least I hope they do. Saying "Thank you for your comments. We were unable to send them" is not awfully helpful.)

TWO:
After the human user clicks Submit or Send or equivalent, their browser makes contact with the site again, using the information in the "action" line. This comes through in logs as a request to your server. If you have never looked at raw logs, it's a useful thing to learn. They are alarming at first glance, but they all follow a pattern. Your host should keep them somewhere for at least a few days.

Now at this point there may be one of two things. Logs may say simply "POST sendmail.php" (or whatever the name of the page is) or they may say "POST sendmail.php?name=something&email=somethingelse&site=blahblah" and so on.

In the second scenario, you have a lot more options, because now there are two places you can intercept the request: either on the form-processing page, or in the server before your visitor even gets to the page.

[Planet13]

Thanks for the clarification, lucy24