I've been confused about the purpose of this module for some time now. After recently migrating a site from D6->D7 I thought I had figured it out why the module had been created, but I've only become more confused about this module than before.

I'm making the following assumption. A clean install of D7 has no use for this module as it has been replaced by the fields API. So now fields can be attached to the user entity.

On a D6->D7 migrated site, I thought this modules value was that it could take over for the profile module that you get in D7. I thought it would then allow me some additional functionality in terms of what new fields could be attached to the existing profile as well as the display of the existing profile fields.

However this doesn't appear to be the case. It seems that the profile 2 module only allows you to add new profile types. Then on those profile types you can add new profile fields.

My hope was that the Profile 2 module would allow me to take control of my existing profile fields, not just the new ones.

Since the profile 2 module only allows control over newly created fields, what benefit does it have over the new D7 fields API method?

Any clarity that can be offered on these matters would be greatly appreciated.

Comments

bryancasler’s picture

bryancasler CreditAttribution: bryancasler commented
Issue summary: View changes

Added a few more details

logsd’s picture

logsd CreditAttribution: logsd commented

There are things you can do with profile 2 that you cannot do with the current field api such as declaring fields as private or creating different user profiles. Nevertheless, from my reading, the field api is definitively the future. The major issue I have with profile 2 is the fact that I cannot uninstall it properly, as explained in http://drupal.org/node/1223286. Currently, I have to keep it enabled on my server.

bryancasler’s picture

bryancasler CreditAttribution: bryancasler commented

Thanks for the feedback logsd. I'll be sure to make backups before I try it anytime soon. Quick question, my assessment about it not working with existing profile fields that have been migrated, is this correct?

As for the benefit of private fields, this module does the trick for Fields API fields http://drupal.org/project/field_permissions

joachim’s picture

joachim CreditAttribution: joachim commented
Status: Active » Closed (duplicate)

See #1006442: Provide a comparison with core user module + fields.

bryancasler’s picture

bryancasler CreditAttribution: bryancasler commented

Thanks Joachim, I've actually read that issue over several times in the past, but now I have a greater understanding of this module. I've re-written/updated one of the comments made in that issue.

Allow to make certain fields appear on registration form: user+fields & profile2
Winner: Both

field_group support: user+fields only (profile2 +field_group is broken on user registration form).
Winner: Fields API (or Both if this has been fixed)

Make fields private: profile2 only (and core's profile). This is also possible with user+fields using http://drupal.org/project/field_permissions.
Winner: Both

Allow to have several tabs on the user profile form: profile2 only (user+fields will display all the field on the same user/edit form, though you can group them with field_group)
Winner: Both

Granular permissions to view/edit own/any profile type: profile2 only. This is also possible with user+fields using http://drupal.org/project/field_permissions.
Winner: Both

Manage the display of migrated D6 profile fields.
Winner: Neither (or so I think)

Besides the fact that everything the profile2 module can do now, can also be accomplished by using a combination of fields API and the field permissions module, it is that last issue that is still bugging me. What are migrated D6->D7 sites supposed to do about managing their display of existing profile fields? I'm not saying handling that issue is this modules responsibility, but handling that issue is why I'm looking at this module and it is the reason I opened this thread. Since that question "Can the profile2 module manage the display of migrated D6 profile fields?" has neither been answered here and it wasn't asked/referenced in the linked issue, I'm asking for your feedback on if this one should be re-opened. If you still think this conversation would be better had in that que then I'll move it over there, but I do not feel it is a question of comparison with fields api.

joachim’s picture

joachim CreditAttribution: joachim commented

> Winner: Fields API
> a question of comparison with fields api

This is a misnomer -- profile2 uses FieldAPI as well. The difference is *what* you put fields on.

Also, you are missing some of the major points about profile2:

- better separation of data
- speed (because you're not overloading the $user object with data)
- different profile types according to role

bryancasler’s picture

bryancasler CreditAttribution: bryancasler commented

Thanks for the feedback Joachim. Could you comment on the question "Can the profile2 module manage the display of migrated D6 profile fields?". After I figure that out I can let this thread die :D

joachim’s picture

joachim CreditAttribution: joachim commented

I don't know what you mean by 'migrated D6 profile fields'. Migrated to what and by what?

bryancasler’s picture

bryancasler CreditAttribution: bryancasler commented

Lets say I have a D6 website with profile fields A & B and then I migrate my D6 website to D7. Now my migrated profile fields are being handled by D7's profile module. I quickly realize that the D7 profile module is limited in how it can manage the display of profile fields, it has no field groups support and it does not have a way to distinguish between the user registration page and the user/edit page.

So now I have to find another module that can "manage the display of migrated D6 profile fields?". The profile 2 module looks promising so I install it hoping that I could use it to manage the display of fields A & B. However, it seems the profile 2 module can not handle these fields. It appears as if it can only handle new fields (ie C & D, etc...) that have been created after the site has been migrated to D7.

I hope this clarifies what I was trying to say. If it helps I think the use of the word "migrate" could also be substituted with the word "upgraded"

joachim’s picture

joachim CreditAttribution: joachim commented

They've not been migrated, as they are still core profile.

What is needed is an *upgrade path*. There's an issue for that already IIRC.

bryancasler’s picture

bryancasler CreditAttribution: bryancasler commented

Thanks again Joachim, that's exactly the info I was looking for. I found this thread back in May #394720: Migrate profile module data to field API, there hasn't been a single post since then. And before my post there hadn't been any work done since February 2010. Is there perhaps another more recent post I'm missing?

Also of interest
#301071: Remove profile module from core especially comment #74
#141419: Full rework of profile categories improving data model
#608894: Resolve the conflict between the fieldable users UI and the profile module

TWD’s picture

TWD CreditAttribution: TWD commented

subscribe

TWD’s picture

TWD CreditAttribution: TWD commented
Issue summary: View changes

typo