Migrate profile module data to field API

Subscribe. Any kind sole willing to take this on? Glory goes to you ...

Florian assigned it to himself, so presumably he wants to do it. Yay, Florian!

subscribe. excellent idea. smooth upgrade to 7.

#301071: Remove profile module from core marked as duplicate.

We don't need to get rid of the module if it doesn't make sense, just convert fields. But to these points:

- Categorize profile fields to have different secondary tabs when editing a user.
This is what a core version of fieldgroup could do -- there is a contrib module now that makes fieldgroups into tabs.

- Visibility/privacy options for each field.
We need permission/privacy settings per field to make it into core, that's already noted as a TODO

- Add certain fields to the registration form.
Not sure what module should be responsible for this, might be one of the remaining uses for the profile module, but we could also just make the registration form 'fieldable'.

- Autocompletion for text field
Can be done with field API, already done in CCK D6.

- Provide lists of users with a certain value for a specific profile field.
Maybe could be done with Field API -- we don't yet have userreference in core, or maybe we need a 'rolereference' field.

- Display an "author information" block on node pages.
I always thought the 'node author' should become a userreference field, which will also allow you to set multiple authors for a node, something we can't do now. Then displaying it on a node becomes just another field setting.

- Provide URL and date fields
Two more field modules that need a core version anyway.

- A formatter that outputs comma-separated lists rather than HTML lists.
Just another formatter, not really any need for a module to do this.

So it looks to me like it is mostly a matter of getting more parts of CCK into core.

adding 'fields in core' tag so this issue will show up in the block listing

Tracking!

@flobruit - are you still planning to tackle this? if you want some help, perhaps you can list a few tasks that others can do.

perhaps we just leave date and url fields unmigrated and leave it to those contrib modules to do the job. i think it is a bit unlikely that those go in.

"- Provide lists of users with a certain value for a specific profile field.". we have a field_attach_query() now.

"Also, here's a re-roll of the original patch only change is the update number and adding the $ret variable."
Forgot the patch ;-)

These two:

- Provide lists of users with a certain value for a specific profile field.
- Display an "author information" block on node pages.

Profile module really shouldn't be providing these any more, and especially not if it's using field API storage, so I'd be in favour of dropping these completely and point people to views. We absolutely have to provide an upgrade path for data, but not necessarily for every single feature if it's easy to replicate in contrib.

Fully agreed with catch - although there's a slight gotcha about "lists of users with a certain value for a specific profile field"
The actual feature is 'display the value as a link to a list of users having the same value".
Even if we defer the actual list page to Views, I'm not sure how we will generate 'display the value as link to this page'.

Two tracks:
- this sounds darn close to a taxo field on users (closed list or freetag)...
- a generic link builder for formatters, similar to the one added in Views 2.2 or 2.3, would be super useful (link to the object, link to a custom path with a pattern...).
Interesting case, because I'm not sure the Field API currently allows that. Formatter settings are specific to each formatter, and we don't want each formatter (for text fields, for number fields, for image fields...) to reimplement this. Sounds pretty close to CCK D6's #417122: Allow drupal_alter() on Field and Widget Settings (on formatters, this time), which we'll need to adress in D7 too.

[edited out - wrong thread]

subscribe...

See #526122: Autocomplete widget for taxonomy term fields for autocomplete widget stuff. Maybe moving to a more general autocomplete for text field for core.

It looks as if the old "Provide lists of users with a certain value for a specific profile field" functionality has already been removed from the HEAD version of d7 profile.module (with the probable intention of letting Views take care of that). Can someone confirm that has happened? If it's true, we can close this issue: http://drupal.org/node/525058 ("pages view for profile fields broken").

this really should be batching per uid.

Subscribing. Maybe I can eke out some time to work on this.

Sounds like a good plan to me.

Wow, thats a really solid justification and thanks so much for volunteering to be a maintainer. +1 from me. CCK UI is very very close.

Hey, a suggestion to take something *out* of core! Hurray!

Here's a patch.

I'm not so keen about removing profile module at this point. Before I commit this patch, I want to see CCK UI in core, and be applicable to users along with an upgrade path from profile module to Fields API.

Dries, does this mean you're making Date and URL fields in core a requirement to move profile module to contrib?

I don't think Dries meant that. He wanted an upgrade path *of some type*. Some of that path will be core, and some will be contrib (date field, views, ...).

Looks like this is postponed on the items outlined by Dries in #30.

Hope to see you folks at #516138: Move CCK HEAD in core and #366364: [meta] Data migration from D6 contrib CCK fields to D7 Field API.

We need an upgrade path from profile.module to fields, not from CCK to fields, so [#3666364] shouldn't be a dependency.

furthermore, marking this postponed just discourages anyone from working on that update path.

@moshe: Er. Is this issue about moving profile module to contrib, or is it about creating an update path from profile to field api? Please title accordingly, and/or create a sub-issue for someone to work on said upgrade path. I can guarantee no one's going to work on an upgrade path for Profile module in an issue entitled "Move profile.module to contrib" that is set to "active" status. ;)

@webchick - see #30 where dries creates a dependency for this issue. he requires that the upgrade path to fields be complete. so, this issue is about both IMO. i don't see much point in creating another issue but if someone wants to do that, go ahead.

subscribe

Re-roll of flobruit's patch.

Renamed system_update.

Don't migrate date and URL fields so we leave that to the relevant contrib module(s) to deal with. I have a feeling we need to skip 'list' as well since no such field type exists in core, or maybe we change these to freetagging taxonomy vocabularies attached to users if we're feeling bold, which would depend on #526122: Autocomplete widget for taxonomy term fields.

Also doesn't delete profile data after migration so some other module can do something with it if necessary, like the profile_retro module.

Remaining TODOs apart from working out what do do with lists: allowed values for checkboxes and selects.

no patch. :(

grr, and I completely replaced my HEAD installation too. Untested re-roll.

:(

Since Field UI has no way to view or edit allowed values, I consider this upgrade 'good enough'. After committing this patch, then please `cvs remove -f modules/profile`

I'd love it if yched or bjaspan could glance over this real quick.

+++ modules/system/system.install	2009-08-22 16:00:04 +0000
@@ -2428,6 +2428,96 @@
+function system_update_7036() {

I'm afraid this needs to be a multipass update...
Proposed sctructure:
Initialization: get the list of profile fields
Then a series of passes to create fields and instances - one profile field per pass (I guess 5 or so would be safe, but it doesn't really make a difference)
Then a series of passes to migrate user data - N (5, 10...) users per pass
Could be simpler to write two separate updates.

If we want to rush this in before freeze, multipassing the update can possibly be done in a critical followup, that's a negociation with core committers ;-)

+++ modules/system/system.install	2009-08-22 16:00:04 +0000
@@ -2428,6 +2428,96 @@
+    $instance = array(
...
+      'weight' => $old_field->weight,
+    );

'weight' is now per context: $instance['widget']['weight'] and $instance['display']['full']['weight'], instead of $instance['weight']

+++ modules/system/system.install	2009-08-22 16:00:04 +0000
@@ -2428,6 +2428,96 @@
+      case 'textarea':
...
+        // Use the default text format.

The current data migration provides no value for 'format', which will thus be set to NULL, not sure if that's good enough.

+++ modules/system/system.install	2009-08-22 16:00:04 +0000
@@ -2428,6 +2428,96 @@
+        // TODO: get allowed values.

re moshe #49: allowed values for list fields are a field setting : $field['settings']['allowed_values'], and Field UI should let you edit this on a test field to check the expected format.

+++ modules/system/system.install	2009-08-22 16:00:04 +0000
@@ -2428,6 +2428,96 @@
+  $ret[] = array('success' => TRUE, 'query' => "The profile module has been replaced by the new Fields UI. For additional functionality such as adding fields to the registration form and migrating from date and URL profile fields, install the Retro Profile module.");

Minor, but do we want to hardcode the name of a contrib module that doesn't exist yet ?

This review is powered by Dreditor.

Just a quick note that 'profile retro storage' just meant it's worth leaving the tables in place even if we're not using them - i.e. I think it's safer for sites which have custom modules based on profile to leave data in place after migrating it - then we can either drop those tables in a later release or just let site owners remove them themselves if not needed. We can replace that with 'other contrib modules' or whatever, wasn't a serious suggestion ;)

Won't this patch, which only migrates the data without affecting how it is displayed, result in substantially less attractive display of profile data than the profile.module?

field_create_field()/instance() can throw exceptions; they should probably be caught and handled, no?

Will date.module and link.module automatically import remaining profile data? If not, the messages displayed are somewhat misleading.

The patch needs to be updated for Translatable Fields.

It's doesn't really matter, but it seems like field_attach_insert() would make more sense than field_attach_update(). Frankly, I wish we had not created the distinction, and had only field_attach_save().

"t seems like field_attach_insert() would make more sense than field_attach_update()"
Well, the user is already created, so technically 'update' is correct.

"Frankly, I wish we had not created the distinction, and had only field_attach_save()."
Possibly. We mapped this on nodeapi, though.

"The patch needs to be updated for Translatable Fields."
Right,

+    $accounts[$result->uid][$result->field_name][0]['value'] = $result->value;

needs to be

+    $accounts[$result->uid][$result->field_name][FIELD_LANGUAGE_NONE][0]['value'] = $result->value;

Patch applied, but I'm not sure what steps you want me to test this.

I didn't see an option to put the user field on the registration form.

It merely adds *support* for such -- as in, it won't accidentally discard the "does this field show during registration" data.

You need to run the other patch as well to actually SEE the option, this is ONLY the code dealing with migrating legacy profile.module data into fields.

So, testing would involve making a 6.x site, adding some profile.module data, and then upgrading to HEAD, and making sure all the data came along for the ride...

@bdragon

thanks for the clarification. Don't have time to test that unfortunately.

add tag

Not sure I'm doing things correctly, but here's my test results:

I installed the latest stable d6, enabled the profile module and created profile fields of each kind. Filled in some data, disabled the profile module.

I then replaced all files with the latest 7 dev, and applied patch #62.

Went to update.php, and all I see is a blank screen on my browser. Very weird since i have show php errors on, even a php error log file setup, but nothing comes up there. Same goes for my apache and mysql logs. Has the update process in d7 changed dramaticaly and I'm making a fool of myself? is anyone else seeing this problem?

Other than this not sure I can provide further information to this thread, although I realy want to help make this happen. I will be sprinting today in Paris, and If i can work on this issue testing and giving feedback.

The upgrade path from 6 - 7 has been broken for a while. However it should be possible to install HEAD, set up some fields, then apply the patch and update from there.

I think D6 -> D7 upgrade path is currently broken in HEAD, which makes testing this patch kind of difficult :-(

Adding tests for the upgrade path manually just seems like cruft to me to be honest, until we have a generic way to test update paths let's not special case this one.

Tested the #71 patch

The update process failed with the following message:

The update process was aborted prematurely while running update #7038 in system.module. All errors have been logged. You may need to check the watchdog database table manually.

The last entry on the watchdog was:

Notice: Undefined index: current_set in _batch_next_set() (line 375 of /home/jcv/drupal_cvs/drupal-head/includes/batch.inc).

There are also these for each user:

Notice: Undefined index: 7 in system_update_7038() (line 2568 of /home/jcv/drupal_cvs/drupal-head/modules/system/system.install).
Notice: Undefined index: 7 in system_update_7038() (line 2571 of /home/jcv/drupal_cvs/drupal-head/modules/system/system.install).
Notice: Undefined index: 8 in system_update_7038() (line 2568 of /home/jcv/drupal_cvs/drupal-head/modules/system/system.install).
Notice: Undefined index: 8 in system_update_7038() (line 2571 of /home/jcv/drupal_cvs/drupal-head/modules/system/system.install).

Those notices are in HEAD, not this patch.

Hm, I'm not sure whether it's a good idea to attach all profile fields to the user account object?

I agree, that this makes a lot of sense to do for small profiles. However, I built quite some sites with bigger profiles and I don't think you want to have all that profile data loaded into memory every time a user *account* is being loaded. Imo drupal misses a distinction between "user account" and "user profile" here.

Thus I think user profiles should be separate (fieldable) entities. Profile module could provide that entity as well as ways to easily get those profile for a user.

Regardless from that it still might make sense to have a fieldable user account, so users and *modules* could add further "account settings" as fields.

I agree with @fago above as far as I can - I don't know the ins and outs of this, but I have certainly been in cases where I've had big profiles. At the same time, I want to be able to flexibly get at user information, but the instances where these two need to be combined to get "one big profile" are much fewer, IMO.

re: #75-76, I'm not sure this is relevant. Unless I'm mistaken profile.module already loads all the profile data on every user_load(), so we aren't changing that by having the data in Field API.

- Should profile fields get a name like "profile_fieldname" to avoid field name collisions?

- Make sure the 'textarea' default format code is up to date with D7 default filter behavior (hasn't it changed?).

- Minor nit: Case 'list' does not set a widget type, but case 'textfield' does. Either both should trust the default or neither should. I suggest neither.

- I think you can just remove $delta from this:

+  $accounts[$result->uid][$field_name][FIELD_LANGUAGE_NONE][$delta]['value'] = $value;

- My comment from #55 the reference to date and link modules still applies.

Cowardly refusing to change from CNR to CNW or RTBC.

re: #75-76. I understand now. user.module calls field_attach_load(), whereas in D6 it did not, only profile.module did. So we do in fact have "profile data" on the global $user object whereas we did not previously. That's a valid point. You are basically arguing that users should not be directly fieldable, but that profile.module (or related code) should use hook_user_*() to make them so. I think if having users be directly fieldable is a mistake, it is a mistake that was made with the original Field API patch. It's probably too late to fix it now for D7 unless it is critical.

I don't think having users be fieldable is a mistake... But is there a way to differentiate between profile module added fields and just general fields on the user? The reason for this is you may want to attach extra information to a user that isn't really a typical "profile" field. And you may want to attach 50 fields to the user that are strictly profile information and only really needed when you're displaying the profile.

Sorry if this is a naive comment... I am not familiar with the fields api at all. Just coming at this from a user perspective and a person who has worked a lot with user profiles.

Michelle

Okay, I'll just come out and say it. Here is a proposed course of action:

1. Un-make users fieldable. This should be little more than removing field_attach calls from user.module.
2. Leave profile.module in core as is.
3. Plan on/begin writing a Fieldable Users module in contrib that uses hook_user and hook_entity_info_alter to re-field them, depends on date and link, migrates the data, and turns off profile.module. It might even allow different user bundles based on role, or all kinds of other cool functionality.

I never actually really liked users being fieldable anyway. Users are not content; they are an authentication and authorization concept. Profiles are content, but profiles are not users. We made users fieldable in the original Field API patch because we could, and because it was much easier than the other likely candidates, and we wanted a proof that other entity types could be fielded. But now we have taxo terms, comments, and blocks (on the way).

How's that for a last minute firebomb?

Oh, and:

4. Remove profile.module from D8 once everyone is comfortable with Fieldable Users in contrib.

re: #80. Yes, there is a way to differentiate between profile module added fields and just general fields on the user. Profile.module (or a contrib version of it) can define a new entity type (e.g. "Profile"), whose id is the user id (just to make it easy), and has no real storage of its own but is fieldable. Then on hook_user_$op(), Profile.module would perform $op on the Profile entity corresponding to the user.

I'm doing something like this for combofield... but to be honest I do not have it working yet. :-)

re: #83. Note that there is little/no difference between what I'm suggesting there and a Profile node type.

I see where you're going Barry, but for my money it would be a real loss for Drupal in general to not have fieldable users in core in D7. There's work out there in the form of content_profile etc that might help.

Could we not propose a re-write of profile, where we link users to their "profile data" via that, and make that a D7 core goal? It's late, but there is a very high demand for this as a use case, and it's sorta been in core already for some time.

Node_profile and content_profile solutions have been very frustrating and late to the game in D5 and D6 respectively, and with the continuing increase in profile data for authenticated users, I see this as a big step for Drupal to get this in core. Think of it as a "feature freeze", perhaps? :) Sorry if I've missed the point - I'm in the same boat as Michelle tech-wise.

If you have profile.module install, with fields on it, then you're already loading them into the $user object on user_load(). So the fact that sites without profile.module don't do that, is neither here nor there - since we're only migrating existing fields, not adding a bunch of new ones. Sites can then choose to use core user fields, or it'd be as easy to do a 'fieldable profile' module in contrib as to do it in core - since the user hooks are there either way.

Also the global $user object will only get a field_attach_load() call on it, if you explicitly call user_load() during the request. That's already a (slightly weird) optimization in core to deal with hook_user_load() and friends, and applies here too.

Regardless, I think leaving profile module in core, not using field API, for Drupal 7, would be a real mistake in terms of general WTF - better to do the whole job in contrib if we're not yet sure on the best case for core.

I think #83 is the most logical way forward, and I would attach the fields created by the current profile module to the profile object rather than the user object. This profile object is similar to a profile node type, but adapts to the special needs of users with a place to store the user id and some logic to be sure they are auto-created for each user or that a one-to-one relationship between profiles and users is maintained, while keeping some separation between user data and profile data. Then we would NOT load all the profile fields in every user_load() but instead do a profile_load() to get those fields only when we actually want/need them.

This new profile entity could be defined in either core or contrib, but I think we should attempt to get it into core with a fallback to leave it in contrib if we can't get it done.

I don't know what fields would be attached to users, and I go back and forth about whether we should leave both fieldable or turn users off and turn profiles on instead. If people start adding hundreds of fields to users or try sharing lots of fields between nodes and users it might create a real mess. The biggest disadvantage of leaving users fieldable is that we have a UI that makes it easy to add fields to users when instead we should probably only have a UI for adding fields to profiles, the thing people are most likely to really need and want.

And should it be possible to have more than one profile for each user, sort of equivalent to the profile categories we have now, or limit it to one profile per user and sub-divide it into fieldgroups?

So profile.module would do a profile_load() on hook_user_view()? That does sound better. User fields - well picture and signature springs to mind - unless we finally move those to fields and profile.module, which would be great, and we can probably do that if profile.module doesn't suck as much.

I started on a 'ghost entity' for translation sets at http://drupal.org/node/132075 - pretty much all we need is a profile_entity_info(), and field_attach_* calls in all the right places, and that's more or less it right?

@catch: If we move those to profile.module, that runs into the issue of performance. Some user/profile fields are needed a lot, like every time you display the user info on posts. Some user/profile fields are only needed on the profile page. If we have a clean line between fields attached directly to the user that are loaded always with the user and fields attached to the profile that are loaded only on demand, then it's not so much of an issue. But if you lump the signature and picture into the potentially 100+ profile fields, are you then going to have to load those 100+ fields with every node/comment so that you can get at the signature and picture?

Michelle

Ah yes, picture and signature are needed always so would be fields that remain on the user object. Maybe the distinction is that fields defined by core live on the user, since they are needed by core, and fields created by the UI live on the profile object, since they are not used by core. Then we could maybe find a way to turn the UI off for the user object so end users are not confused about where to add their custom fields. Modules could still add fields to users programatically using the API, if they had a need. Or maybe we just need to make sure to create enough help text to make it clear that you don't want to add your custom fields to the user directly, but instead to the profile.

This seems to be going in a similar direction to how nodes work in Drupal already, I think? We have a lightweight node object with nid, title, body and so on that is "core" (before D7) and then CCK augments that with the field API. It seems as if taking a similar tac with users wouldn't be awfully amiss? It's obvious (as we've already discussed) that users necessarily have "some data" associated with them, and may have more via the profile.module. I agree with Michelle's notion of what the dividing line should be (#89) and Karen's API-based comments in #90.

The notion of multiple profiles is a little trickier, but that's perhaps something that could be catered for with a bit of clever user.module API thinking?

Sub.

I think multiple profiles is a limited enough use case that it doesn't make sense to try and put a UI for it in core, especially if we have fieldgroups that take the place of the old categories. It would be nice, though, if the API was flexible enough that a "multiple profiles" module could be created in contrib without hacking core for those who need it.

Michelle

@Michelle, yep - that's exactly what I was getting at - as long as the way the API and user object refers to "it's profile" is flexible enough to manage it via contrib, then no problem. Just making sure the API is adequate is probably the biggest argument (outside of what's already been said).

@83: Yep, as said that simple profile-entity makes a lot of sense to me.

re: #83. Note that there is little/no difference between what I'm suggesting there and a Profile node type.

I don't think so. Having it as a node-type would be a big step backwards to the "everything should be a node" days ;) Nodes are typical "site content", which profiles aren't in general. Thus "profiles" would appear in a lot of cases where it wouldn't make sense. Making a lot of exceptions for profile nodes would be a way to go, but its' not only unlogical, it would end up in a mess ;)

Well the field API & entity controller are big steps forward to the "drupal entity" direction, which we really should continue to follow.

@Fieldable user:
If we have that profile entity, I don't think we should have UIs for attaching fields to profiles + users in core. But it might still make sense to let modules attach fields to users, thus they can make use of them and don't have to reinvent the wheel when adding other user account settings. So I'd vote for making users fieldable in core, but not by UI.

Ah yes, picture and signature are needed always so would be fields that remain on the user object. Maybe the distinction is that fields defined by core live on the user, since they are needed by core, and fields created by the UI live on the profile object, since they are not used by core.

Well that's pragmatical but not really logical. When a contrib module could add a field to the user object too, so when should it and when not? Thus I think $account and $profile would end up with wildly mixed fields.
What drupal is missing imo is a proper distinction between the user account and the user profile - think of the "access user profiles" permission in "user.module". Thus we should start separating them properly and add account related data to $user and move profile related data to $profile.
However if some profile fields are that often needed we could just add them to $user on load and rely on the entity loading caching - I think that should work?

Anyhow, I don't think 'signature' is a profile field. It's a typical account setting, thus should be kept in $account. Thinking of the picture as "avatar" it might pass as setting too, but being different from a possible profile picture. Thus the picture looks like a "border-case" to me, but as it's primary usage in core is "avatar" I think we could just keep it in the account settings. We could even rename it to "avatar" to make it's usage clearer.

I think multiple profiles is a limited enough use case that it doesn't make sense to try and put a UI for it in core, especially if we have fieldgroups that take the place of the old categories. It would be nice, though, if the API was flexible enough that a "multiple profiles" module could be created in contrib without hacking core for those who need it.

Agreed. Well we could support different 'bundles' for the profile entity, thus each bundle being it's own profile type (another profile). Profile.module could just default to the main bundle, but still it's API would be useful to contribs adding another bundle type. Anyhow
that's perhaps too much to do that late in the code-cycle... :/

+1 from me to all of #96. Sounds like fago and I are on exactly the same page. I don't know that my opinion has much weight since I'm not offering to code any of this, but it's the perspective of someone who has been deep in the whole user profile thing for the last couple of years. I've been pushing the "user account != user profile" view for a while.

Michelle

I think it's important we get this right in D7 core, even if it is late - the unstoppable march of the "social network" style site would leave us on a real back foot if we couldn't do profiles out of the box (even if only from an API point of view).

Just chiming in with what I hope isn't a further complication -- I like the idea of separating users and profiles, partly because of user_load implications, etc etc.
But also -- might it then be possible to have profiles that don't belong to a user? This would have useful applications for things like a CRM system.

Joachim - the concept of the node profile is not new, but I don't think this relates to users, or this proposed API / fields. You can have profile nodes in any case without having to link them to users. I'm doing just such a thing now. I suppose you mean "create a profile that *could* be used by a user, but doesn't have to be".

In which case, if the "user profile" is to be a fieldable user, then this flies in the face of this no longer being an arrangement where "profiles are nodes". This could have easily been the case in D6 with content_profile (some caveats notwithstanding) but I don't see that it fits here. Which is a shame, as I understand your use case.

Thanks for the thorough discussion here. My 2 cents:

I am generally very, very opposed to this recurring attitude of kicking critical functionality to contrib to deal with. Extraneous functionality like a minimum word count on body? Sure. Code written around constantly evolving standards that doesn't mesh well with the length of core's release cycles, like BlogAPI? Sure. Just plain broken silly code like Drupal module, especially when an equivalent module that's infinitely better is in core? Sure. But user profiles are mission-critical functionality, by any modern website's standards.

(off-topic rant) When we move features to contrib, the following things happen:

1. We lose the oversight of the 1,000 people viewing the core queue every day, as well as the dedicated core maintainers.
2. We over-burden what is typically a single contrib maintainer with a bunch of code that they did not write and then task them with keeping it humming without any help from their peers.
3. Our end-users get the delightful experience of searching through 4,000+ Lego bricks trying to find one grey turret corner piece to help build their castle. In amongst a pile of other, very similar-looking grey turret corner pieces that all appear to do basically the same thing, but choosing the wrong one causes the entire left tower to collapse and fall down, taking the entire structure with it. :P

So. A gigantic, flaming -1 to pushing (all of) fieldable users to contrib. We've got 4 weeks to fix this, and fix it right, and do it here in core. So let's! :) This issue was granted an exemption for a reason.

In general, I support fago's #96, and agree that user profiles are not, never have been, and never will be nodes. But making a separate profile entity type that's different from the user entity type seems like it makes a ton of sense, and is even quite powerful for people who know what they're doing to designate certain fields as always available, and others only when viewing a page like user/3. I'm not sure that we should not offer the UI to do both, as long as it's clear what the ramifications are. People could then make the call individually about whether user picture qualified as an "always there" field or not. But I won't get too picky about it.

fago, is this something you'd have time to work on over the next couple of weeks?

Awesome, webchick, and I agree that strong user profiles need to be in core. I consider the whole "profiles as nodes" movement to have been a necessary evil because of the mess that was profile module. This is something important not just to social networking sites but any site that allows users and wants to have a profile even a little more useful than the dumping ground it is now.

I'm not able to help out on the coding side but I'll try to help out in other ways since this user profiles and I have a long history. :)

Michelle

^ Letter for letter, what Michelle said.

NikLP -- I'm saying that if as being proposed here, a profile is a different entity from a user, but linked to that user, then *if* we make it so the profile to user connection isn't a requirement, then we can do potentially cool things like maintain a profile for someone who is not a user. Which is what CRM-type stuff needs to do, which would be really cool to do in a contrib module.

I'm just raising it as something to bear in mind when designing the architecture here in core -- allow a profile object to exist without specifying a user to be connected to.

There is a hook_entity_info_alter() to do any crazy edge-case needs. Let's please focus on fixing the actual issue here, as time is running short.

I'm just saying consider this case before making the uid column on the entity table required or unique is all... and CRM is potentially a major application of Drupal.

I would say a special nodetype vs standard user account as profile fields container really depends on your user case. Some of my latest cases:

- travel forum: all I need is to attach weblink and textfield to user objects to get some simple profile info for users + eula checkbox for registering. Using some supercharged profile functionality would be total overkill. Making simply drupal user accounts fieldable would suit me just fine, for this case user account is tightly coupled with profile data.

- theater site: users accounts and user profiles are decoupled: users are just couple of content admins, profiles are created for all actors and directors etc. There are some cases when user and profile are linked: several of younger actors are eager computer geeks so they need way to log in and somewhat be able to extend their profiles. Likely implementation: a special nodetype for profiles, a nodereference attached to user account to link to specific profile and views to overload user/x page with node-profile data.

If drupal user accounts are fieldable, i can always use reference fields to point to any number of extra profile nodes and create neccessary views. Contrib module could also set this system up using the method above. No need to bloat core with extra profile nodetypes.

That's very true actually - a simple contrib mechanism such as that used by content_profile to couple the user to its node profile could easily be employed at which point you could have node-based profiles again very easily. Views_attach module also does a handsome job of displaying things like this on node displays (by latching fields onto nodes via node ref or whatever - via views obviously).

Altho joachim's point is that he wants the user profiles to all be "together in the mix" regardless of user's existence. Unfortunately, whilst the use case is self-evident, it's also rather niche, and nothing immediately springs to mind re how to fix that in an API way.

Actually, I'm having a bit of a tinker with profile.module and hook_entity_info, and I reckon it's doable the way you'd do it anyway:
Profiles are entities.
The categories we had in profile D6 are the bundles (like node types).
Each profile should have a pid, because having multiple categories implies more than one profile per user.

And the more I think about it, the more it seems like not an edge case at all. Lots of modules want to store information about people that maybe aren't users. Eg Ubercart could store billing addresses and so on as a profile.

We just have to write the profile_save API in such a way that doesn't insist on a non-zero value for the uid field.

> And should it be possible to have more than one profile for each user, sort of equivalent to the profile categories we have now, or limit it to one profile per user and sub-divide it into fieldgroups?

So pondering this one now...

A. One profile object per user. Fields are grouped into categories which make the profile tabs
Pros:
- reusing existing components such as fieldgroup.
- simple: one profile object is the entire set of data about a user
Cons:
- probably need to abuse the field API and the fieldgroup system to load only data from one fieldgroup at a time, eg when viewing a user profile tab.
- a profile is the whole entity, and so if you have an 'address' tab you couldn't then allow a profile to have more than one address. (But then, would an address not be better as an entire field type perhaps?)

B. Profile bundles. We define profile categories, which are analogous to node types. For the sake of example, say these are 'personal' and 'business'. A user could than have one personal profile object, one business profile object, and the two collated together would form what we think of as their 'profile'.
Pros:
- extensible: you can have more than one profile object in each category.
- only load the fields we care about on each tab, or on other output.
Cons:
- lots of ID keys floating around. Each profile object would have a profile object id (poid), and a uid to say which user it belongs to. This would be sufficient, but this then brings us to the potential contrib cases I mentioned in #104: it would be very very cool to allow modules such as Ubercart or a hypothetical CRM to create profiles without a user (such as billing address, and so on), which they can then tie to users when that person creates an account. In other words, I think that there should be a profile set ID too, which gathers together all the profile objects that belong together.... which in most cases is a mere duplication of the uid, and we'd need a way to autoincrement it without a master table, and it's all a bit meh :/
- we've no idea how Views is going to handle the FieldAPI in core -- whether it'll define one lot of data for all fields, or do it per-entity to cover any special cases. But I've a feeling this won't be nice for views to deal with.

Any thoughts on this?

>fago, is this something you'd have time to work on over the next couple of weeks?

I'd love to, but unfortunately I'm already rather busy with working on #551406: Centralize entity properties meta data and I'm going to leave for a vacation on Oct. 5th. So I don't feel like being the major one behind this, but of course I'm going to help where I can.

@user-relation:
I agree that it makes sense to allow profiles not related to users in contrib, but not dealing with it in core.

@#110:
I thought also about how to do this best, and I'd follow route B. Directly map profile bundles to user-categories, but add a flag to hide profiles from the user categories to hook_entity_info(). That way modules can easily chime in and display the form anywhere else, e.g. as tab directly at /user/X.

>I think that there should be a profile set ID too, which gathers together all the profile objects that belong together.
I don't see why we need that? It might make sense to bundle together multiple not-user related profiles, but that's something a contrib can deal with.

@views integration:
I don't see any troubles here? Having a simple profile id - uid mapping should be fine for views.

>>I think that there should be a profile set ID too, which gathers together all the profile objects that belong together.
> I don't see why we need that? It might make sense to bundle together multiple not-user related profiles, but that's something a contrib can deal with.

I grant that a profile set ID feels wrong to me. It's storing meaning that is already in the uid, and that does not seem right at all

On the other hand, that means that a contrib module that implements floating profile needs to do one of:
- maintain its own profile set ID - profile ID table
- add a profile set ID field, and some sort of autoincrement mechanism that works through FieldAPI.
- hack the schema and add the field to the profile table
- define its own entity type, meaning it completely reimplements profile module, data, UI and all.

Letting contrib tackle problems is fine when there is a clean way for contrib to bolt on, but core needs to lay down that groundwork.
Are there possibilities I've not thought of?

As a quick note: I really think separating users from profiles would be great and want to give another example where this makes sense. Simplenews currently can't store personal information about subscribers - with profiles not being attached to users this would become much easier.

If this doesn't get in, can someone consider something like an extended existing Profile module. I hacked up an example earlier and attached it to an old issue so not to mess up the queue here. Since that issue was about a taxonomy field, I added a simple taxonomy field, but there is no extra functionality other than this.

http://drupal.org/node/83902#comment-2060014

This is a patch of my tinkering so far, as I'm fairly snowed under with work at the moment :/
This just defines the profile entity, defines the schema, and that's about it.

I don't know what kind of UI would be appropriate here. I think something slightly more complex than profile's existing automatic category creation, as there may be data we want to store on categories like the flag fago mentioned.

So this is largely frankencode ;) but enough to get the ball rolling maybe?

Ok: I'll reopen this: #301071: Remove profile module from core.

Subscribe.

- We need signature + picture as fields on the user. These are not profile fields.

- Other profile fields belonging to Profile along with own profile bundles sounds about right.

- Sounds like we need to introduce support for fieldable, but non-field-UI-extensible entities. Hence, modules can add kinda "locked" fields (like signature and user picture), but the user can only configure and is not able to extend with further fields.

- Why do we want to do that? Because fields like signature/picture are duplicating a lot of awful code that's already (or in case of image field about to be) cleanly implemented as fields.

- Regardless of whether fields are provided by User or Profile module, the fields need to appear on the user form. I'll try to resolve #367006: [meta] Field attach API integration for entity forms is ungrokable.

- Moving Profile module to contrib won't fly.

- joachim's proposal in #109 of turning ex-categories into bundles makes sense. However, I totally disagree with (user) profiles being completely detached from users, like in the given example of ubercart wanting to store customer data for non-users. If you want to do that, then you create your own entity, or simply use nodes. A profile is a user profile, and should thereby have a direct relationship to a uid.

Scope creep, but indeed a nice point raised by fago in #96: The "access user profiles" permission and entire output should belong to Profile module. That would make the clear distinction we currently miss. theme_username() has a preprocessor now, so Profile module would basically be able to preprocess a link to the user profile in there - if not, no link. Probably too much for D7 though.

- In general though, this issue is partially also touching the issue of #192056: User's raw login name should not be output directly: We have theme_username(), theme_user_picture(), and theme_user_profile() hard-coded in various places. Given fieldable users, fieldable profiles, user pictures, RDF, and whatever else, we now have countless of potentially renderable data for a single user in D7. But we don't have build modes for users. And a themer has absolutely no way to take control over the output of a "user" in a certain place (it's an all-places-or-none thingy).

Tagging.

> A profile is a user profile, and should thereby have a direct relationship to a uid.

True, but a profile is also information about a person, who happens to also have an account on this site.
Lots of modules need to hold information about a person who happens to visit this site, or who has never even looked at this site, and in both of these cases, that person may eventually become a user of this site, at which point the connection to the uid should be made. I think profile has to consider these use cases enough to leave a space for contrib module(s) to plug in.

Otherwise, having contrib define a 'floating profile' entity means a repetition of UI work when it attaches to a user, and worse, it probably means that site developers will face one of these architectural decisions in the set-up of their site that they probably won't even know about.
What I mean is: where should a site builder add an address field? On the profile? On the floating profile? What if they've already built their site and later on find they need Ubercart?
Hypothetical floating profile entity module could just add all the fields found on profiles to the FPE, but then users either have an object of the profile entity or the FPE, depending on how they first came to the site.

So I'm starting to think the cleanest cut is to allow uid on profiles to be null, and for floating profile module to add a column to profiles for fpid -- least bad solution.

Sub

I have a use case for #121. I run the camera club's site and most members don't use the website. But any member could potentially decide to start using it. Because I use the profile data for the roster, I made dummy user accounts for every member. Sometimes a member forgets I did that and signs up with a new account. It would be much easier if profiles could be detached from literal users and attached when needed.

I can understand this is an edge case and we don't want to put tons of stuff in core for this. But simply using a profile ID as a key rather than a user ID is a simple way core can tie the fields together and let contrib sort out how to make use of profile fields that aren't attached to users. Core would only concern itself with ones that have a UID and ignore the rest.

Michelle

For #121 and other similar comments, I think I agree with sun for the most part. For core, user profiles should be straightforward and solve the specific issue of handling data about a drupal user. For more CRM type situations or edge cases where an admin is maintaining profiles on behalf of other people, we have the awesome flexibility of drupal to fall back on. I'd rather see flexible profiles for real users get in before oct. 15 than see scope creep stall this great opportunity for API unification.

subscribing... also wanted to get some of the field ninjas to take a look at #563000: Provide upgrade path to file which has a similar aim.

Yeah, it does seem to me there should be a way of making a generic upgrader that takes schema-like information and turns it into fieldAPI fields and data.

I think getting at least one "field ninja" on this would be good, even if it is to just create the entity framework to kick start things. I was off work with the flu yesterday and had my first play with the Fields API seeing if I could help with this issue. It is a fairly large API to get started with, so I only ended up with a big pile of crud :\

Since this does mean redoing the schema from scratch, I thing we need a proper primary key on the category (cid / cpid?). I've lost count of the number of times the database guys around here have complained about this. Also, for consistently with other modules, body_label => help? Lastly, how about adding a module FK to allow contrib. modules to interact using the new schema? Changes against #115

<?php
      'cid' => array(
        'description' => 'The primary identifier for a profile category.',
        'type' => 'serial',
        'unsigned' => TRUE,
        'not null' => TRUE,
      ),
      'name' => array(
        'description' => 'The human-readable name of this category. Used as its label in user profiles.',
        'type' => 'varchar',
        'length' => 255,
        'not null' => TRUE,
        'default' => '',
      ),
      'machine_name' => array(
        'description' => 'The machine-readable name of this category.',
        'type' => 'varchar',
        'length' => 32,
        'not null' => TRUE,
      ),
      'description' => array(
        'type' => 'text',
        'not null' => FALSE,
        'size' => 'big',
        'description' => 'Description of the category.',
      ),
      'help' => array(
        'type' => 'varchar',
        'length' => 255,
        'not null' => TRUE,
        'default' => '',
        'description' => 'Help text to display for the category.',
      ),
      'module' => array(
        'type' => 'varchar',
        'length' => 255,
        'not null' => TRUE,
        'default' => '',
        'description' => 'The module which created the category.',
      ),

?>

Alan

I implemented the basic profile entity CRUD, needs review -> http://drupal.org/node/301071#comment-2081970

As suggested, let's handle that over there and keep this issue for the migration.

Just a note that it looks like work on this has stalled. Pinging folks to have a look at #301071: Remove profile module from core where fago's started a bunch of the work.

sigh. :(

We can discuss it in a new issue, but I think we need to go back to #24 where flobruit makes the case for moving profile module to contrib. he has agreed to be the maintainer. There, we will work on upgrade path.

For me, it is a complete non-starter to ship D7 with profile module. There will be be docs pages and blog posts everywhere saying "Don't Touch That."

I'd be up for co-maintaining that. I was just starting to get to grips with github this morning with a view to continuing work on profile module :)

Yeah whether it's a profile module in contrib or a core release blocker I'm neutral on, but shipping with it is horribleness.

I don't see what choice we have, really. We can't ship a CMS in the year 2010 that doesn't have the native ability to create dynamic user profile pages. We also can't strand our users without an upgrade path. Remember the "Drupal will break your code, but not your data" mantra? I agree it's not ideal from both an implementation and UI perspective that our built-in Profile module doesn't leverage this great new Field API we worked so hard to get in. But the fact is, Profile module works "good enough" for most people, including Drupal.org, and Profile module's UI/functionality was already "other" (compared to CCK/nodes) in D6. So the current situation isn't a regression.

We had 6+ months since field API was committed, plus an additional 6 week extension (calling this issue out as an explicit exception in order to rally support) to figure this out. If a solution hasn't materialized in the core queue in that time, I fail to see how it's going to resolve itself in contrib by the time we ship D7.

I am, however, confident that a profile module leveraging Field API will eventually appear in some form in contrib, where it can take its time figuring out how best to address some of the challenges outlined here, and be refined over the coming weeks and months into something awesome, which can hopefully move straight into D8.

Huh? Fields can be attached to users in D7 using the GUI. We certainly have dynamic user profile pages, even without profile module.

I would be embarrassed to ship with code that noone is supposed to use in D7. We would be keeping profile there just for upgrading sites. But even that is silly. Every D6 site that uses CCK is already going to have to go to contrib for their upgrade path. Going to contrib for the profile module upgrade is going to feel consistent.

Huh? Fields can be attached to users in D7 using the GUI. We certainly have dynamic user profile pages, even without profile module.

Agreed. The basic functionality is already in core. What's missing that profile does is:

1. User registration integration
2. Permissions
3. Listings
4. Categories

As was already spelled out in the other issue. I fully agree that requring contrib modules for a data upgrade path is fine, even for data.

"We won't break your data" doesn't exclusively rely on core - we removed synonyms and related terms without an upgrade path for that data too - since there's no implementation in core (or contrib), it's up to contrib and custom code which was relying on that to migrate it to appropriate field storage.

There is a huge difference between taxonomy synonyms (a feature which probably 4 sites in total are using) and user profiles (which is basically a critical staple piece of functionality for every single website on the planet except for single-user blogs and brochureware sites).

And yes, the problem with Profile module is it does a lot more than simply add fields to users. The field visibility feature is particularly problematic, since if we don't provide an upgrade path for that, we leave users' data vulnerable. Content Permissions module didn't make it into core (which I'm totally fine with), but neither did an alternative option for Profile module's use alone.

Migrating Profile module to Field API is a complicated problem, as evidenced by two 100+ reply issues on the topic, and it's something we needed to have done by now, not something we should start trying to rush out the door 2 weeks after code freeze. Darwin's law dictates that if this was actually meant to be, someone would've done it. Hopefully those someones will appear in contrib and solve this problem properly in D8.

@webchick - I don't really get your argument. All we are suggesting now is to move profile module to contrib. There, users will get a full upgrade path to fields api, and will be prompted to install the fine field permissions module for d7. The other minor points in #136 already have reasonable solutions coded or recommended in this issue (use Views for listings, use a new small module for reg form integration, ...).

Lets ask the docs and Ux teams if they think it is a good idea to have two different ways to build out profile pages in core.

I would rather remove the exposure of Field UI for users from core than bank on a mystical profile upgrade path magically appearing in contrib given that the focused energy of 7-8 core developers over the course of 2 months couldn't pull off. In fact, I already made an issue to that effect but I can't find it just now.

My arguments are:

* Drupal core shipping without Profile module functionality would be casting us back to 2003.
* The current situation of Profile module sucking and being inconsistent with everything else is no worse than we had in D6 and below. It comes down to a major "Wow, that sucks" that it doesn't do what it does leveraging Field API. This is not worth stranding 100,000+ users over.
* I have absolutely no reason to believe an upgrade path for Profile module will bubble up in contrib in time for D7 to ship, given the lack of progress on this patch and lack of organization around such an effort in contrib in the meantime.
* This is a really thorny problem and we should take our time and solve it right.

All of which screams "D8" to me. And FWIW, Dries agrees. Is it optimal? Hell no. But despite all the promotion of this issue and efforts that went in to trying to solve it, we simply didn't get it done, so this is where we're at for options.

There's 'putting us back to 2003' in terms of raw features available in core, or there's shipping with code and features which hasn't been updated since 2003, expecting people to locate a contrib module to get something up-to-date - by which time they may already have data in Drupal 7 core profile module without the knowledge to migrate that data - which while not the hardest part of this issue, isn't easy either.

Even if this patch was fixed in time, users would still have had to install contributed modules to get an upgrade path - for example date and listings.

Also the issue with these two patches isn't that an upgrade path couldn't be worked out - that's been there for ages. What's been missing is the exact requirements for what needs to be in core vs. contrib - and then getting that implemented once these were stated, something which happened much closer to code freeze than a couple of months.

"there's shipping with code and features which hasn't been updated since 2003, expecting people to locate a contrib module to get something up-to-date - by which time they may already have data in Drupal 7 core profile module without the knowledge to migrate that data - which while not the hardest part of this issue, isn't easy either."

To a user, what do they care if the module they use isn't up-to-date by API standards? Answer: they don't. They care about being able to set up dynamic user profile pages in their CMS. So they'll have something usable on release day that has the same limitations they've had to deal with since Drupal 4.whatever. If they need something more, they will use the forthcoming Awesome Profile module in contrib (which will have an upgrade path baked in, since it would have to in order to be a viable contender for D8; so the user never needs to bother themselves worrying about how to migrate that data themselves).

>To a user, what do they care if the module they use isn't up-to-date by API standards? Answer: they don't.

Well, but this also affects users. First off users can't use the same features there as they are used with elsewhere on the site, e.g. where is the filefield or why does it look different? Secondly it can't be extended as with usual field types. So in the end users have to care.

I have to back webchicks point of view in #139. It seems far to late in the development cycle to get this right in time for the release of Drupal 7. The permission issue by itself is a complete upgrade blocker on most of our sites.

Simply moving profile to contrib to free the development of core and to allow the Profile module to become "fieldable" seems like a big gamble now. So how about the following road map?

Drupal 7

• Profile stays in core and the Profile "fields" made extendable.
  This requires a minimal amount of work, about 4 hours work to do the basics!
• New fieldable contrib. module maintained by flobruit and joachim.
  Maybe see if pwolanin or ax would surrender the member / members project for a good representative module name for the task (both projects are old Drupal 5 projects)
• Provide upgrade path from Profile to [NewProfile] as existing functionality is covered.
• Good documentation letting users know the road map

Drupal 8

• Profile is abandoned or moved to contrib.
• [NewProfile] module moved to core.

or

• [NewProfile] module is merged into Profile and [NewProfile] is abandoned.

From a commercial point of view, clients find the old profile and webform module interfaces easy compared to the cck interface. Of the 100 or so clients we have had, at least 30% happily modify these, but I can only think of one client that modifies cck fields.

Once a module is extendable, the community quickly fills any missing requirements. The hacked non-field patch supplied in #83902: profile field types and attributes has enabled us to create about 10 new field types with minimal work in the 3 sites that have used it so far.

Side note about upgrade: as explained in #366364: [meta] Data migration from D6 contrib CCK fields to D7 Field API,

the upgrade cannot be a regular, one-off process running 'silently' along with other update.php updates (because core or even one single contrib module can't predict how to migrate date fields or wicked_contrib_field_type fields). The upgrade process needs to be iterative, provided by a cck_upgrade module that exposes a page with the list of D6 fields that it's able to migrate given the current state of enabled modules. Press 'submit', eligible fields are batch-migrated.
Until date.module D7 (or a submodule) is enabled and implements hook_cck_upgrade() or whatever, stating that it knows how to migrate date fields, your D6 date fields are not visible in D7. Come back to the 'migrate fields' page when you have enabled date module.

Same thing holds for profile migration : date (profile) fields, url (profile) fields, (profile) field permissions, require some plugin-modules whose availability we don't control.
We could imagine that this cck_upgrade (or field_upgrade or whatever) module handles 'profile fields' migration with the same workflow and benefit from the same UI and code flow, only going through a slightly different set of pipes and hooks.

I agree with #140, aside from being listed as an exception to the code freeze, this patch definitely seems to have suffered from lack of vision/leadership on the approach to take. I know I personally was monitoring this issue to be able to chip in once there was some consensus since I didn't feel comfortable blazing the path on my own.

Also concur with Moshe and others - this is embarrassing to say the least. Profile module was already a dog in D6 and suggesting that its ok to continue with it being a dog in D7 is, well, not something I want to show other developers or clients. At this rate, we might as well use the same argument for profile.module when D8 rolls around. I would never suggest that any drupal contributor is lazy, but this definitely feels like taking the easy way out in order to ignore an less-than-glorious task.

In regards to the upgrade path and other approaches, I would also point out the http://drupal.org/project/content_profile module which many people have already been using as an alternative to profile module.

Sometimes it sucks to make the hard call, but I would see this as a release blocker and would much rather see a delayed release than see this continue. I believe that a clear outline of the approach to be taken (and the intense focus a release blocking issue would gather) would quite rapidly produce something very credible and that we would not feel ashamed about. This will leave plenty of room for improvement for profile in D8 (think about the likely improvements/changs to fieldAPI if nothing else) without the further hurdle of being a dog

In case it not obvious or is forgotten, it seems there are several people in this thread who have offered to help with this effort - myself included.

"Sometimes it sucks to make the hard call, but I would see this as a release blocker and would much rather see a delayed release than see this continue. I believe that a clear outline of the approach to be taken (and the intense focus a release blocking issue would gather) would quite rapidly produce something very credible and that we would not feel ashamed about."

Had this issue achieved a status of "80%+ of the way there" before feature freeze, we could probably totally make this a release blocker. However, it did not. By my estimation, it did not even achieve 25-30%, since major architecture questions are still being hashed out. Perhaps if some of the people I see coming out of the woodwork now to lament this decision had helped out people like flobruit, fago and joachim much earlier in the process, we wouldn't be in this situation now. :P But I digress...

We already tried the intense focus thing; this issue was one of only 10 features that were explicitly exempted from feature freeze (despite the fact that it hadn't really gone anywhere yet), blared far and wide at Drupalcon Paris, on the Drupal.org front page, on Drupal Planet, on Twitter, etc. It still wasn't enough to rally the necessary support (brainstorming, code, architecture reviews, tests...) to get this in. There is absolutely no basis for the belief that by granting a second extension that this problem will magically somehow get solved. And I'm not going to postpone the release of Drupal 7 on a myth...

I'm getting a little tired of rehashing this over and over again. Folks who want to see this resolved in the D7 release cycle (and core for D8), please work with flobruit, fago, and joachim on the Awesome Profile module in contrib. Or, continue the brainstorming about how to solve the problem here where you have everyone's attention. But the decision to leave good ol' crappy Profile module in D7 core is made, as far as I'm concerned.

@moshe: "For me, it is a complete non-starter to ship D7 with profile module. There will be be docs pages and blog posts everywhere saying "Don't Touch That."" --> totally agree, make me one of THOSE t-shirts, too.

@webchick: "We can't ship a CMS in the year 2010 that doesn't have the native ability to create dynamic user profile pages. "

Should we ship a CMS in the year 2010 that uses code from the year 2003 (as you pointed out)?

And, of course, I get to point out that profile isn't a) enabled by default out of the box and b) has no fields defined out of the box when you turn it on and c) what use case are we supporting with dynamic user profile pages, exactly?

@webchick: "To a user, what do they care if the module they use isn't up-to-date by API standards? Answer: they don't"

Which users? Which end users? Which use case? (noticing a theme?) The developer and site builder users -- who are apparently targeting since we are abandoning good OOB functionality -- care a lot.

+1 for profile to contrib, ESPECIALLY if it continues to not be enabled by default in the default install profile.

EDIT: I know what you're going through, webchick, and I guess I apologize for riding in late here. The issue, of course, being not enough people focusing on core work to get this in under the wire. This is a last ditch attempt to, perhaps, visit a "third way" - of core removal.

Say it ain't so! At times like this, I wish I could code worth a damn. D7 was supposed to be the release where core caught up to what was going on in contrib. Despite being a highly visible feature, I don't see why removing profile module is completely off the table. Contrib is needed for many common things that a CMS should have in 2010. Core doesn't have to do it all.

As an alternate to removing profile, perhaps a stripped down effort could be completed at the last minute? In #136 Catch posted a list of what profile provides but is still missing:

1. User registration integration
2. Permissions
3. Listings
4. Categories

I don't see removing features 2-4 being a problem. Field permissions will be available, as will Views and Taxonomy. If data migration and user registration integration are the only big blockers, would the scope of work be possible in a shortened time frame?

Guys. If you all put 1/100th of this energy you're spending raging here on hunkering down and building a replacement profile module in contrib, it might very well be done by now, and maybe we'd have something to talk about. :P~

On a more serious note, it's getting supremely irritating seeing a bunch of comments from people at #130+ who were nowhere to be seen at #130-. You all had ample opportunity to help with this, and you didn't. So it didn't get done. Them's the breaks.

@webchick: apologies, I'm trying to triage and (still) advocate for regular end users. I agree that "doing it right" is no longer an option. I'd rather we didn't ship it wrong, and am attempting to explore options - switching tactics now that we are past the point of no return.

Would you like that opened as a new issue?

Someone should open up development on a D7 contrib field API-based profile module asap, get it ready before rc, then if it's there I think we could probably change Drieschick's mind on ripping it out of core if the upgrade path is ready and waiting with open arms.

Agreed -- and even if it doesn't make it, then it's still work that's done.
In contrib we could move quicker on this as we could get basic stuff committed then build on it, and have people (hopefully there are TONS of potential testers!) try dev releases rather than patches.

Someone should open up development on a D7 contrib field API-based profile module asap, get it ready before rc, then if it's there I think we could probably change

Just a reminder that such work *has already* started on #301071: Remove profile module from core. The leadership on that issue is not clear, though.

What, is it over? Ah, dangit. :-)

First, I gotta applaud webchick for the demonstration of leadership here. She did make the tough call, and without saying that I necessarily agree with it, I'm glad we have the kind of leadership that can make the unpopular choice based on present reality, instead of betting on unmaterialized dreams and caving into pressure.

Second, subscribing. I look forward to helping with the new ProfileAwesomo contrib module that will be ready for D8.

#151 sounds good!

Oops, should post this here too: #623210: Architecture and roadmap.

@fago, flobruit, anyone else interested: do you want co-maintainership?

I've also seen #141419: Full rework of profile categories improving data model and #301071: Remove profile module from core around. I'm sure there are others. Should those be set to duplicates/follow ups?

#301071: Remove profile module from core is/was about reworking the module, leaving this issue to be about data migration.
#141419: Full rework of profile categories improving data model I didn't know about, but looks like it's been made obsolete by FieldAPI. I will take a proper look at it when I have time to see if there are any ideas there we should use.

Is there a migration path from profile fields to the field API, or were profile fields completely depreciated without a migration path?

Profile module is no longer in Drupal 8. It was kept for Drupal 7. If folks want to work on migrating data out of profile, this issue has the best effort for migration code.

For D8, we do need to move user picture and signature to field api. No issue out there for that AFAICT.

I don't understand what you mean by closing this as 'wontfix'.

I thought Drupal had a policy of not leaving people's data stuck in a dead-end? Profile module being gone from D8 does not change the fact that people who used Profile module on their D5, D6, and D7 sites need their data to still be usable when the day comes that they upgrade or migrate to D8.

Maybe better to point to the successor, profile2, albeit that the process has not started yet.

#1068446: Migration path from core Profile

Ah, I see -- yes #1261576: Profile module data is not upgraded is the issue this is a duplicate of.