The way the PHP solution works is that it works as an intermediary between your website and Salesforce’s web to lead process. It takes in the data, checks if its spam and then sends the data onto Salesforce as if you had that checkbox set in the first place. Any other activity in your system does not run through the process. It is then up to you to handle what you want to do with the spam. Personally, I route it to a “Spam” queue, check it out and delete it if it’s real spam.

The way my updated, native force.com solution works is similar. You have a Sites page that acts as an intermediary. The same concept applies about you routing it where you need it to go. The additional piece of the new app (called Spam Check) is that it also includes Apex methods that allow you to do a spam evaluation in your own code. Thus, you could add a trigger to any object that checks if it’s spam and do what you want to with the results.

If I didn’t answer your question well here and it requires a more detailed conversation, submit your contact info here and we can talk.

The problem I’m having seems to be with the custom field. I set up “Marked as Spam” to be checked by default, assuming the scripts would deselect the checkbox for all valid forms I pass through it. This is working great for my test form. Spammy submissions mark the field checked, non-spammy submissions deselect the checkbox. The issue is that the spam isn’t passing through the scripts — it’s going to SFDC directly. Although I set up the custom field to be checked by default, spam leads entered through the API seem to ignore this field.

Is there a way to make a custom field required by default? Any other ideas?

Many thanks for your effort to help the SFDC community!

I am not sure. What I’d do is create a simple page to catch the post and review what’s contained in the $_POST data for that field.

You might also want to check out the Spam Check app on AppExchange. It’s been rewritten in Visualforce so it all runs on the platform.

I would like that too and I suppose its possible. The part that uses fopen is the adapter written by another developer for the Akismet community. I doubt I’d have much pull to ask him to update it, but it’d be nice if he did since many PHP installs have turned off their file functions. The alternative would be for us/you to modify the adapter itself. My gut says it wouldn’t be too hard, but I haven’t investigated it too much.

Is there any way you could tweak your code so that it uses a adapter that doesn’t require fopen, but uses curl?

Of course, if it’s much work, I’d understand if the answer is no!