The user registration form looks different depending on the setting of User-configurable time zones (see attached screenshot). If this setting is enabled, the username and e-mail are enclosed in a fieldset; if the setting is disabled, they are not.

It is probably related to this part of user_register():

  // Remove form_group around default fields if there are no other groups.
  if (!$extra) {
    foreach (array('name', 'mail', 'pass', 'status', 'roles', 'notify') as $key) {
      if (isset($form['account'][$key])) {
        $form[$key] = $form['account'][$key];
      }
    }
    unset($form['account']);
  }
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

wulff’s picture

Status: Active » Needs review
FileSize
1005 bytes

It makes sense to hide the fieldset if $extra only contains hidden fields.

See attached patch.

Status: Needs review » Needs work

The last submitted patch failed testing.

wulff’s picture

Seems one of the tests in user.test might need some adjusting. I'll look into this when simpletest plays nice again.

wulff’s picture

Status: Needs work » Needs review
FileSize
1.34 KB

On second thought, let's try this.

c960657’s picture

+  // Remove the fieldset unless $extra contains one or more non-hidden elements.
...
   // Remove form_group around default fields if there are no other groups.

These two comments overlap. I suggest you remove the reference to "form_groups" – AFAIK this is history.

When investigating the code in question I noticed some other issues related to this code. These are outside the scope of this issue, so feel free to ignore them :-) But here goes:
- You may want to incorporate the patch for #227690: hook_user('register') implementations can't inject fields into account (the main one) fieldset.
- Instead of moving the controls, it may be better to simply change $form['account']['#type'] from 'fieldset' to 'markup'. This results in the same layout effect (I think), but it preserves the form structure, and this makes life easier for modules altering the form using hook_form_alter.

Dries’s picture

In the code comments, we'll also want to explain _why_ we're doing what we're doing, not only _what_ we're doing.

catch’s picture

Status: Needs review » Needs work

Needs work based on those comments.

c960657’s picture

Status: Needs work » Needs review
FileSize
2.79 KB

Slightly different approach. Using the idea from the patch in #227690: hook_user('register') implementations can't inject fields into account (the main one) fieldset it is now possible to inject fields into $form['account']. Modules should do that if they have invisible fields or don't want to trigger the layout change.

wulff’s picture

Status: Needs review » Reviewed & tested by the community

This seems like a sensible solution.

Tested and seems to work as expected.

Dries’s picture

Issue tags: +Needs screenshots

Would be great to get some screenshots of this.

catch’s picture

Dries, There's a screenshot in the opening post, I assume the idea is that there's zero change with the patch.

Status: Reviewed & tested by the community » Needs work

The last submitted patch failed testing.

lilou’s picture

Status: Needs work » Reviewed & tested by the community

Setting to previous status - testbot was broken (failed to install).

Status: Reviewed & tested by the community » Needs work

The last submitted patch failed testing.

c960657’s picture

Status: Needs work » Reviewed & tested by the community

Setting to previous status - testbot was broken (failed to install).

Status: Reviewed & tested by the community » Needs work

The last submitted patch failed testing.

c960657’s picture

Status: Needs work » Reviewed & tested by the community

Setting to previous status - testbot was broken (failed to install).

webchick’s picture

Status: Reviewed & tested by the community » Fixed

This change looks good to me.

@Dries: Basically, this is fixing a visual regression. In Drupal 6 and below, if "Account information" is the only profile category available, you don't get a fieldset on user/register. But currently, you do, because the user timezone field is not contained within the rest of the account information variables. This fixes that, and also cleans up the logic a bit to remove a bunch of hard-coded assumptions about what the "Account information" category ought to contain. +1.

Committed to HEAD!

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

c960657’s picture

Issue tags: -Needs screenshots