CAPTCHA weight on the registration page

It's a known bug, but it doesn't look like a new release has been made since it was fixed. Check out http://drupal.org/node/368795 ... I just applied that patch to the module and it moved the Captcha down to the bottom of the form.

To quickly patch it, just change into the mollom/ directory where mollom.module lives and run:
# curl http://drupal.org/files/issues/mollom_weight.patch | patch -p0

Will this patch ever be applied to a version?

Mollom 5.x positions the CAPTCHA before user profile fields on the registration form.

Does the #pre_render hack that the D5 version uses prevent us from inserting the CAPTCHA at the bottom of the form?

In 5.x-1.8, Mollom's CAPTCHA's weight on a form is set using the minimum of the Submit and Preview elements:
'#weight' => min($form['submit']['#weight'], $form['preview']['#weight']) + 1,

On forms without a preview button, (like user registration,) this effectively sets the CAPTCHA's #weight to 1.

The attached patch (for 5.x-1.8) adds a little logic for this situation, positioning Mollom's CAPTCHA at the bottom of the user registration form.

- I haven't tested this patch yet but it has some minor coding style issues. We write "} else {" over two lines.

- Looking at the code, I'd think it makes some unfair assumptions. For example, I think it breaks when you have a form with both a Preview and a Submit button.

I think that this should do the trick, as I think that the cause of the issue is that you can configure individual weights for the profile fields.

Overall, however, I'd hesitate to commit this patch, as it can be considered as a very late API change. It's probably better to go with a stop-gap fix, just for the user registration form, and only if Profile module is enabled (not sure if we can check whether it actually added fields to the form, but of course, that would be even better).

Thanks for your reviews!

For example, I think it breaks when you have a form with both a Preview and a Submit button.

The underlying issue here is that the existing code breaks when there is no Preview button: when $form['preview']['#weight'] is undefined min(...), returns 0, regardless of the value of $form['submit']['#weight'].

I've fixed logic and style errors in the first patch. I mis-typed min() as max() in my original patch. I'm not trying to change any logic; just account for edge conditions. This patch goes one step further to explicitly cover all cases. (If neither $form['preview']['#weight'] nor $form['submit']['#weight'] are set, $form['captcha-solution']['#weight'] defaults to 1, (which is the outcome in the existing code, too.))

@sun, I'm not sure how this amounts to an API change -- I'll certainly defer to you there -- but maintaining the min(...) function as such seems pointless when one of its parameters being undefined, (a common scenario,) spoils the logic...

Jeff, could you test sun's patch in #12? Does that work for you?

The patch in #13 seems to make sense too, although we tend to use isset() instead of is_int().

If #12 works, I'd prefer to commit #12 so let's test #12 first. Thanks!

Yes, sun's patch in #12 works for the user registration form in question.

In that case, I'm inclined to go with #12, unless there are other unexpected regressions.

Thanks for testing, jeffschuler! We may go with my #12 then. I'm merely thinking of other modules and custom, site-specific code that may expect certain form element weights on forms.

All forms enabled to be protected by Mollom currently get a preview/submit weight of (+)2 while Mollom ends up on (+)1. With this patch, form element weights are "suddenly" changing from those values to (+)100 and (+)101. Existing code (rather thinking of custom code) may rely on those weights, squeezing further elements in between by using decimal weights, i.e., 0.8 or 1.5, or trying to append things to the end of the form. In the end, I'm just trying to say that this weight change can break certain designs. But it also may not.

But then again, usage statistics for D5 only mention a small amount of installations (next to Drupal 5 overall being unsupported with the release of D7 anyway), so I'm not sure whether it's worth to think this perfect.

Committed #12 to DRUPAL-5. Let's see what happens ... would love to get some more test feedback.