On Fri, 21 Jan 2005 07:49:08 -0000 "Michael Jervis" <mike@fuckingbrit.com> wrote:

I've been thinking, I intend to implement this as a new module that requires the spam module and works with it to keep the code modular and separate. I think this is the right way to go as it allows the functionality to be totally removed if people don't want it.

I agree it should be a seperate module.

I've had a swift first look at the spam schema, I'm thinking these need to go into the custom table as regexes, but also need marking as MT items for management. I'd add an itemtype column or some such, and insert MT for moveable type items. This should make it all transparent to the spam plugin, but allow the MT Blacklist plugin to know which items it shouldn't touch.

The first section of the file contains regexps. Those should go into the spam_custom table as you've described. The second section could either be inserted into spam_custom or spam_tokens with URL* prepended to be treated as URL filters. It's probably easier to keep them all in the custom filter table as you've suggested.

I think the first iteration should provide:

1) Manually triggered one shot, load the master list. 2) Cron managed periodic update of additions and deletions. 3) Manual trigger of 2.

Step one is unnecessary. Cron will kick off the first shot, too. But it can be nice to provide a manual "update now" button to test, etc. The add/update/delete logic in 1 and 2 should be the same. (ie, you'll want to be sure that none of the custom filters have already been manually added by the admin) -Jeremy