Missing profile fields in the registration form

I have a single website and have the same problem

I feel the same, no fields are shown in profile during registration.

The problem persist because role of the user is not certain during registration of the user. So user should choose a role first. A module like registration_role_with_approval should be used, and according to roles selected, a multi-step registration may be in action :)

I did try this module with no effect at all to the other languages. The fields remain hidden. Please explain, did you manage to do it with the help of this module or is this just a theory?

In my test, when profile_role is enabled, profile fields in registration form is disappeared. It is an expected behavior because role of the user is not certain during registration of the user as I wrote before.
Yes it is just a theory. My solution is creating new module with a registration page with options of register student / parent / staff (see school_administration module) and handle profile fields in module... :(

All in all this is unwanted behaviour as anonymous user should be able to see the fields in the registration form.

Yes, using this way against anonymous users is an unwanted behavior. So there must be a registration page with some permissions, and a person with the required permissions should register the user...

Not sure how correct this is. But on line 79 of profile_role.module

Change it from:
$roles = isset($form_state['post']['roles']) ? $form_state['post']['roles'] : array();

To:
$roles = isset($form_state['post']['roles']) ? $form_state['post']['roles'] : array('1'=>'anonymous');

And comment out or delete the "if" right above that. Allows you to set Profiles to the anonymous role for registration.

Dude, you were right on with that! I commented out the entire if statement above that (below the function start) and replaced the code and it works beautifully. I have another User_Types module that allows me to have multiple registration forms with various options based on the registration form hyperlink they are sent to. The user-type defines the various fields displayed and in conjunction with this module, it removes that information from the tabs in their respective profiles. Hooray!

Needed this fix and can also confirm now that mnestor's 2 code changes work!

Actually this issue happens if you reach the register page with parameters in the url for example

/user/register?destination=xxxxxxxx

if you go to
/user/register

This issue will not appear.

To fix this issue you need to the following in the code in the profile_role_form_user_register_alter

function profile_role_form_user_register_alter(&$form, $form_state) {
$form_action = $form['#action'];
if(mb_strlen($form['#action']) > 14)
{
$form_action = (mb_substr($form['#action'],0,14));
}
//if ($form['#action'] == '/user/register') {
if ($form_action == '/user/register') {
// No way to determine what role user will be, so leave form alone.
return;
}

... continue the function with any other changes

Regards,

Does my patch resolve this?
http://drupal.org/node/924116

@bumathan, see comment #17 at http://drupal.org/node/431454
you don't need to set anything to display for anonymous user from this issue thread,
the patch there integrates auto assign role with profile role for registration...

As mentionned by OmarQot on #10, the issue appears only when you have arguments in the url after /user/register.

I have made a simple patch which work fine for me.
Please review and comment.

@samuelsov,

Better solution in patch here http://drupal.org/user/284019
This patch takes care of lang prefixes (/nl) but also removes the possible problems with arguments suffixing the url...

Cheers

Thanks for your feedback Bartezz, but the patch is missing.
I suppose you meant : http://drupal.org/node/924116#comment-3498508.
In this case, yes, i tested it and it's much better than my patch.

Oops, wrong url idd... Good you found it anyway. Could you mark the other post as reviewed and tested, thanx!

Cheers

#7 is not quite right either - you could use a default array array(2 => 'authenticated user') since you're always going to create an authenticated user, but that's not the real problem.

This issue (and several others) have pointed it out already - using $form['#action'] == '/user/register' is very bad. It doesn't handle arguments in the url at all and won't work with i18n and there's just no reason to use the form action in a test like that. I think the intent of this block of code can be expressed as "Dont mess with the form when registering new users."

The patch in http://drupal.org/node/924116#comment-3498508 checking $form['form_id']['#value'] == 'user_register' is useless too - the function hook is hook_form_FORM_ID_alter(), in this case profile_role_form_user_register_alter(), so they're always going to match, essentially removing this function. I'm not claiming this doesn't work for some people, since it does prevent fieldset removal, just that it only works by disabling the function, not because its a real fix.

I think the best solution is to change the initial if block to is_null($form['#uid']). $form['#uid'] will be null when creating a new user. I think it'll be defined when looking at an existing user, but haven't verified that. The attached patch makes this change.

I can into this problem not when registering, but when creating new users as an admin. It's still the user_register form, but the action and url is at admin/user/user/create.

Not much hope of getting this in though - D6 versions of profile modules are not going to get much maintenance love :D

As I stated above, the hook being used is hook_form_FORM_ID_alter(). In this case that's profile_role_form_user_register_alter. So the FORM_ID part is user_register. So the check to make sure $form_id == 'user_register' is already in the function definition.

This form_alter doesn't actually seem to make a huge lot of sense. Please correct me if I'm wrong, I'm just working on a site where this module has been previously installed, but I say this because:-

1. The purpose of the function is to remove profile fields that are not (as defined by the module configuration) for the role of the user.
2. There are two instances (in core) where the registration form is called: admin/user/user/create and user/register. In neither case do you know what role the user is going to get. With contrib added you can't even guarantee 'Authenticated User' as a role for the user.
3. There is an option in profile to choose which profile fields are shown on the registration form.

I assume this is why the solution of checking $form_id == 'user_register' is popular above, it always return TRUE hence the form_alter does not run on the registration form at all.
Is there a use case for removing for profile fields from the registration form, when you can choose that they are there in the first place? If not, is it not better to remove this function?

Answering myself. Everything is correct. Except there is a use case for removing the fields from the administration admin/user/user/create form.

Senario: Profile fields are put on registration form for the default user role of a first registering user on the site (remember this need not be authenticated user). There are other roles with different profiles that can be created by administrators.

Fine, but confusing, for admins if the registration form user role profile fields are present on the admin version of the form. However, not only confusing but impossible any of those fields are compulsory.

Solution: While detecting where the form is being show (as proved above) is brittle; and difficult. Only a user with 'administer user' privs can select chose role; they are also the only users who can access the admin version of the form. Swap out the path check, for a user access check.

you can solve this by installing the profile2 module 2 https://drupal.org/project/profile2 ...what it does is that it allows you to add custom fields on the user registration form