Provide API to programmatically validate content (integration with Trackback module)

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

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

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

+      if (variable_get('mollom_trackback', 0)) {
+        mollom('mollom.checkContent', $trackback);
+      }

The return value of the call to mollom() is not used.

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

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.

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.

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...

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.

Anyone have news about this issue????

This is a bit more complex, since no form is involved in the game. The new module code is all about forms, and there is no low-level functionality that would allow for programmatic validation of arbitrary content.

However, that's something we can consider to add. We would just have to make sure that the consumer provides as much data as possible + some required properties...

Alternatively, modules like Trackback could also programmatically execute a form (and optionally implement hook_mollom_form_info() to protect custom forms), which would work for textual analysis.

If I'm following the thread correctly, it seems like this request led to a very long discussion, which was finally postponed until a couple of other issues were addressed, but now they have been addressed.

If I'm right about that, wouldn't it be appropriate to make this request active again?

Thanks.

subscribe

subscribe

Subscribing.

subscribing

Any progress???

How do we boot strap this item back into existence? Do I need to reroll this into D7 or ?? It was going well and then fell into weeds, but seems like there's momentum to resolve this or close it as a duplicate/etc. @sun or @dave_reid, can you comment?

This issue is still on my radar.

However, as I've tried to clarify in #31 already, the main problem space is that the entire functionality of the module is currently architected around forms. If there is no form in the game, then the current Mollom module does not know how to process the "post".

As of now, you'd only be able to check a random data entity if 1) you know exactly how it is structured, 2) you're able to extract the necessary values from its data structure, and 3) you're able to translate those values into the format that the Mollom REST API expects. In other words, the only case for which you can do that currently is when you develop a custom integration for a very particular entity type.

Up until upcoming D8, Drupal did not provide the necessary architectural framework to allow Mollom to operate on raw entity objects. My hope is that the new Property/Field API in Drupal 8 will allow Mollom module to "make sense" of random entities, even when no form is involved. This new architecture should inherently allow the Mollom module to process entities on a programatic/API level.

In other words, I foresee a rather fundamental rewrite of the current Mollom module for the new architecture of Drupal 8 and I'm eager to start to work on that, but as there are some other hot topics on my plate currently, so it will take some time until I can get to that.

I am closing this issue, since Mollom (the service) reached its EOL and it isn't provided anymore.