This plan is that profile2 is a replacement for profile in core. But further than that, I believe with fieldAPI we have an opportunity to lay the foundations for some pretty cool stuff, and better integration of data about users and people in contrib modules.
Map of the modules involved (the following includes hypothetical stuff!)
CORE HOPEFULLY CORE CONTRIB
user ----- profile2 ------- people / crm_contact
The entities are:
- user
- profile (aka profile item) / profile_type
- people / crm_contact / crm_contact_type
CORE HOPEFULLY CORE CONTRIB
user ----- many profile items ----- people / crm_contact
-- where the connections on both sides are loose.
So in profile2 we are providing an entity, 'profile', with a bundle, 'profile_type', somewhat analogous to node / node_type.
An instance of a profile entity is called a 'profile item', and what we really mean when we say a profile in everyday parlance (and what users will mean) is the collection of all profile items that describe one person.
For profile2's purposes, the profile items belong to a user, but for extensibility, they don't have to: different modules on the right can group multiple profile items into a meaningful representation of something that is not a user.
So to recap: a person's profile is made up of several profile items, of different types.
Profile types are extensible by other modules, as is outlined in some rules and examples below.
Some rules for profiles:
- some profile items must be unique, eg you can only have one profile item for your name, salutation, date of birth. But you can have several profile items for your different addresses.
- profile items by default display a tab at the user account, but a profile type may override this.
- some profile types don't apply to all circumstances, such as users/people/organizations. Up to contrib to alter them out of the way, but up to core to plan for this to happen.
Example 1: hypothetical profile_address module provides the 'address' profile type. This can then be used by various e-commerce modules, among others.
The address profile type comes with some suitable default fields, more field types that can be added, some clever internationalization stuff for postcodes, regions, etc.
This is a multiple profile type: a user may have more than one profile item of this type.
A field on the profile type would allow the user to flag one as their primary address, one as billing, etc.
Example 2: A lightweight 'people' module keeps a simple register of the members of a club, who are not necessarily users. People module keeps its own table of people, and keeps track of which profile items make up a single person. Should a user register subsequently, those profile items can be claimed by them.
Example 3: A more heavy duty crm_contact module could have several types of contact, say people and organizations, and have profile items on each of them. Different profile types may apply to different contact types; eg an organization needs a company number, a person needs name and salutation.
Depending on which modules are used, the different situations we can have:
- a user with a set of profile items.
- a set of profile items that people module groups to represent a club member (who is not a user)
- a user with a set of profile items that people module also knows about (so all the connections made)
- a crm_contact item that is an organization, not a person. this has some different profile items and may be also tied to a user account.
Can you clarify you ideas a bit better. I think the first bit is supposed to suggest their is a continuum of features/modules that could qualify as "profile" material, with a few hints as to where the lines might be drawn. However, it took me a several times rereading that to grasp the intention and am still not sure I've got the point.
Lets just provide a list of features/functions that need to be achieved to replace the core profile module with one that uses the new field api. We can have extra features listed that might be more optional of course. The other main point we need to reach concensus on is how to tackle this. I believe the last thread touched on whether we should be adding fields directly to the use for a profile or whether there should be profile type that all fields are attached to. There were mentions about performance, etc on each approach.
hmm. Well, I had typed up something saying that I agreed with rcross that our first priority should be porting the core profile module to use fieldAPI, with the OP's use cases in mind.
Also, as a clarifying question, without implying a suggestion or challenge, why aren't profiles nodes? I realize that D7 suggests that entities are the new node, but I expect that in reality, contrib will be slow to catch up with the concept.
I was asked why profiles aren't nodes yesterday down the pub and was stumped for a bit.
I guess the considerations of whether to define a new entity rather than use an existing one are the same as whether to create different node types or use something like taxonomy to distinguish.
I saw a blog post on that recently which I'd like to if I could remember it, but my rough rule of thumb is: how much do they have in common? how much separates them? do you want to output them in similar ways? For node types, the main thing to look at is common fields, output locations, and theming.
For profiles, my thinking is: profile items don't need a title, body, comments, or any of the stuff that comes with nodes. I don't think they need to be in nodequeues, for instance, though someone may come up with a use case. Contrib modules really worth their salt already support entities in a way -- flag, votingAPI, and views to name a few let you define new object types to flag and vote on in their API. Flaggable profile items I think is good, views of profiles obviously, votable ones again I can't see a case for but I'm interested to hear suggestions.
Lastly, and this is the biggie: we don't want to be fiddling with hiding profile items from node/x, implementing node access rules and so on.
To my mind, nodes are content. Profiles are not, the same way that say Ubercart orders are not.
And re: first priority, yes absolutely.
But I want to get ourselves a roadmap that sees far ahead, so we build the first storey of the system (to mix metaphors) knowing what we want to build on top of it later.
Hi,
It would be great to have a profile2-entity and to be able to integrate the profile fields in a node, let's say through cck. Than best of both worlds can be combined. First profile 2 will give the possibility to have profile-entities without node_access problems etc.. but for people like myself who want to see profiles also as content, they could be added to nodes through having a cck_profile 2 submodule, or something? Right?
Thanks in advance considering this!
greetings,
Martijn
- You got the point! For content profile, I think we could integrate it later on to wrap a node around each profile. But let's leave that out of this issue for now.
@roadmap:
* UI: Do we want to have a simple UI for managing profile types? I'd say, yes let's use admin/structure/profiles
* Registration: We need to clarify whether we want to support multiple profile types here. Moving profile form fields in a fieldgroup should be possible, but then still we would have to prevent fields being in two activated profile types as both would use the same form value. For now the code allows only one profile type there. And should we allow enabling registration integration per-field?
* Field privacy - Should we implement it? If so, how?
feel free to ping me on IRC to discuss this issues.
I think having the profiles as nodes brings some disadvantages. As joachim mentioned, they are not typical editorial content.
I'm not sure I grasp the concept of different profile types, though. How do you relate them to the user? Do you choose which user has which profile type? Or is this just different subgroups of profile?
What about fields on the User entity. Will they be integrated? Let's say I want to classify people in groups, unrelated to any permissions. Would I do that in the User entity or in the profile?
Regarding field privacy, are you talking about reading or writing the information? I think it's very very very important to be able to specify which role can see which profile fields. People don't want their private information readable for guests, but still want to have public profiles. Or is this a use-case for the profile types, e.g. having one for private and one for public information? In the latter case, I think it's important that both may optionally share the same fields.
What we think of as a user's profile is in fact a collection of profile items, of different types. These correspond to the current categories in D6.
So my profile could be made up of:
- a 'main' item that has my name and DOB
- several 'address' items that have my postal and billing addresses
- a 'membership' item that has details about when I joined the organization, what kind of member I am, and is only visible by admins
For the record, I think it's worth pointing out that when profile module in core is really not "salvageable" any more. When this new module reaches a reasonable level of maturity, the core profile module will be shipped out to the middle of the Pacific to some tiny Atoll and blown into subatomic dust by a hefty thermonuclear device of some kind. Any dust that remains in a collectable form will then be flown, as fast as current technology permits, into the heart of the freaking sun.
I agree with most of this but there are some benefits to profiles being nodes. Comments on the node can make a quick and easy "wall". Nodes are automatically searchable. You can mix profiles with other content in Views.
None of this is impossible to work around, but I wanted to toss them out as an alternate perspective to the "dump the nodes" idea.
Michelle got me thinking that I should expand on my prior comment about contrib & entities: profiles as nodes gets us lots of free add-ons: Fivestar, UserPoints, nodereference, etc...
So +1 to Summit & fago's suggestion of being able to have an optional 'node wrapper' around profiles. Lets plan for this from the outset.
Typically, the "type" of a profile is more related to a *relationship*, or another type of categorization, and not so much a segmentation between individual types of people.
For example, if I'm a donor, you know that because I have _donated_. Anyone who has ever donated is a donor, and the metadata makes describes me as a donor belongs on the 1+ relationships I have created with you by donating over time.
Similarly, if I'm a member, that's based on a membership that I have created at some point. Again, the metadata that describes my membership isn't a separate profile type for me, it's the existence of a record attached to my uid that cites my membership date and details.
Other addresses (e.g. mailing vs. billing vs. email vs. facebook) are also related to me based on their application.
Drupal has always had a clean way of maintained these types of relationships simply by linking on uid. Essentially, what you're describing is exactly how everything has behaved since day one. As long as we're only talking about entries in the users table.
But the reality is that many of the people you want to track don't have a uid because they're not Drupal users at all. So perhaps we need to worry less about creating different profile types, and more about creating a unique entry (perhaps in the profile module itself) that can be attached to a user record, but may also work anonymously? I created such a mechanism in the Send API, and I'm sure others have done similar for ecommerce, sessions, etc. It would be nice to unify these efforts and let other modules have something they can stick to consistently (e.g. profile id) that works as conveniently as uid does now.
Allie Micka: I think that is what is conceptionally called an entity now. Realizing that consistently throughout core and contrib is probably something to consider for D8. Here we should focus on what we can do better than core for D7.
I agree with your point about relationships. In my view, what is stored in the user table are properties of the virtual user that logs in to the drupal page. One of these properties, the uid, is the unique entry to relate to, for example to link the user to the information about a person. But it's not a prerequisite for a profile. That's how I understand it now. The relation of a user to a profile entry can be n:m.
About profiles being nodes. It's nice to have all the contrib modules for free on the profile, but I don't like the implication that profiles are handled as content then. I'd prefer not to have the profiles in the same UI as the content. I don't want them listed in admin/content, neither in admin/content/node, nor in node/add. I only want them listed in search results if the page user clicked a checkbox to search profiles in the advanced search (in the basic search, they should imho not be listed). I don't want them influenced by admin/content/node-settings. I also don't want all the fieldsets on the edit page that a node entails. Just my 2cts.
Profiles as nodes:
If I were building a facebook-type application, I'd have profile entities for private stuff about members, and a node for public stuff. Or for flexibility, as has been suggested above, some kind of node wrapper that outputs a subset of the fields on profiles.
FWIW, http://drupal.org/project/votingapi works on any entities, and therefore so will fivestar with minimal tweaking.
Profile types:
The terminology around all this is confusing and overloaded, and requires better explaining, as I'm not sure we're talking about the same things all the time.
I am REALLY open to better words for things!
Currently, in the document that kicks off this issue and in the code, "profile type" is a FieldAPI bundle, analogous to node type.
What I envisaged is that these form the category tabs like those we see in D6. I, as a user of the site might have the following profile items -- objects of type 'profile', analogous to nodes -- that describe me:
- one "Personal details", first name, surname, DOB
- two "Address", one marked as primary, one as billing.
- one "Club membership". By this I don't mean just the fact I am a member, but the fields that are about me that related in some way to the club: stuff about which committees I am on and whatever.
These four entities, of three types, make up what colloquially I would call "a profile". (This is where the hairy terminology starts!)
Being different types, they have different fields, and can also have different behaviours. Eg, I can only have one "personal details" entity, but I can have several "address". And other things I've not thought of yet.
And where I say 'contact type' I mean that a type like "personal details" won't be applicable to a profile that is for a company rather than a person. I think that's something a contrib CRM that sits on top of this module would need to figure out.
Allie's comment about membership data being in fact fields on the membership is spot on, and somewhat changes my example in this post... But it's making my head hurt thinking about whether we actually need profile types at all. We probably do for some things. But will sleep on it :D
I think a small-scale site that is just about one club (the example is Michelle's photography club site) would need just a profile type with fields for date joined, committee position, that sort of thing.
A bigger CRM contrib module would definitely do this with relationships instead.
Regarding how profiles are grouped together to make people, I did suggest back in the earlier issue (on core) that profile module maintain a profileID, which in the trivial case is a 1-1 mapping with uid, and where profiles are not users, lets you keep track of people in general.
The argument against this was that this is unnecessary duplication in core.
On the other hand, I think it's core's job to provide canonical ways of doing things -- in this case, clearing up multiple methods of doing the same thing.
So let's consider what that would mean:
We'd have a {user_profile} table that links UID to PID.
We'd have a {profile} table that lists the profile items. Several profile items would have the same PID, and together they would form my "profile".
Contrib modules can build on this, and all have the same PID to define memberships, relationships, activities, event signups, newsletter subscriptions, ecommerce transactions, etc.
The cost is an extra join when we want to ask "what is the profile data of uid X?"
Opinions?
>It's nice to have all the contrib modules for free on the profile.
Well that's nice, but this shouldn't control how we architecture things. It just makes things complicated when profiles appear as content, when users don't expect it to. Of course for some sites this makes sense, but in general it doesn't. Apart from that I think it's the modules turn to support multiple entity types now (see my blog post)
"profile types"
I think of those types as multiple different profiles, thus different users can have different profiles. E.g. a membership profile. Maybe we should just use "profile" in the UI? Admin -> Structure -> profiles lists all different profiles identified by their 'name' ('main', 'member', 'customer',..).
"But the reality is that many of the people you want to track don't have a uid because they're not Drupal users at all. "
Agreed. But that's another issue. The code already allows for profiles unrelated to accounts, so any module could go and introduce anonymous user ids and relate profiles with it. But I don't see why a profile should be the solution for something that core misses. I really suggest to stay focused on the main problem "profiles for regular site users" and just make sure it can be extended.
>We'd have a {user_profile} table that links UID to PID.
Hm in that case you could still add the uid into the profile table, anyway.
>Several profile items would have the same PID.
So all profiles belonging to the same user. So what would change that?
* We need a new primary key, as field API allows only single column primary keys we'd another new auto-increment id.
So what's different then? We have introduced a new id grouping profiles of a user. Well that's basically the above suggested 'any user id' - but again: Why should the profile module introduce that? I don't think it is its task, better introduce it in a separate module and/or work on it for d8 (comment authors...).
A "Custom Entity Kit" might also help here. Need multiple addresses attached to your customer profile? Need things like an entity representing 'any user'? It would be neat if one could just create those entities and configure how they should behave (Are they content? Searchable? Viewable? Embeddable? Have access permission?...). Well funny idea, but it's still quite far away..
I think we're all still getting confused. I am at least :)
I get the feeling fago is meaning something different to me in his comment above when he says 'profile type' which is worrying as we're co-maintaining!
From now on let's say 'profile type' to mean only the bundle:
- A profile item is a node-ish thing that holds some fields, and it's of a particular type.
- The profile type is a node type-ish thing that defines the fields.
And when we're talking about whether person we hold profile information on is indeed a person, or a member, or a company, then let's say something else, like 'contact class' (raiding the thesaurus here; we could have 'character' instead?).
As I see it, it's not up to profile module to have a notion of contact class.
Contrib can do this as it chooses, depending on the requirements of the contrib module.
My hypothetical crm_contact module would define at least two classes: person and organization.
Then it defines two profile types: 'personal_data' and 'org_data', with these fields:
- personal_data: first name, surname, dob, sex.
- org_data: company number, VAT registration, whether it's a charity, other business-related data.
The crm_contact module then uses the profile API to impose these rules:
- a contact of class 'person' can't have a profile item of type 'org_data'.
- a contact of class 'organization' can't have a profile item of type 'personal_data'.
So profile type is not the same as contact class, but there is interplay between these two concepts.
joachim, this your last comment, I think, covers the problem. In drupal-6 we have simple profile, all the users have equal fields, so it's hard to make different enough classes of users. Content_profile module extends profiles by making profile-nodes, but this doesn't solve the problem of different classes of users(why should company populate the fields like birthday) by itself, again we have to do something to separate fly from soup. Also content_profile implicates some unnecessary work to separate profiles from another content of the site(tracker, and so on), though this feature is contrary good for sites where users are the main content of the site and no need to separate them into classes - all they are people.
So, I'd prefer to see in your module something like what we see in node structure - the main table with column "type" and different types of profiles with sometimes generic fields and sometimes absolutely different. I'd like drupal with this module to let create systems with different types of accounts easy and without unnecessary fussing, which we have now. I think this is the mission of this module.
I think it would be great if this module would let to create such types as "person" and "company", add different fields to each and get different registration forms for them automatically by checking checkbox on the profile-type settings page. And also there could be type for example like "contact info", which is common to persons and companies and this type sould not have separate registration form.
And I don't think this is needed to select for each field to be on registration form or not to be, it's much better to have different registration forms for certain types of profiles and these types have common fields.
What I'd like to see is a few things. Pick and choose as you see fit - as I'm not sure what's in or out of scope...
1. Address Book
We need a (unified) address book. That means that there is a consistent way to reference registered individuals and unregistered organisations and individuals. Bear in mind that these external individuals may at some point become registered and "take over" control of their profile, address and contact details. Robert Castelo says he has some code/modules that can do this kind of thing. And can we sync these with other address books like Plaxo, Exchange, yadda?
What about the privacy issues? Who gets to see what? Are we building a social network permissions matrix where users select who can see what?
2. Identification
Vanilla Drupal is coarse to say the least - you get a username for pretty much everything. What I'd like to see is us giving people choices based on the functionality, namely:
1. A login name that is only used to access the site and does not get exposed anywhere else. This is an issue of security and one half of the username/password login challenge.
2. A display name that could be a real name or whatever is chosen.
3. A nickname (screen name) used for a user's URL and hence disambiguation (like if you have 2 people called "Daniel Harris").
For me, for example we'd have:
1. Login name: I'm not telling you!
2. Display name: Daniel Harris
3. Nickname: dahacouk
And my user URL would be http://.../user/dahacouk
3. Semantic Web
There's another reason why all this makes sense. Drupal 7 will have the semantic web built in. But soon we'll want to write documents with in a more semantic way with wysiwig editors like: http://loomp.org
We should at least be able to refer to people and organisations unambiguously from within documents via a unique URL. That means both registered and unregistered people and organisations should be able to have address book entries.
Not sure what for core or not. I just want to see the functionality easy.
Well, come on, it's a bit better than just saying "subscribe"! ;-/
netbear & dahacouk, Nice ideas, but they're all way outside the scope of this project, I think. Such tasks belong to other modules.
At the risk of introducing scope creep of my own, here's a thought on the idea of non-user profiles:
What if, instead of introducing a Profile ID that will often simply duplicate user ID, instead, we make profiles nestable, and having parents of any entity. E.g., we would have two columns: parent_id and parent_entity_type. This might solve a few problems at once.
So the parent of a profile that belongs to a user will be parent_entity_type = 'user' and parent_id = $uid. The parent of a profile that is not a user will be another profile which contains the unique identifier(s) for that person.
But I want to treat profiles as content... No problem! Set the parent as a node. (The code should be smart enough to trace from node to $node->uid when that node should also be treated as belonging to a user.)
Nested profiles are also a useful in their own right. E.g., I might have a single Membership profile, with several 'Committee' sub-profiles. I have a 'Contact information' profile with several 'Postal Address' sub-profiles.
On further thought, there's absolutely no need for Profile2 to support hierarchy itself, as long as the profile_values table provides a unique index. So I am relegating my own suggestion to 'another module,' which will store UID 0 to the profile table, and provide it's own separate hierarchy table ala taxonomy.
@ #35: Interesting third way!
I would call that concept 'ownership' of the profile rather than nesting.
We'd say either:
a) this profile item is owned by a user entity. The owner ID is 4 -- this means the profile item has data about Ursula, uid 4.
b) this profile item is owned by a crm_contact entity. The owner ID is 5 -- this means the profile item has data about Chris, crm_contact ID 5, who is not a user.
I'm curious what happens when Chris, crm_contact ID 5 registers for an account -- do we change the profile items to point to his UID? crm_contact module probably needs to keep a table of uids to crm_ids regardless.
@scroogie:
>fago: did you deliberately leave out the rest of my sentence in that quote? ;)
Sry about that, in future I'll have an eye on quoting better.
@joachim #30:
Agreed - that sounds all fine!
@#37:
Interesting question, but that's which the "contact class" providing module has to solve. Please let's concentrate on the main issue here now, the task of profile module: Providing profiles for users.
To move on, please check the data model of the latest code at http://github.com/fago/profile. Imo it's fine as that way things are working as described in #30.
@Questions regarding registration integration:
1) Should we move the fields of a profile type in an own fieldset?
2) Should we support per-field registration integration?
3) Should we support multiple profile types to appear during registration?
3)a: If yes, how to deal with a field being multiple times on the page?
4) Should we support multiple signup-ways?
My opinion:
1) If we implement 3), yes, else I don't care much.
2): Yes.
3): I'd be ok with both ways here. However if we allow that, we need to prevent a field being there multiple times. Probably best we don't allow the user to configure that, although that me confusing as there is no good cause for the user why it is that way.
4): No. That's a big change to the way drupal registration works and imo scope creep. This can be implemented by any contrib module (see auto assign role module).
As I see no really good way for supporting 3) I tend to think it's best to only support 1 profile type integrated during registration. That way the module stays slim and easy to understand. Still other modules can easily support more complex registration ways.
Registration integration:
Regarding your option 2, I started work on this last week: http://github.com/joachim-n/form_insert
My idea there is that profile fields should be insertable in other forms (Ubercart, Simplenews, Signup) and that a general framework is going to be needed. Probably in would belong contrib though, so that maybe doesn't help us here.
For the other questions:
1) I'd say yes, it looks cleaner and a fieldset costs us nothing to add.
2) Yes
3) Yes.
3a) Do you mean two different types, or one type several times (like address?) It'll be different instances of a field, surely?
4) No.
So we agree nearly entirely :)
Regarding #37:
I think this is the best compromise for the core/contrib split. It means an extra column in a core table, but allows a much less hacky implementation for contrib.
Regarding #34 dahacouk:
Unified address would be an excellent thing! Hopefully profile module will provide the groundwork for say a contrib 'profile_address' module, which then all contrib modules that use addresses can depend on. profile_address would define an 'address' profile type, allow a profile to have more than one of these, deal with synchronization and internationalization and all that.
Thanks for the input! :)
Also, while I +1 the 'profile entity and bundles' architecture that is being drawn here, one consequence is that moving a profile field from one profile type to the other (= from one bundle to the other) will be fairly difficult - at least, it's not supported by Field API. Not sure it's even doable if you consider Field API's storage backend abstraction, since you can't even assume SQL tables that you can 'manually' update.
> one consequence is that moving a profile field from one profile type to the other (= from one bundle to the other) will be fairly difficult
That's a very good point!
Currently, users are able to move a field from one category to another very easily. That is functionality we are removing.
Though it is worth noting that the limitation exists in content_profile too -- if you make 2 node types to be profiles on D6, then you have to choose carefully where you put your fields.
It could presumably be doable as a batch operation, though? Add the field to the destination bundle, do a batch of profile_load / profile_saves for both the source and destination profile items, then delete the field on the source bundle. Not simple, though.
True that it's also a limitation of current content_profile. @fago, did anyone scream about this ?
It could presumably be doable as a batch operation, though? Add the field to the destination bundle, do a batch of profile_load / profile_saves for both the source and destination profile items, then delete the field on the source bundle. Not simple, though.
Yes, probably. Also note that you'd have to invent the UI for this - CCK D6 or Field UI D7 don't offer that feature either.
@fago, did anyone scream about this ?
No, this was no problem. So I'd suggest to just don't support it for now. If a lot of users are demanding it, it can still be implemented later on. Maybe specialized data migration modules will deal with that problem.
@3)a: If yes, how to deal with a field being multiple times on the page?
Yep, I'm aware that it won't work right now. So we need to somehow solve/avoid this problem when we do 3)
@joachim: If you have one field, e.g. 'name' in two profiles and you would enable both profiles for registration integration, the form would contain the field two times. However that won't work as e.g. the value would be two times in $form_state['vales'] at the same place, thus one value would overwrite the other one.
So I tend to not support 3) as that way we don't have to find a workaround, which users have to understand.
>Regarding #37:
>I think this is the best compromise for the core/contrib split. It means an extra column in a core table, but allows a much less >hacky implementation for contrib.
I disagree :/ See my comment #39. We are working on a profile module here not on a way to identify anonymous users. That's another issue.
@form-insert:
Interesting idea, though the same "namespace" clashes as with multiple profiles could easily occur. For d5 I was able to workaround that with the subform element (warning: form api magic). Something like that might work again for d7, but again that's another topic.
Adding profile forms to another form though is easy for developers anyway with the provide form attach function (see profile2 code).
I have written a module to migrate profile data in D6 that could be useful here, http://drupal.org/project/profile_migrate. You have an option of whether your profile categories should become fieldgroups on a single content type or separate content types, since not all sites will have the same preferences. It analyzes the profile data, creates the new fields and additional content types, and then migrates the data in a batch process.
I just wanted to mention there is code that might be used as a base for getting the data migrated. If nothing else, we could make the migration a two step process, use that code to migrate from profile to D6-style fields before the CCK updates run, and then update the fields from D6-style to D7-syle using the same process we use for all CCK upgrades.
re #46: great !
IMO in D7 land, with a bit of architecture work, a single module could migrate both D6 fields and user profile fields to D7 fields. Callbacks and hooks would be different, but general architecture, UI and code workflow would be pretty similar.
Comments
Comment #1
joachim commentedAnd in a comment so I can edit myself:
This plan is that profile2 is a replacement for profile in core. But further than that, I believe with fieldAPI we have an opportunity to lay the foundations for some pretty cool stuff, and better integration of data about users and people in contrib modules.
Map of the modules involved (the following includes hypothetical stuff!)
The entities are:
- user
- profile (aka profile item) / profile_type
- people / crm_contact / crm_contact_type
-- where the connections on both sides are loose.
So in profile2 we are providing an entity, 'profile', with a bundle, 'profile_type', somewhat analogous to node / node_type.
An instance of a profile entity is called a 'profile item', and what we really mean when we say a profile in everyday parlance (and what users will mean) is the collection of all profile items that describe one person.
For profile2's purposes, the profile items belong to a user, but for extensibility, they don't have to: different modules on the right can group multiple profile items into a meaningful representation of something that is not a user.
So to recap: a person's profile is made up of several profile items, of different types.
Profile types are extensible by other modules, as is outlined in some rules and examples below.
Some rules for profiles:
- some profile items must be unique, eg you can only have one profile item for your name, salutation, date of birth. But you can have several profile items for your different addresses.
- profile items by default display a tab at the user account, but a profile type may override this.
- some profile types don't apply to all circumstances, such as users/people/organizations. Up to contrib to alter them out of the way, but up to core to plan for this to happen.
Example 1: hypothetical profile_address module provides the 'address' profile type. This can then be used by various e-commerce modules, among others.
The address profile type comes with some suitable default fields, more field types that can be added, some clever internationalization stuff for postcodes, regions, etc.
This is a multiple profile type: a user may have more than one profile item of this type.
A field on the profile type would allow the user to flag one as their primary address, one as billing, etc.
Example 2: A lightweight 'people' module keeps a simple register of the members of a club, who are not necessarily users. People module keeps its own table of people, and keeps track of which profile items make up a single person. Should a user register subsequently, those profile items can be claimed by them.
Example 3: A more heavy duty crm_contact module could have several types of contact, say people and organizations, and have profile items on each of them. Different profile types may apply to different contact types; eg an organization needs a company number, a person needs name and salutation.
Depending on which modules are used, the different situations we can have:
- a user with a set of profile items.
- a set of profile items that people module groups to represent a club member (who is not a user)
- a user with a set of profile items that people module also knows about (so all the connections made)
- a crm_contact item that is an organization, not a person. this has some different profile items and may be also tied to a user account.
Comment #2
rcross commentedsubscribe.
Can you clarify you ideas a bit better. I think the first bit is supposed to suggest their is a continuum of features/modules that could qualify as "profile" material, with a few hints as to where the lines might be drawn. However, it took me a several times rereading that to grasp the intention and am still not sure I've got the point.
Lets just provide a list of features/functions that need to be achieved to replace the core profile module with one that uses the new field api. We can have extra features listed that might be more optional of course. The other main point we need to reach concensus on is how to tackle this. I believe the last thread touched on whether we should be adding fields directly to the use for a profile or whether there should be profile type that all fields are attached to. There were mentions about performance, etc on each approach.
Comment #3
floretan commentedSubscribe.
Comment #4
mattiasj commentedSubscribe
Comment #5
chrisroditis commentedSubscribe
Comment #7
matt2000 commentedDidn't I subscribe to this this morning?
Comment #8
matt2000 commentedhmm. Well, I had typed up something saying that I agreed with rcross that our first priority should be porting the core profile module to use fieldAPI, with the OP's use cases in mind.
Also, as a clarifying question, without implying a suggestion or challenge, why aren't profiles nodes? I realize that D7 suggests that entities are the new node, but I expect that in reality, contrib will be slow to catch up with the concept.
Comment #9
andypostSubscribe
Comment #10
joachim commented'entities are the new node'
Heh, I like that :)
I was asked why profiles aren't nodes yesterday down the pub and was stumped for a bit.
I guess the considerations of whether to define a new entity rather than use an existing one are the same as whether to create different node types or use something like taxonomy to distinguish.
I saw a blog post on that recently which I'd like to if I could remember it, but my rough rule of thumb is: how much do they have in common? how much separates them? do you want to output them in similar ways? For node types, the main thing to look at is common fields, output locations, and theming.
For profiles, my thinking is: profile items don't need a title, body, comments, or any of the stuff that comes with nodes. I don't think they need to be in nodequeues, for instance, though someone may come up with a use case. Contrib modules really worth their salt already support entities in a way -- flag, votingAPI, and views to name a few let you define new object types to flag and vote on in their API. Flaggable profile items I think is good, views of profiles obviously, votable ones again I can't see a case for but I'm interested to hear suggestions.
Lastly, and this is the biggie: we don't want to be fiddling with hiding profile items from node/x, implementing node access rules and so on.
To my mind, nodes are content. Profiles are not, the same way that say Ubercart orders are not.
Comment #11
joachim commentedAnd re: first priority, yes absolutely.
But I want to get ourselves a roadmap that sees far ahead, so we build the first storey of the system (to mix metaphors) knowing what we want to build on top of it later.
Comment #12
summit commentedHi,
It would be great to have a profile2-entity and to be able to integrate the profile fields in a node, let's say through cck. Than best of both worlds can be combined. First profile 2 will give the possibility to have profile-entities without node_access problems etc.. but for people like myself who want to see profiles also as content, they could be added to nodes through having a cck_profile 2 submodule, or something? Right?
Thanks in advance considering this!
greetings,
Martijn
Comment #13
fago'entities are the new node'
- You got the point! For content profile, I think we could integrate it later on to wrap a node around each profile. But let's leave that out of this issue for now.
@code: See http://drupal.org/node/301071#comment-2229218 for some updated code.
@roadmap:
* UI: Do we want to have a simple UI for managing profile types? I'd say, yes let's use admin/structure/profiles
* Registration: We need to clarify whether we want to support multiple profile types here. Moving profile form fields in a fieldgroup should be possible, but then still we would have to prevent fields being in two activated profile types as both would use the same form value. For now the code allows only one profile type there. And should we allow enabling registration integration per-field?
* Field privacy - Should we implement it? If so, how?
feel free to ping me on IRC to discuss this issues.
Comment #14
SeanBannister commentedSub
Comment #15
scroogie commentedI think having the profiles as nodes brings some disadvantages. As joachim mentioned, they are not typical editorial content.
I'm not sure I grasp the concept of different profile types, though. How do you relate them to the user? Do you choose which user has which profile type? Or is this just different subgroups of profile?
What about fields on the User entity. Will they be integrated? Let's say I want to classify people in groups, unrelated to any permissions. Would I do that in the User entity or in the profile?
Regarding field privacy, are you talking about reading or writing the information? I think it's very very very important to be able to specify which role can see which profile fields. People don't want their private information readable for guests, but still want to have public profiles. Or is this a use-case for the profile types, e.g. having one for private and one for public information? In the latter case, I think it's important that both may optionally share the same fields.
Sorry, I seem to be lacking a lot of the basics.
Comment #16
joachim commentedWhat we think of as a user's profile is in fact a collection of profile items, of different types. These correspond to the current categories in D6.
So my profile could be made up of:
- a 'main' item that has my name and DOB
- several 'address' items that have my postal and billing addresses
- a 'membership' item that has details about when I joined the organization, what kind of member I am, and is only visible by admins
Comment #17
sunsubscribing
Comment #18
niklp commentedbusdriving
Comment #19
matt2000 commentedFor the D7 cycle, will Profile2 be a drop in replacement for Core Profile, or an extension of it?
Comment #20
joachim commentedReplacement.
Comment #21
niklp commentedFor the record, I think it's worth pointing out that when profile module in core is really not "salvageable" any more. When this new module reaches a reasonable level of maturity, the core profile module will be shipped out to the middle of the Pacific to some tiny Atoll and blown into subatomic dust by a hefty thermonuclear device of some kind. Any dust that remains in a collectable form will then be flown, as fast as current technology permits, into the heart of the freaking sun.
Comment #22
catchSubscribing.
Just a quick note that profile types looks like it just requires a 'bundle' column equivalent to node type, more or less anyway.
Comment #23
michelleI agree with most of this but there are some benefits to profiles being nodes. Comments on the node can make a quick and easy "wall". Nodes are automatically searchable. You can mix profiles with other content in Views.
None of this is impossible to work around, but I wanted to toss them out as an alternate perspective to the "dump the nodes" idea.
Michelle
Comment #24
matt2000 commentedMichelle got me thinking that I should expand on my prior comment about contrib & entities: profiles as nodes gets us lots of free add-ons: Fivestar, UserPoints, nodereference, etc...
So +1 to Summit & fago's suggestion of being able to have an optional 'node wrapper' around profiles. Lets plan for this from the outset.
Comment #25
allie mickaTypically, the "type" of a profile is more related to a *relationship*, or another type of categorization, and not so much a segmentation between individual types of people.
For example, if I'm a donor, you know that because I have _donated_. Anyone who has ever donated is a donor, and the metadata makes describes me as a donor belongs on the 1+ relationships I have created with you by donating over time.
Similarly, if I'm a member, that's based on a membership that I have created at some point. Again, the metadata that describes my membership isn't a separate profile type for me, it's the existence of a record attached to my uid that cites my membership date and details.
Other addresses (e.g. mailing vs. billing vs. email vs. facebook) are also related to me based on their application.
Drupal has always had a clean way of maintained these types of relationships simply by linking on uid. Essentially, what you're describing is exactly how everything has behaved since day one. As long as we're only talking about entries in the users table.
But the reality is that many of the people you want to track don't have a uid because they're not Drupal users at all. So perhaps we need to worry less about creating different profile types, and more about creating a unique entry (perhaps in the profile module itself) that can be attached to a user record, but may also work anonymously? I created such a mechanism in the Send API, and I'm sure others have done similar for ecommerce, sessions, etc. It would be nice to unify these efforts and let other modules have something they can stick to consistently (e.g. profile id) that works as conveniently as uid does now.
Comment #26
scroogie commentedAllie Micka: I think that is what is conceptionally called an entity now. Realizing that consistently throughout core and contrib is probably something to consider for D8. Here we should focus on what we can do better than core for D7.
I agree with your point about relationships. In my view, what is stored in the user table are properties of the virtual user that logs in to the drupal page. One of these properties, the uid, is the unique entry to relate to, for example to link the user to the information about a person. But it's not a prerequisite for a profile. That's how I understand it now. The relation of a user to a profile entry can be n:m.
About profiles being nodes. It's nice to have all the contrib modules for free on the profile, but I don't like the implication that profiles are handled as content then. I'd prefer not to have the profiles in the same UI as the content. I don't want them listed in admin/content, neither in admin/content/node, nor in node/add. I only want them listed in search results if the page user clicked a checkbox to search profiles in the advanced search (in the basic search, they should imho not be listed). I don't want them influenced by admin/content/node-settings. I also don't want all the fieldsets on the edit page that a node entails. Just my 2cts.
Comment #27
joachim commentedProfiles as nodes:
If I were building a facebook-type application, I'd have profile entities for private stuff about members, and a node for public stuff. Or for flexibility, as has been suggested above, some kind of node wrapper that outputs a subset of the fields on profiles.
FWIW, http://drupal.org/project/votingapi works on any entities, and therefore so will fivestar with minimal tweaking.
Profile types:
The terminology around all this is confusing and overloaded, and requires better explaining, as I'm not sure we're talking about the same things all the time.
I am REALLY open to better words for things!
Currently, in the document that kicks off this issue and in the code, "profile type" is a FieldAPI bundle, analogous to node type.
What I envisaged is that these form the category tabs like those we see in D6. I, as a user of the site might have the following profile items -- objects of type 'profile', analogous to nodes -- that describe me:
- one "Personal details", first name, surname, DOB
- two "Address", one marked as primary, one as billing.
- one "Club membership". By this I don't mean just the fact I am a member, but the fields that are about me that related in some way to the club: stuff about which committees I am on and whatever.
These four entities, of three types, make up what colloquially I would call "a profile". (This is where the hairy terminology starts!)
Being different types, they have different fields, and can also have different behaviours. Eg, I can only have one "personal details" entity, but I can have several "address". And other things I've not thought of yet.
And where I say 'contact type' I mean that a type like "personal details" won't be applicable to a profile that is for a company rather than a person. I think that's something a contrib CRM that sits on top of this module would need to figure out.
Allie's comment about membership data being in fact fields on the membership is spot on, and somewhat changes my example in this post... But it's making my head hurt thinking about whether we actually need profile types at all. We probably do for some things. But will sleep on it :D
I think a small-scale site that is just about one club (the example is Michelle's photography club site) would need just a profile type with fields for date joined, committee position, that sort of thing.
A bigger CRM contrib module would definitely do this with relationships instead.
Regarding how profiles are grouped together to make people, I did suggest back in the earlier issue (on core) that profile module maintain a profileID, which in the trivial case is a 1-1 mapping with uid, and where profiles are not users, lets you keep track of people in general.
The argument against this was that this is unnecessary duplication in core.
On the other hand, I think it's core's job to provide canonical ways of doing things -- in this case, clearing up multiple methods of doing the same thing.
So let's consider what that would mean:
We'd have a {user_profile} table that links UID to PID.
We'd have a {profile} table that lists the profile items. Several profile items would have the same PID, and together they would form my "profile".
Contrib modules can build on this, and all have the same PID to define memberships, relationships, activities, event signups, newsletter subscriptions, ecommerce transactions, etc.
The cost is an extra join when we want to ask "what is the profile data of uid X?"
Opinions?
Comment #28
fago>It's nice to have all the contrib modules for free on the profile.
Well that's nice, but this shouldn't control how we architecture things. It just makes things complicated when profiles appear as content, when users don't expect it to. Of course for some sites this makes sense, but in general it doesn't. Apart from that I think it's the modules turn to support multiple entity types now (see my blog post)
"profile types"
I think of those types as multiple different profiles, thus different users can have different profiles. E.g. a membership profile. Maybe we should just use "profile" in the UI? Admin -> Structure -> profiles lists all different profiles identified by their 'name' ('main', 'member', 'customer',..).
"But the reality is that many of the people you want to track don't have a uid because they're not Drupal users at all. "
Agreed. But that's another issue. The code already allows for profiles unrelated to accounts, so any module could go and introduce anonymous user ids and relate profiles with it. But I don't see why a profile should be the solution for something that core misses. I really suggest to stay focused on the main problem "profiles for regular site users" and just make sure it can be extended.
>We'd have a {user_profile} table that links UID to PID.
Hm in that case you could still add the uid into the profile table, anyway.
>Several profile items would have the same PID.
So all profiles belonging to the same user. So what would change that?
* We need a new primary key, as field API allows only single column primary keys we'd another new auto-increment id.
So what's different then? We have introduced a new id grouping profiles of a user. Well that's basically the above suggested 'any user id' - but again: Why should the profile module introduce that? I don't think it is its task, better introduce it in a separate module and/or work on it for d8 (comment authors...).
A "Custom Entity Kit" might also help here. Need multiple addresses attached to your customer profile? Need things like an entity representing 'any user'? It would be neat if one could just create those entities and configure how they should behave (Are they content? Searchable? Viewable? Embeddable? Have access permission?...). Well funny idea, but it's still quite far away..
Comment #29
scroogie commentedfago: did you deliberately leave out the rest of my sentence in that quote? ;)
Comment #30
joachim commentedI think we're all still getting confused. I am at least :)
I get the feeling fago is meaning something different to me in his comment above when he says 'profile type' which is worrying as we're co-maintaining!
From now on let's say 'profile type' to mean only the bundle:
- A profile item is a node-ish thing that holds some fields, and it's of a particular type.
- The profile type is a node type-ish thing that defines the fields.
And when we're talking about whether person we hold profile information on is indeed a person, or a member, or a company, then let's say something else, like 'contact class' (raiding the thesaurus here; we could have 'character' instead?).
As I see it, it's not up to profile module to have a notion of contact class.
Contrib can do this as it chooses, depending on the requirements of the contrib module.
My hypothetical crm_contact module would define at least two classes: person and organization.
Then it defines two profile types: 'personal_data' and 'org_data', with these fields:
- personal_data: first name, surname, dob, sex.
- org_data: company number, VAT registration, whether it's a charity, other business-related data.
The crm_contact module then uses the profile API to impose these rules:
- a contact of class 'person' can't have a profile item of type 'org_data'.
- a contact of class 'organization' can't have a profile item of type 'personal_data'.
So profile type is not the same as contact class, but there is interplay between these two concepts.
Comment #31
netbear commentedjoachim, this your last comment, I think, covers the problem. In drupal-6 we have simple profile, all the users have equal fields, so it's hard to make different enough classes of users. Content_profile module extends profiles by making profile-nodes, but this doesn't solve the problem of different classes of users(why should company populate the fields like birthday) by itself, again we have to do something to separate fly from soup. Also content_profile implicates some unnecessary work to separate profiles from another content of the site(tracker, and so on), though this feature is contrary good for sites where users are the main content of the site and no need to separate them into classes - all they are people.
So, I'd prefer to see in your module something like what we see in node structure - the main table with column "type" and different types of profiles with sometimes generic fields and sometimes absolutely different. I'd like drupal with this module to let create systems with different types of accounts easy and without unnecessary fussing, which we have now. I think this is the mission of this module.
Comment #32
netbear commentedI think it would be great if this module would let to create such types as "person" and "company", add different fields to each and get different registration forms for them automatically by checking checkbox on the profile-type settings page. And also there could be type for example like "contact info", which is common to persons and companies and this type sould not have separate registration form.
Comment #33
netbear commentedAnd I don't think this is needed to select for each field to be on registration form or not to be, it's much better to have different registration forms for certain types of profiles and these types have common fields.
Comment #34
dahacouk commentedWhat I'd like to see is a few things. Pick and choose as you see fit - as I'm not sure what's in or out of scope...
1. Address Book
We need a (unified) address book. That means that there is a consistent way to reference registered individuals and unregistered organisations and individuals. Bear in mind that these external individuals may at some point become registered and "take over" control of their profile, address and contact details. Robert Castelo says he has some code/modules that can do this kind of thing. And can we sync these with other address books like Plaxo, Exchange, yadda?
What about the privacy issues? Who gets to see what? Are we building a social network permissions matrix where users select who can see what?
2. Identification
Vanilla Drupal is coarse to say the least - you get a username for pretty much everything. What I'd like to see is us giving people choices based on the functionality, namely:
1. A login name that is only used to access the site and does not get exposed anywhere else. This is an issue of security and one half of the username/password login challenge.
2. A display name that could be a real name or whatever is chosen.
3. A nickname (screen name) used for a user's URL and hence disambiguation (like if you have 2 people called "Daniel Harris").
For me, for example we'd have:
1. Login name: I'm not telling you!
2. Display name: Daniel Harris
3. Nickname: dahacouk
And my user URL would be http://.../user/dahacouk
3. Semantic Web
There's another reason why all this makes sense. Drupal 7 will have the semantic web built in. But soon we'll want to write documents with in a more semantic way with wysiwig editors like:
http://loomp.org
We should at least be able to refer to people and organisations unambiguously from within documents via a unique URL. That means both registered and unregistered people and organisations should be able to have address book entries.
Not sure what for core or not. I just want to see the functionality easy.
Well, come on, it's a bit better than just saying "subscribe"! ;-/
Cheers Daniel
Comment #35
matt2000 commentednetbear & dahacouk, Nice ideas, but they're all way outside the scope of this project, I think. Such tasks belong to other modules.
At the risk of introducing scope creep of my own, here's a thought on the idea of non-user profiles:
What if, instead of introducing a Profile ID that will often simply duplicate user ID, instead, we make profiles nestable, and having parents of any entity. E.g., we would have two columns: parent_id and parent_entity_type. This might solve a few problems at once.
So the parent of a profile that belongs to a user will be parent_entity_type = 'user' and parent_id = $uid. The parent of a profile that is not a user will be another profile which contains the unique identifier(s) for that person.
But I want to treat profiles as content... No problem! Set the parent as a node. (The code should be smart enough to trace from node to $node->uid when that node should also be treated as belonging to a user.)
Nested profiles are also a useful in their own right. E.g., I might have a single Membership profile, with several 'Committee' sub-profiles. I have a 'Contact information' profile with several 'Postal Address' sub-profiles.
Does that make sense?
Comment #36
matt2000 commentedOn further thought, there's absolutely no need for Profile2 to support hierarchy itself, as long as the profile_values table provides a unique index. So I am relegating my own suggestion to 'another module,' which will store UID 0 to the profile table, and provide it's own separate hierarchy table ala taxonomy.
Comment #37
joachim commented@ #35: Interesting third way!
I would call that concept 'ownership' of the profile rather than nesting.
We'd say either:
a) this profile item is owned by a user entity. The owner ID is 4 -- this means the profile item has data about Ursula, uid 4.
b) this profile item is owned by a crm_contact entity. The owner ID is 5 -- this means the profile item has data about Chris, crm_contact ID 5, who is not a user.
I'm curious what happens when Chris, crm_contact ID 5 registers for an account -- do we change the profile items to point to his UID? crm_contact module probably needs to keep a table of uids to crm_ids regardless.
Comment #38
scroogie commenteddahacouk: #2 is for core. Have a look at #102679: Add a Display Name field to core in addition to Username #394282: Add a standardized full name field to the users table and #192056: User's raw login name should not be output directly
Comment #39
fago@scroogie:
>fago: did you deliberately leave out the rest of my sentence in that quote? ;)
Sry about that, in future I'll have an eye on quoting better.
@joachim #30:
Agreed - that sounds all fine!
@#37:
Interesting question, but that's which the "contact class" providing module has to solve. Please let's concentrate on the main issue here now, the task of profile module: Providing profiles for users.
To move on, please check the data model of the latest code at http://github.com/fago/profile. Imo it's fine as that way things are working as described in #30.
@Questions regarding registration integration:
1) Should we move the fields of a profile type in an own fieldset?
2) Should we support per-field registration integration?
3) Should we support multiple profile types to appear during registration?
3)a: If yes, how to deal with a field being multiple times on the page?
4) Should we support multiple signup-ways?
My opinion:
1) If we implement 3), yes, else I don't care much.
2): Yes.
3): I'd be ok with both ways here. However if we allow that, we need to prevent a field being there multiple times. Probably best we don't allow the user to configure that, although that me confusing as there is no good cause for the user why it is that way.
4): No. That's a big change to the way drupal registration works and imo scope creep. This can be implemented by any contrib module (see auto assign role module).
As I see no really good way for supporting 3) I tend to think it's best to only support 1 profile type integrated during registration. That way the module stays slim and easy to understand. Still other modules can easily support more complex registration ways.
Comment #40
joachim commentedRegistration integration:
Regarding your option 2, I started work on this last week: http://github.com/joachim-n/form_insert
My idea there is that profile fields should be insertable in other forms (Ubercart, Simplenews, Signup) and that a general framework is going to be needed. Probably in would belong contrib though, so that maybe doesn't help us here.
For the other questions:
1) I'd say yes, it looks cleaner and a fieldset costs us nothing to add.
2) Yes
3) Yes.
3a) Do you mean two different types, or one type several times (like address?) It'll be different instances of a field, surely?
4) No.
So we agree nearly entirely :)
Regarding #37:
I think this is the best compromise for the core/contrib split. It means an extra column in a core table, but allows a much less hacky implementation for contrib.
Regarding #34 dahacouk:
Unified address would be an excellent thing! Hopefully profile module will provide the groundwork for say a contrib 'profile_address' module, which then all contrib modules that use addresses can depend on. profile_address would define an 'address' profile type, allow a profile to have more than one of these, deal with synchronization and internationalization and all that.
Thanks for the input! :)
Comment #41
yched commentedfago #39:
Hm, Field API doesn't support this currently - even for different instances of a field. See #627730: Make field forms resilient to form_alter() structure changes (which doesn't try to change that fact, but highlights code areas involved)
Also, while I +1 the 'profile entity and bundles' architecture that is being drawn here, one consequence is that moving a profile field from one profile type to the other (= from one bundle to the other) will be fairly difficult - at least, it's not supported by Field API. Not sure it's even doable if you consider Field API's storage backend abstraction, since you can't even assume SQL tables that you can 'manually' update.
Comment #42
joachim commented> one consequence is that moving a profile field from one profile type to the other (= from one bundle to the other) will be fairly difficult
That's a very good point!
Currently, users are able to move a field from one category to another very easily. That is functionality we are removing.
Though it is worth noting that the limitation exists in content_profile too -- if you make 2 node types to be profiles on D6, then you have to choose carefully where you put your fields.
It could presumably be doable as a batch operation, though? Add the field to the destination bundle, do a batch of profile_load / profile_saves for both the source and destination profile items, then delete the field on the source bundle. Not simple, though.
Comment #43
yched commentedTrue that it's also a limitation of current content_profile. @fago, did anyone scream about this ?
It could presumably be doable as a batch operation, though? Add the field to the destination bundle, do a batch of profile_load / profile_saves for both the source and destination profile items, then delete the field on the source bundle. Not simple, though.
Yes, probably. Also note that you'd have to invent the UI for this - CCK D6 or Field UI D7 don't offer that feature either.
Comment #44
fagothanks for your notes yched.
@fago, did anyone scream about this ?
No, this was no problem. So I'd suggest to just don't support it for now. If a lot of users are demanding it, it can still be implemented later on. Maybe specialized data migration modules will deal with that problem.
@3)a: If yes, how to deal with a field being multiple times on the page?
Yep, I'm aware that it won't work right now. So we need to somehow solve/avoid this problem when we do 3)
@joachim: If you have one field, e.g. 'name' in two profiles and you would enable both profiles for registration integration, the form would contain the field two times. However that won't work as e.g. the value would be two times in $form_state['vales'] at the same place, thus one value would overwrite the other one.
So I tend to not support 3) as that way we don't have to find a workaround, which users have to understand.
>Regarding #37:
>I think this is the best compromise for the core/contrib split. It means an extra column in a core table, but allows a much less >hacky implementation for contrib.
I disagree :/ See my comment #39. We are working on a profile module here not on a way to identify anonymous users. That's another issue.
@form-insert:
Interesting idea, though the same "namespace" clashes as with multiple profiles could easily occur. For d5 I was able to workaround that with the subform element (warning: form api magic). Something like that might work again for d7, but again that's another topic.
Adding profile forms to another form though is easy for developers anyway with the provide form attach function (see profile2 code).
Comment #45
jensimmons commentedsubscribe
Comment #46
karens commentedI have written a module to migrate profile data in D6 that could be useful here, http://drupal.org/project/profile_migrate. You have an option of whether your profile categories should become fieldgroups on a single content type or separate content types, since not all sites will have the same preferences. It analyzes the profile data, creates the new fields and additional content types, and then migrates the data in a batch process.
I just wanted to mention there is code that might be used as a base for getting the data migrated. If nothing else, we could make the migration a two step process, use that code to migrate from profile to D6-style fields before the CCK updates run, and then update the fields from D6-style to D7-syle using the same process we use for all CCK upgrades.
Comment #47
yched commentedre #46: great !
IMO in D7 land, with a bit of architecture work, a single module could migrate both D6 fields and user profile fields to D7 fields. Callbacks and hooks would be different, but general architecture, UI and code workflow would be pretty similar.
Comment #48
bendiy commentedSubscribe
Comment #49
dave reidComment #50
rlmumfordsubscribe
Comment #51
fagoI guess that's fixed now. :)