Integration with trackback.module

I'm almost certain this won't work, but it's something to work with/from, no? :)

I'm not sure what the difference is with Trackback's 'receive' and 'insert' $ops, and I have no idea what is contained in $trackback.

Oops. Missed a semi colon. :x

any chance for a 5.x version?!?!?!?! :)

@allen074: I'm mostly interested in a 6.x version, but once that is set, it shouldn't be too hard to backport it to 5.x (assuming trackback works the same in its 5.x branch). However, 6.x should be done first, so if you want to see this done for 5.x - please help me with 6.x.

i wish i could help you freso - my coding is not that great :(

@allen074: Well, you could test the patch and tell me if it works. :) The handbook has an excellent page on applying patches. If you already have a site with both Trackback and Mollom that receives a lot of trackback spam, it should be quite easy to tell whether this patch makes Mollom check the Trackbacks. :)

I don't know a thing about the trackback module, but I wonder how this patch is supposed to work:

Haha. You're right. But then, as I said: I'd be surprised if the patch works. I'll try and look into this, but I'm wary of just hacking in the blind (as I'll need two trackback enabled sites, where one of them will have to talk with Mollom - possibly corrupting data). Say, there's not a way to access a Mollom server (or a cluster or whatever) that doesn't share its data with the actual Mollom database?

Also, if you have any hints of which code in the Mollom module I need to look at or anything else, please let me know. I'll get back to this ASAP. (I'd also wish the Trackback module people would chime in here, but no luck so far.)

This is a golden opportunity for Mollom. About two years ago a patch appeared for trackback (in 4.7) that allowed akismet to filter trackbacks. Those who installed it were in heaven.

When Drupal 5.x came along, those of us who upgraded Drupal mostly ended up disabling trackback, because the patch was not incorporated into the next version, and none of the alternatives could hold a candle to the kind of automatic, smart filtering we had experienced with akismet.

There have been multiple feature requests going on now for over a year, both at akismet and trackback, requesting that one or the other reintroduce this capability, and neither module appears to have any interest.

If Mollom were able to filter trackbacks in Drupal, there would be many sites ready to implement it, so we could use trackback again.

I would be delighted to help test a patch, after it got to the stage where it was reasonably safe. Since my site is a working site, I can't risk corrupting data, etc. But once that risk is past, count me in.

Ken Watts

the daily mull

So, normally when a Trackback is submitted/made, the only user interaction there is, is the actual creation of the content that triggers the Trackback... right? If so, it'd be pretty hard to insert a CAPTCHA into the process. So I'm thinking, instead of a CAPTCHA, put it into moderation queue. Ie., if it is marked "spam", delete the Trackback on the spot; if it is marked "ham", save it and publicise it; if it is marked "unsure", put it in the moderation queue, and the site admin/moderator can mark it spam/ham (which will then also educate Mollom).

I know Mollom is supposed to remove the moderation queues, but if there is no user interaction for the user to enter a given CAPTCHA in the first place... what do you say? (Also, it will cut down on the moderation queue, as those that are clearly spam/ham will go straight through.)

It would not be possible to insert a CAPTCHA in the process. For now, the best thing to do would be:

1. If Mollom returns 'spam', block the trackback.
2. If Mollom returns 'unsure', put the trackback in moderation queue. (Is that possible?)
3. If Mollom returns 'ham', accept the trackback.

I don't know how the trackback module is implemented, but the above would work and might be easy to implement. Now, it is pretty important to implement a feedback mechanism, so that you can report trackbacks that were not properly classified by Mollom. That would be a requirement for such a patch going in.

And this would be for the Pingback module, too (a cleaner "standard" for trackbacks, essentially).

As well, this really generalizes to *all* non interactive postings. FeedAPI is another example where we would LOVE to have anti-spam support from Mollom.

Aggregate feed --> create node --> pass to Mollom in non-interactive mode --> delete / moderate / or publish based on hammy-ness.

This particular patch only deals with comments -- I'd love for it (as per expanded title and my comments here) to handle nodes, too.

@ Boris Mann:
Please don't hijack the issue. Pingback works by inserting a comment, but Trackback uses its own type of content and thus API. This issue is for making Trackback and Mollom talk together. For Pingback to do what you describe, I think you should talk to the Pingback developers (which would be Andreas Haugstrup and, eh, me). (Also note, that since Pingback uses comments for its content, it already works with Mollom.)

@ Dries:
Yeah, of course there should be a way to educate Mollom. The goal is to remove the moderation queue, so... :)

Sorry, didn't mean to hijack, just that I think that a *general* use case would work here, rather than special casing for Trackback.

And, I assume it wouldn't work with Pingback, precisely because of the no-one-there-to-fill-out-captcha issue.

Alright, time for bed. But I did make some progress, so uploading here so it won't accidentally get lost. :)

I'm probably elucidating the obvious, but in the case of trackback, I would think that it's not so much a matter of eliminating the moderation queue as it is of minimizing its content.

It seems to me that the queue would be essential. When a trackback in the queue is deleted, a message should go to Mollom, marking it as spam, and when one is published a "ham" message should be sent.

I think you've already said that, between the lines, above. But I just wanted to be sure it was said... :)

Also, re: my offer to test above, I am still using 5.x, so for now it's an offer to test a 5.x version.

Ken Watts,

the daily mull

@Freso: I'm here for testing your trackback integration testing! I changed some lines of your patch (yes, changed CASE to SWITCH ;) )
Let me know!

Regards!

sub to test when move to CNR

Sounds good!

Sub.

Where does this stand? Any progress? Anything I can do? Just wondering...

@ thePanz:
Haha. Well caught. ;)

@ Ken Watts:
I'm afraid I haven't had any time to do any more work on this since #15. :/ And per #16, I believe we are thinking about the same behaviour. And seeing how much time I've had for the 6.x version, I doubt I'll find any time at all to work on a 5.x one anytime soon. But it probably won't be too hard to backport.

A few style errors, but looks good. :)

However, taking module weights into consideration - is it good to call _trackback_operation() in hook_trackback()? Won't that make heavier modules unable to work with the trackback in question?

I looked it over again, and thought that you are right. Calling _trackback_operation is probably a little overkill for this, so I took it out and now have it "throwing" an error on spam.

I also noticed a little redundancy in the code that was there.

Let me know what you think now.

Postponing until #245682: Enable use of Mollom for any form and #412760: User interface brainstorming land.

I am wondering if any one have the solution for the integration with trackbacks, thanks alot.

Subscribing. I got tons of trackback spam and no comfortable solution as mollom to fight it.

Per the maintainer in #25, marking this back to Postponed.