I have a related registration experience: There's the useability school of thought that wants users to minimize the number of clicks to do what they want, so in areas of a drupal site that require registration, I'm generating the registration form directly, instead of providing the usual link to /admin/user/register. In fact, I have to anyway, because these 'registration only' areas are not all the same - they don't always want the same registration fields to show up or be required. So, when non-registered users visit these sections (they're og pages, actually) I'm calling the user_register() function (from user.module), and noticing that the extra fields being added are erratic. For example, the profile module doesn't add it's fields (there's a test for arg() values that fails), but the og module does. In this case, I don't actually want the og checkboxes, so i'm doing the same trick as derek below, and unsetting it in my theme_user_register override i.e.. unset($form['og_register']). This works well (since there are no fancy validate/submit hooks for og), but putting the profile fields back in is more complicated that I would have thought or expected (since they do need validating, typically). Any other experiences or hints on this out there? And if you're still reading and know something about the user.module, do look here as well at what I think is a potential bug in that user_register function. http://drupal.org/node/66945 - Alan On 6/6/06, Derek Wright <drupal@dwwright.net> wrote:
in http://drupal.org/node/64221, i had good luck in form_alter() using a more drastic approach: unset(). ;)
of course, you'd have to make sure the validate() and submit() hooks don't do something catastrophic if some form element they were expecting is totally gone...
but, it worked for me in project. might work for you, too...
-derek (dww)
-- Alan Dixon, Web Developer http://alan.g.dixon.googlepages.com/