Heine

I've written before about (ab)using %s in IN clauses such as:

Should time permit I hope to work on MyCaptcha 5.2 this weekend.

Planned features:

• Support for recaptcha.
• Configurable location in forms.
• Configurable description on the CAPTCHA.
• A minimal API necessary for recaptcha and to silence the voice in my head screaming for a more flexible API.

I promise MyCaptcha won't be about 'APIs'; I will focus on the "Just Works" principle.

Update: MyCaptcha 1.0 has been released.

I've been adding some settings to the math captcha module I created earlier. An important setting is on which forms you want to have a captcha. While it is possible to hardcode the possible forms a captcha can appear on, I've opted for another approach.

I've created two helper modules called Form store and Form collect. If you enable Form collect, it will collect forms on your site while you visit them. You can view the collected forms on the Form store page. In the image below, you can see that I limited the collection to forms I thought useful for Captcha and that I've given most a more readable description. While I intend to include and add a description to all core forms, this has to be done manually for now.

I've a few extra scripts in the webroot of several sites to provide me with server information when I need it. These scripts tend to provide too much information to just anyone. Here's how you can quickly limit access to the Drupal admin user (the first user created on the site).

Create a file restrict.php. The example assumes all files (restrict.php, info.php and apc.php) are in the Drupal root directory. You need to adapt the include paths if you save the files elsewhere. You can make the access criteria as baroque as you need; the example simply checks on user id.