Fields in registration form

Since a few months I try to have a closer look at Drupal 7. After the release of Alpha 6 I decided to start a clients project based on Drupal 7. Two weeks ago we discovered a more or less strange problem.

In Drupal 7, as far as I knew, the profiles module will disappear or integrated in the new field api. 

So I thought it would be a good idea to create the user fields as "fields" not as "profile fields". That worked perfect. It was possible to see the fields in the user edit dialog and in the user profile. It was also possible to access the fields via the views module.

But ... what is with the registration dialog? Usually it is a good idea to let a new user fill-out the necessary fields in the registration dialog. I didn't found a possibility to configure the appearence. I searched on and I found this node: Display user fields on registration form. The last comment was a hint to this node: Port of Field Permissions to D7.

I tried the Field Permissions module in the 7 dev branch, applied the little patch #19 ... and ... it worked.

On one hand - Thank you very much for the solution.
On the other hand - this feature is so necessary and so common ...

Anyway - I am happy :-)



Exactly what I was looking for.Technically spoken; not ideal, but hey, it works.

The Profile2 module - - is an initiative to do fields for user profiles as they ought to have been done in Drupal 7 core (the core Profile module should still be considered deprecated, in that it does not use the Fields API at all).

However, if i understand correctly, you are finding that attaching fields directly to users is working fine for you?  One thing i know you lose is the ability to have different sets of fields for different types of users (apply a field to a user and it applies to every user), but display and everything else is working out fine for you?  Profile2 not needed for in your case?

Big thanx! I try to find similar module about 2 weeks!
Profile2 works great!

In D7 the core profile module stays the same, which means no usage of Field API.

However, using the Field API is obviously the prefered solution, even though it couldn't be done in time for core, hence the move to do it in contrib, for example in

I didn't know that the profile2 module exists :-)

benjamin:  attaching the fields to a user with the "core tools" was the easiest and most logical solution for me and as I said - it works fine except for the registration thing. I also didn't know that I lose the ability to have different fieldsets for different users. I my case this feature was not necessary.

bojanz: It was good to have a deadline for core and the profile decision is ok but for me it is always hard to find the right module.

For now I am happy with my solution but next time I will definitely try out profile2. Wondering wether it is possible to convert my "core fields" to the profile2 logic ... ok, not today

It seems it was far more important to shoe horn the overlay module from zero to core (and omg what a time sink it became)  than to properly finish up fields in core and finally deprecate the core profile module. I certainly hope all that time spent on something that users will likely not care about rather than something 99.9% of users need on every site (user profiles of one form or another) pays off-- I'm just not very optimistic.

Obviously the whole situation with profile and fields is messy. You need profile to making Drupal 6 ports easier, but you don't want to use them for new projects.

I've done another module that is somewhat related, but worked better for me than field permissions for users as that doesn't really work. So have a look at user field role as well.