Fields created by the profile module and marked to be included on the registration form (user/register) are not validated by the profile module. Therefore, the only validation done is form API required field validation.

This can easily be tested by adding a profile URL type field that is marked to appear on registration. If you enter a bogus value that is not an URL is will pass validation (or that is, the valid_url validation in profile.module will be skipped). This appears to be related to the overall way 'register' fields are special cased and the account category system. On user register all values are passed under the 'account' category and not the category the profile fields belong to.

The proper handling does happen on user/X/edit/CATEGORY so this is only applies to 'register' profile fields during user/register.

function profile_validate_profile($edit, $category) {
  $result = _profile_get_fields($category);
  while ($field = db_fetch_object($result)) {
    if ($edit[$field->name]) {
      if ($field->type == 'url') {
        if (!valid_url($edit[$field->name], TRUE)) {
          form_set_error($field->name, t('The value provided for %field is not a valid URL.', array('%field' => $field->title)));
        }
      }
    }
    else if ($field->required && !user_access('administer users')) {
      form_set_error($field->name, t('The field %field is required.', array('%field' => $field->title)));
    }
  }

  return $edit;
}

I'm thinking about a patch but the biggest problem I see is that hook_user validate op in profile.module can't cleanly distinguish when its a register vs. and edit.

CommentFileSizeAuthor
#9 328612_9.patch504 bytesjanusman
#2 328612.patch694 bytesdldege

Comments

dldege’s picture

dldege commented

The same issue exists in D5.12

dldege’s picture

dldege commented
Status: Needs review » Active
StatusFileSize
new 328612.patch694 bytes

Here is the fix but I don't like it - I hate path specific fixes. The profile category and register system seems a bit flaky

dldege’s picture

dldege commented
Status: Active » Needs review
Alaska’s picture

Alaska commented
Status: Active » Needs review

Is there a suggested fix for version 5.14?

Have the same issue. An added phone field will not validate. It is name=profile_phone.

neil.david’s picture

neil.david commented

Yep I have the same issue.

When a new user registers and puts www.example.com on the URL field(profile I added), the link that's created on his/her profile becomes http://www.drupal-site.com/www.example.com.

I'm using Drupal 6.11.

ingo86’s picture

ingo86 commented
Version: 6.6 » 6.14

This bug exists on drupal 6.14 too.
URL profile field is not validated during the registration (hook validate is not called).
Ingo86 & Psicomante

janusman’s picture

janusman commented
Status: Needs review » Reviewed & tested by the community

This seems fixed in D7. Looks a lot like the patch in #2.. so marking RTBC.

Status: Reviewed & tested by the community » Needs work

The last submitted patch, 328612.patch, failed testing.

janusman’s picture

janusman commented
Status: Needs work » Needs review
StatusFileSize
new 328612_9.patch504 bytes

New patch.

Status: Needs review » Needs work

The last submitted patch, 328612_9.patch, failed testing.

janusman’s picture

janusman commented
Version: 6.14 » 6.x-dev
Status: Needs work » Needs review

Huh, that doesn't seem right. Changing the version an re-setting to needs review.

janusman’s picture

janusman commented

#9: 328612_9.patch queued for re-testing.

janusman’s picture

janusman commented
Status: Needs review » Reviewed & tested by the community

Setting back to RTBC for the reasons mentioned in #7. Above path is just a re-roll so it applies to 6.x.

gábor hojtsy’s picture

gábor hojtsy
he/him
Primary language Hungarian
Location Hungary
commented
Status: Reviewed & tested by the community » Needs work

So the Drupal 7 code does indeed do something similar but much more generic, see http://api.drupal.org/api/drupal/modules--profile--profile.module/functi...

$result = _profile_get_fields($form['#user_category'], $form['#user_category'] == 'register');

It took some time to me to realize that _profile_get_fields() does indeed ignore category if the register argument is set. Pretty obscure...

Anyway, regarding the patch itself, checking for $_GET['q'] seems to be pretty obscure. First of all, the registration form is displayed in different flows in Drupal, such as the OpenID module flow, which I believe displays it under a different URL. And anyway, contrib modules might just drupal_get_form() the registration form for other reasons (see dialog module displaying it in a popup for example). So checking for the path of the page does seem very limiting. Do we have any information or can get any information to check for the form being handled vs. the page? Like in Drupal 7. That would be much more robust, and we'd not need to special case a URL that is not always true.

Status: Needs work » Closed (outdated)

Automatically closed because Drupal 6 is no longer supported. If the issue verifiably applies to later versions, please reopen with details and update the version.