What about Zend Captcha? y/n?

Looks like it supports several different types including reCAPTCHA
http://framework.zend.com/manual/en/zend.captcha.adapters.html...

Was reading over the spec again,

Where do you want the saveSettings($postArray) function?

in the library.php? or the settings.php? you only mention the settings.php once, (im talking about the captcha)

also, for the secureimage library It needs the tools file,

currently it is an Img tag that has a link to the tool, that calls $this->securimage->show();

unless its like base64_encoded or something a tool needs to be used,

How to you want to do it?

Mike

and how do you want to do the Loading of the captcha libraries?

settings.php is a form that displays on the captcha page for the display of certain library-specific settings. So on recaptcha settings.php would contain form elements for the public and private key that recaptcha needs to function.

saveSettings($args) would be a function that lives in library.php. It is called by the controller for the captcha page for the selected captcha library, and it passes through from the page controller into the captcha controller to save the settings.

something like this:

within single_pages/dashboard/settings/spam_control/view.php, the form that wraps the captcha settings form would submit to "submit_save_captcha_settings()" which would be a function that lives in controllers/dashboard/settings/spam_control/controller.php. It would behave like this:

And yes, we'd use a tool for it still.

should each library make its own tool? or just have 1 generic tool?

You'd only make them as needed.

- should pkgID be autoincrementing or is there a method to get this?
- should the helpers exist as calls to models, or do direct db calls on their own?

The pkgID is just exactly the same as all marketplace packages currently work. It's not autoincrementing - it just ties to the pkgID in the packages table if the catpcha/antispam helper happens to be installed through a package. This isn't any new functionality - it should be the same as when you make anything else install through a package (you specify the $pkg variable and join it to the database table so that we can later uninstall them, know where they live in the filesystem, etc...)

The helpers will not call models (since models deal with database tables and this likely won't have too much in the way of database needs.); instead, the helpers will likely call third party libraries found in libraries/3rdparty/ or packages/thepackagehandle/libraries/3rdparty/

great,
so addLibrary and checking for the active captcha/antispam should just be a direct db call from the helper?

Okay-
I've put together an extremely basic antispam version that checks with akismet, no settings or options yet, just some php code. I'll submit a git branch.

https://github.com/concrete5/concrete5/pull/105
some other stuff got added in too, but the sedond two commits are antispam.

Is this something someone might be able to patch into the current c5 release, or will we have to wait for this to be a complete package and/or wait on the next release?

currently its very barebones- no way to edit the antispam, no ui, nothing. I believe that you could patch it in, but the functionality would be limited. If you try it let me know how it goes.

This spec looks great! I just wonder if we need an interface to see the filtered SPAM messages. It doesn't happen very often but I had a few cases where akismet wrongly marked a message as spam.

Hmm. Interesting point. For this first version I was thinking that the anti-spam helper would submit reject anything it found as spam. However in the future I could see having it sit in limbo, at least for certain things like the guestbook block.