Remove profile module from core

RIP Profile Module..... Subscribing.

I just asked Barry at DrupalCon about what would be required to remove Profile module from core, and he made a point that the Profile module actually does a lot for the user profiles that shouldn't be covered by the Fields API:

• Provides categorized profile information delegated into tabs
• Sticks profile fields into the user registration form

So, it makes sense to just replace the way data and forms are managed in the Profile module with the Fields API, while not completely removing the Profile module.

Tag tweaking and subscribe

#394720: Migrate profile module data to field API is more recent but has a patch, marking this as duplicate.

Let's reopen this to be about the data architecture, and leave that other issue to be about migrating D6 data to the new model, as suggested by flobruit on that issue.

I posted a very rough patch over there to get the ball rolling; there's also plenty of discussion about how how to structure it.

@#3: yep it does more, but I think this code has to change significantly when working with fields. Thus fixing title.

I took the start from http://drupal.org/node/394720#comment-2060556 and implemented the basic profile entity as discussed in #394720: Migrate profile module data to field API. It comes with a handy function to load profiles per user (profile_load_by_user()), but allows contribs to do even profiles unrelated to users.

TODO: admin UI, integrate form into user categories, display profile, registration integration..

Hm. I don't understand why this was broken into its own issue, but allowing fields to show up on registration form is a critical feature of Profile module that we can't lose during this conversion. I care a lot less about showing fields in different categories, since most clients of mine actually want me to *undo* that behaviour, and FieldGroup module in contrib seems like it could handle this well enough.

Hm I don't think we should add anything related to fieldgroups here, I talked about integrating with hook user categories like profile module did. For core I'd just map each profile type to a category, but allow contribs to disable that.

Started implementing user categories integration, seems to basically work for me (needs a simpletest).

update: ah sry, now I understand what you meant. Well we could also just ship with one default-profile type and don't add an UI to manage profile-types to core? That would also make user registration integration much simpler - I didn't had a look at the new AJAX stuff yet and whether it breaks when we move fields using it into a fieldset, so probably for that restricting to one profile type makes sense.

Well we could also just ship with one default-profile type and don't add an UI to manage profile-types to core?

I think so. There are definitely use cases for advanced profiles but I'd rather people download the advanced profile module (or whatever) and not burden every user who just wants to add a couple fields to user profiles with the UI overhead.

It would be nice though if the upgrade path from 6.x -> 7.x though had the capability of programmatically creating core representations of categories... but mostly I'm stressing out about the time here and really don't want to ship yet another version of Drupal with our current Profile module and its horribly inefficient data storage. :( So keeping the scope in check here would be very much appreciated.

Updated patch:
* Implemented basic display of profiles, although I think it might make sense to add a separate template for profiles and integrate that on user-view. Thus profiles could be easily listed separately from the user-view.
* Imo user.module needs a cleanup to implement the user account <-> user profile distinction. I've not touched that yet, probably best this would be a follow-up.
* Implemented basic user registration support which just displays one profile there. From looking at the code displaying multiple profiles in fieldgroups should theoretically work fine as long as the profiles have distinct fields (as all goes in the same form values..).
* Added a simple 'main' profile with a 'full name' field that's auto-created during installation. Currently you can edit its fields at 'admin/structure/profiles/main/fields'.

@multiple categories:
Well, this patch is already capable of dealing with them, so adding multiple profiles during the upgrade would be easy. However without any UI users won't be able to edit their profiles / fields any more... So if we do so, I think the UI should be in core too. It wouldn't be hard to do anyway, I'd just follow admin/structure/types and add admin/structure/profiles - which lists profile types and allows edit + deletion (if not locked). At 'edit' we would have just the possibility to change the 'label' and the 'weight' as well as the tabs for managing fields.

As it looks to be quite simple, I think that UI would make sense.

@registration:
* We should probably move the fields in a fieldset per profile.

TODO: more tests, API docs.

I'm currently on vacation, so I can not easily review patches right now, let alone apply and test them. Here are a couple remarks from a visual review.

+    // Auto-create a field for the full name.
+    $field = array(
+      'field_name' => 'field_fullname',

Plz keep the 'field_' prefix for UI-defined fields. We should try to enforce the good practice of prefixing field names with the name of the module that defines them 8'body' being kept as a handy, legacy exception), so I'd suggest profile_fullname.

+      'weight' => 0,
+      'settings' => array(),
+      'widget' => array(
+        'type' => 'text_textfield',
+        'label' => 'Text field',
+        'settings' => array(),

weight is per context : should be under 'widget', and under each build mode display settings if any
label looks wrong
no need to provide an empty array for settings, the default will be filled in automatically

Shouldn't profile_type_save() include a call to field_attach_rename_bundle() when a profile type is updated with a different name ? field_attach_delete_bundle() is probably needed too, except there's currently no 'profile type' deletion ?

There's a gotcha if profile-level fields are included in the same form than user-level fields. Nothing forbids a given field to have instances on both user and profile, and having both on the same form might very possibly clash.

Having 'Field API' fields live under a form fieldset require updating the $form['#fields'][$field['field_name']]['form_path'] property to contain the parents of the element (probably something like array('name_of_fieldgroup', $field_name)).

Also, supporting the 'Add mode' button on multiple fields require some extra work to make the forms multistep.
See how node.module, or the following, simplified stub code (#367006: [meta] Field attach API integration for entity forms is ungrokable has a discussion to streamline that part a little, but for now the code below is the current 'official' way). Sun was recently working on a patch to implement this construct on base user forms for user-level fields, I don't know how the two tasks override or collide.

function myentity_form(&$form_state, $entity) {
  // Take the current state of the $entity.
  if (isset($form_state['entity'])) {
    $entity = (array)$form_state['entity'] + (array)$entity;
    $entity = (object)$entity;
  }

  // Build form.  
  $form['foo'] = array(...);

  // Attach fields.
  $form['#builder_function'] = 'myentity_form_submit_builder';
  field_attach_form('myentity', $entity, $form, $form_state);
  
  return $form;
}

function myentity_form_submit_builder($form, &$form_state) {
  // Extract an $entity out of form values.
  $entity = myentity_submit($form_state['values']);
  field_attach_submit('myentity', $entity, $form, $form_state);

  // Prepare for form rebuild.
  $form_state['entity'] = $entity;
  $form_state['rebuild'] = TRUE;

  return $entity;
}

function myentity_form_submit($form, &$form_state) {
  $entity = myentity_form_submit_builder($form, $form_state);
  if (myentity_save($entity)) {
    // Successful save: prevent form rebuild.
    unset($form_state['rebuild']);
  }
}

thanks yched. I fixed the form to work with multisteps. I used the workflow as described in http://drupal.org/node/367006#comment-2090318 - works fine!

>Shouldn't profile_type_save() include a call to field_attach_rename_bundle() when a profile type is updated with a different name ? field_attach_delete_bundle() is probably needed too, except there's currently no 'profile type' deletion ?

I've added a profile_type_delete() function dealing with that. However I'd just not support profile-type-machine-name-changes - as that makes just things complicated for any module relying on profile types. If needed, we can add it later on anyway.

updated patch attached.
Todo: work in the field-creation suggestions

* Worked in the field-creation suggestions, thanks yched.
* Added tests for registration integration and profile edit+display.

I think both fago and I are now on vacation. The approach taken here definitely seems to be the way forward on this most awaited for D7 topic. I cannot apply and eveluate the patch myself, though

Fago, if you're online, could you post a summary of where the patch stands and the TODOs, if any ?
I guess some manual testers would be welcome too ?

I'll test and reroll and do what i can.

Thanks, Benjamin! Time is drawing short. :( 10/15 is in 4 days...

First, here is a reroll of last patch against current HEAD

Let's cool down the title ;)

Needs review so bot can have a crack at it.

Thanks for the re-roll, andypost!

Well I've applied this patch, emptied my DB and started from scratch, enabled profile module, and I can't find anything to do!

As I seen there's only CRUD for profile and no UI at all... :(

Ah right...
Well looking at what I've got in the DB:

- profile_type looks fine
- profile:
This has: pid, name, uid.
Couple of points:
- surely there should be a 'type' field so a profile item knows which type it is?
- 'name' -- I'm confused about the point of this. If an admin or module adds more profile types, the a user's profile is made up of more than one profile item, ie, more than one row in the profile table. Each one must have a name? That seems wrong. If I'm a user, I'm going to find it very silly and tedious to keep putting my name into each section of my profile.

Suppose 'name' in profile table just points to "profile_type" so each profile can have 0 or more "types" assigned

That's fine, but the column name needs changing.

What kind of UI do we want? Back when I rolled a patch for this there was a sort of UI working in the same way as node types.

There's an existing UI for adding fields to users at admin/config/people/accounts/fields. No need to create a new one. But what we do want is ability to retain the functionality to show fields on the registration form as we had in D6 and below.

If the profile is a separate entity, we can't use the user fields UI. However profile_entity_info() should be able to provide an admin path for the manage fields tabs to live on (look at user/taxonomy for examples), and the profile itself needs a form to edit it, even if that only consists of field_attach_form() and a submit button.

1. Maybe it's because of my D6-based expectations, but admin/config/people/accounts/fields seems completely tucked out of the way to me. I expect settings to just be a page of ticky boxes, not have extra tabs of field API wonderment.
I would move this to a 'profile fields' page one level up, so admin/config/people/profile.

2. I added a field, created a new user and BANG:

PDOException: SQLSTATE[HY000]: General error: 1366 Incorrect integer value: '' for column 'field_floop_value' at row 1: INSERT INTO {field_data_field_floop} (etid, entity_id, revision_id, bundle, delta, language, field_floop_value) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4, :db_insert_placeholder_5, :db_insert_placeholder_6); Array ( [:db_insert_placeholder_0] => 1 [:db_insert_placeholder_1] => 2 [:db_insert_placeholder_2] => [:db_insert_placeholder_3] => user [:db_insert_placeholder_4] => 0 [:db_insert_placeholder_5] => zxx [:db_insert_placeholder_6] => )  in field_sql_storage_field_storage_write() (line 421 of /Users/joachim/Sites/7-drupal/modules/field/modules/field_sql_storage/field_sql_storage.module).

Yeah, floopiness ;)

3. Output looks wrong on user profile -- wrong formatting.

4. My new field appears both on user/1/edit (outside of fieldsets, ugly) and user/1/edit/main

Could we have some UX input on how this should work? I could wade in and try to rearrange things but I might make them just as bad :/

The error in 2 comes from profile_form_submit_handler() but I don't know the new field API well enough to figure out how to fix it.

But more generally:
- it's a good feature to have some profile fields that show up when you register
- it's a good feature to have some profile fields show up on the main account edit page
- these may not be all the same fields. Sites may want to collect a lot of data on registration, but then keep it in separate sections. For example, a site might want to collect user address details, but not clutter the account edit page with them, and so put them on a separate type.

What I propose:
- one profile type is special -- call it 'account'. Fields on this type appear on the account edit page, inserted as a new fieldset.
- other profile types may be flagged as being required for registration. (though, per profile type or per field, I wonder?)

Trying to standardize type/name/label to match node.module, but confused -- does FieldAPI use 'label' where node uses 'name'?

EDIT: giving up on this, as it's asking for trouble. Also webchick said on IRC that name/label for types is ok (which implies node module should get changed instead... ;)

I'm going to go ahead and call this as "didn't make feature freeze." Dries and I are going to need to have a discussion about what happens next.

Note that throwing out profile module does not affect any public APIs. If you were reusing profile module then you needed medical attention :P

Another patch. Partway work still.

- installs without crashing ;)
- added a 'registration' boolean on types to allow multiple types on registration rather than using a variable.
- changed the profile type 'main' to 'account' (but I haven't had time to go through the test files -- needs changing there too!)
- should be hook_install rather than hook_enable, surely?
- field_config_entity_type is not getting a new row for 'profile'?!?! (but the full_name field is correctly create on install, WITH an instance!)
- cannot fathom what makes fields appear at admin/config/people/accounts/fields. They are also at admin/structure
- totally baffled by the form stuff from fago's patch. No idea. Probably doesn't work any more. Needs fixing anyway, see comments 32 and 33 above.
- we need a UI to list / create types as far as I can tell
- we need a plan. code without a plan is teh messy.

Sending joachim's patch to bot module. I've been working on this too but joachim's been ahead of me at every step, except that I should be able to add/fix the admin/structure/profile page from my code.

Note that this is on Dries' list of exceptions to work on!

I feel we don't need an 'account' profile with special treatment-- instead this can be handled by the capability to add fields directly to the user.

Hope I"m not overstepping my bounds, but since this patch is a dependency of #394720: Migrate profile module data to field API and I keep loosing track of the progress of this patch - adding "Exception code freeze" to tags

Not overstepping at all. Would be great to have folks jamming on this this weekend!

> I feel we don't need an 'account' profile with special treatment-- instead this can be handled by the capability to add fields directly to the user.

Good point! That means one less thing to implement too!

Benjamin: I'll come on IRC if I have more time to work on this so I can coordinate with you or anyone else :)

One thing I've just remembered that I've not seen in the patch:

Field privacy: old profile module allows fields to be one of:
a) admin-only (use case: 'this user is a troll')
b) admin and user-only
c) public, not shown in listings
d) public, shown on listings
(At least that is how I understand them; profile module is shabby on documentation)

The difference between c) and d) I don't think we care about, as I'm inclined to drop profile listings and let people use views.
a) and b) might as well be implemented in FieldAPI so anything can take advantage. As far as I know, FieldAPI doesn't handle this yet, does it?

While we're at it, if someone who regularly uses profile module could do a quick run-down of features so we don't miss anything, that would be handy :)

I think we can leave profile field permissions to http://drupal.org/project/cck_field_perms or whatever the equivalent in CCK HEAD is - presumably that'll still exist in D7 in contrib.

umm, doesn't that kind of make an upgrade path for profile module depend on a contrib module? I think it would be best to find a way to keep this functionality in core.

catch: The problem with that is core ends up exposing data that used to be private. Also, CCK Field Permissions is a complete beast of a module that screws with the visibility of ALL of your fields. It's not really functionally equivalent, IMO...

Yup, CCK Field Permissions is a pain as suddenly all fields are affected, so any field you add later requires a bunch of fiddly permissions to be set. The D5 version was much easier, as you first enabled its functionality per-content type.
And I agree with rcross, we really can't lose a feature like this; it will leaves tons of sites with no upgrade path.

I'm not sure that's totally fair really. Let's look at this a different way - we've just put CCK in core for god's sake. I think it's pretty reasonable to assume that people will expect to have to install some contrib things to match their previous configuration in 99% of cases.

Field permissions is a nightmare of a module to use, initially. All you have to do is make it so that when a D6->7 upgrade is run, a note appears that says the equivalent of "you're going to lose your field privs, please see node x on d.o re this matter".

Not delightully pretty, but given the *huge* jump between 6 & 7 in some respects, I think the egg breakage count should be minimised not completely eradicated(?)

NikLP, weren't you one of the loudest complainers (along with me!) on #drupaluk when the 5-6 upgrade lost breadcrumbs from the Primary links menu? ;)
I really really think that removing features is a no-no. Removing a module outright is one thing (whole other kettle of fish), but saying to users 'Profile module now shiny with fields... oh btw they no longer do something that's possibly crucial to your site' is just pants.
Besides, I'm not even sure there IS this in the works for D7 -- the CCK project page seems to talk only of a UI for D7, and the content_permissions folder on the MAIN branch is empty.

Yes field visibility is a crucial part of profile, should be in core if at all possible... And, subscribing.

I'd argue that role based field visibility is a "nice to have" rather than a requirement, especially considering that we're now past feature freeze. What is really needed here is (a) Fields API based profiles (b) clean data migration. Linking to handbook documentation on how to deal with field visibility using contrib would be enough.

There's no way on god's earth field visibility is getting into core at this stage, and equally zero chance that implementing a "profile only" version is going to wash in the negative amount of time there is to implement this.

We need to focus on getting some sort of UI available and the API stuff working, and go nuts about the rest later.

Rickvug's a + b are a prerequisite to any other features anyway, so would be great to get that side of things working like NikLP says. If we ended up missing the boat on permissions and not getting the patch in, then the code itself would still be valuable for a "profile as fieldable entity, but not node" module in contrib - which could have an upgrade path from core profile and possibly content_profile too if there's enough momentum behind that approach, and ought to then be a drop-in to Drupal 8. So hopefully people can continue working on that side of things, and we can have the permissions discussion orthogonal to getting the basic implementation working.

On field permissions - certainly that's a much more important feature than the field listings - I really hope we can just say 'use views' for listings - but whether it's a profile-only solution or an updated and less annoying field permissions module then there needs to be something for it.

From what I remember, and it's only a few months ago I just used this, profile field visibility allows for a couple of things:

1. Specify a field to be visible only to admins + the user, and no other users. Editable as usual.

2. Specify a field to be visible and editable only to admins.

There's also 'allow users to specific field privacy themselves' - which you can do with http://drupal.org/project/profile_privacy - that's fine left in contrib, but nice not to make it impossible with whatever else is done here.

To me, #1 is a very common scenario which core ideally should support.

#2 is a lot less common. The "this poster is a troll" field mentioned above is better handled by flag module IMO. If you're storing non-boolean fields visible only to admins, then likely that's tied up with custom application logic - at which case you could probably manage a couple extra hook implementations or installing a contrib module anyway.

One last thing. If we're more or less agreed that profile module shouldn't be handling listing users by profile field and want to tell people to use views instead - then that argument holds whether profile module is converted to field API or not - since there's views integration for profile tables already. So we could have a spin-off patch to remove that functionality now - we already did similar for multiple term and depth handling for taxonomy, and you can already tags users in core without profile module at all, then that'd be one less thing to worry about here.

> If you're storing non-boolean fields visible only to admins, then likely that's tied up with custom application logic - at which case you could probably manage a couple extra hook implementations or installing a contrib module anyway.

Not necessarily.
Better use case than the 'troll' one: membership data. Which committee a user is on, which position they hold there, whether they have paid their membership fee. Information about a user that the user should either a) not change themselves, or b) not even view themselves.
Granted, this could be handled by a CRM module. But we're back to the point about removing features and blocking upgrade path.

Note that RDFa that just went into core will work with fields naturally and will require extra wrangling to make it work with non-field profiles (agree in principle with webchick in comment subject and body to fields #55 but we do have examples of non-field RDFa already and fields are much cleaner, especially in a flexible environment like profile).

Can we look at getting the field bits and the UI working first? :) I'm happy to test but I don't know what, if anything, is actually being done?

When the hell is Fago back?? :p

Is user a fieldable object? if yes so profile should be a UI module to attach fields

That's the whole idea, yes...

+111111 Really wanting to test this patch.

> Is user a fieldable object? if yes so profile should be a UI module to attach fields

Yes, but no.
As discussed either above or in the earlier issue, we don't want the overhead of loading heaps of profile fields on every user load.

Hmm for that matter, maybe we *should* have a special 'account' profile type?

@joachim Suppose that profile information should be loaded only for profile module's pages and blocks not on hook_user_load() same as profile_load_profile()

I'm not sure I get what you mean -- only load the profile data in certain places? But AFAIK, adding fields with FieldAPI to an object means they always get loaded.

The other reason for the new profile entity rather than adding fields to users is extensibility: big discussion on it in #394720: Migrate profile module data to field API.

sigh. :(

Trying to learn the fields api so late in the production phase meant that I couldn't help with this, but we are using a highly modified profile module at work that has webform like fields that are defined via hook_profile_fields calls. I'm guessing that such a change would also be to late for D7? Double sigh..

If there is interest, I can look at re-porting these to an updated Drupal 7 patch, #83902: profile field types and attributes. So far, I've have had no interest (good or bad) by anyone about this approach, which is strange as it totally removes all limitations from the profile module with minimal refactoring.

Key points of this approach:

• No schema changes and no data migration required, (My hacked module has filter format support that means a serialization of textareas profile values + addition of default filter format - I think that I removed this from the patch)
• Profile fields defined dynamically. A drupal_alter means that all callbacks can be overridden.
  • Profile fields have defined view and input callbacks.
  • Additional save and load callbacks. The date field is run through custom serialize / unserialize callbacks, and we use this to provide 1 to many relationships in non-core profile fields. This does mean that there is always a cruddy save to {profile_values} even if the data is stored in other tables, databases or systems (eg: LDAP integration). I done this as this table is checked by the standard profile module in many places to see if there is data present, and I didn't have the time to refactor this.
  • An optional widget like options forms fragment callback. This provides the profile list options form.

NNNNNNOOOOOOOOOOOOOOOOOOOOOOOOOOOO!!!!!!!!!! >:'(

:((( - another release cycle with the old profile.module? ouch! :(

@#72
>- added a 'registration' boolean on types to allow multiple types on registration rather than using a variable.
It was a single variable, because multiple types won't work right without further work/tweaks.

>- changed the profile type 'main' to 'account' (but I haven't had time to go through the test files -- needs changing there too!)
I veto. We want to distinct the profile from the account right?

>- should be hook_install rather than hook_enable, surely?
It should be yes, but due to some caching issues I wasn't able to resolve profile creation didn't work in that stage. However I got it working with hook_enable.

Well, so I think we have to move this to contrib.

>- changed the profile type 'main' to 'account' (but I haven't had time to go through the test files -- needs changing there too!)
I veto. We want to distinct the profile from the account right?

Doh! You're right of course!

For contrib -- looks like, sadly.
I volunteer to co-maintain :)

subscribe.

subscribe

Subby.

If all the interested parties want to go over to #623210: Architecture and roadmap...

Ok, so I keep the code discussion here, but let's use the issue above for architecture.

@code:
I took my old code and fixed it for to work with HEAD. Well I did already focus for a contrib module, but I moved that in another branch so we can focus on the core route. Please see, test and review

http://github.com/fago/profile

@profile-type:
Well I used the 'name' column to identify the type, if that's confusing let's change it to 'type'?
Also I loaded the type's label into the profile, so that the type's label is the profile's label. So each profile (of the same type) has the same label which should make sense to the user and may be used when displaying. Does that make sense?

@module:
It auto-creates a 'main' profile type which is used during registration and can be edit at user/X/edit/main and it's displayed at user/X This all works for me.

#608894: Resolve the conflict between the fieldable users UI and the profile module hid profile module from the UI on new Drupal 7 installs, so it is confirmed now as a legacy module that has no place on new sites (except for those who love it enough to hook_system_info_files_alter() it back to life).

There are three options (at least):

- git rm modules/profile + open an issue for profile2 to migrate the core profile data into it. Rich user profiles stay in contrib, core provides fieldable users in case you just need to add a couple of fields.

- add profile2 or something like it to core, with an upgrade path from core profile module.

- migrate profile data to user fields (I'd vote against that being done automatically since it would hard-code profile2 out of the running as an option).

Slightly off-topic, if there is a candidate for the proposed 'code debt' tag to be retrospectively applied to an issue, profile module might well deserve first place in line see latest comments on #1050616: Figure out backport workflow from Drupal 8 to Drupal 7 for background.

>- add profile2 or something like it to core, with an upgrade path from core profile module.

Once we have crud for entities in core, going with the profile2 code would be pretty straight-forward I think. It doesn't have an update-path from the old-profile module though.

Is there any movement on this? Has "crud entities in core" been resolved?

I think profile2 with upgrade path from profile should solve this issue

I'm going to risk opprobrium and bump this to critical for 8.x.

I don't think we can release D8 with a hidden module in core that can only be enabled if you were originally upgraded from D6 with it enabled already because we're too embarrassed to show it to anyone.

Following intently

This thread was at some point marked as a duplicate of this one #394720: Migrate profile module data to field API

Also of interest
#141419: Full rework of profile categories improving data model
#608894: Resolve the conflict between the fieldable users UI and the profile module
#1223224: Still not understanding profile 2's uses and purpose

I would say get rid from core and even it is questionable if we send it to contrib, the only question is an upgrade path.

couldn't agree more with marcingy

http://drupal.org/project/field_convert and #1068446: Migration path from core Profile look like the places the upgrade path is best focused on.

By hiding the profile module from the UI in Drupal 7, we decided to deprecate it. Now, in Drupal 8, it has to go away.

Tagging.

Oh. :)

Cue in a cheering mob.

And There Was Much Rejoicing
http://www.youtube.com/watch?v=enSYlCEz5VI

Dries committed this. Thanks!

http://www.youtube.com/watch?v=SLY7yI1xV-M

I like how there is no upgrade path to add back the fields to hold the data that was there before :-) . Well done, crew!

Yeah I don't think we can offer that in core. People might want to migrate to profile2, or they might want to migrate to user fields, or possibly move some fields to one and some to the other. This isn't something that can be one size fits all.

I'm personally fine with just seeing what happens over the next couple of years - we're talking about sites upgrading from Drupal 6 to Drupal 8, that don't move away from profile module to fields in Drupal 7 - which they have 2-3 years to do before anyone really needs to worry about it.

If we are worried about that data having somewhere to go when 8.0 is released, we could open a task to track stuff like that.

Has anyone been able to migrate D6 profile field to D7 user fields? Catch mentioned #1068446: Migration path from core Profile in comment #81, but the ball hasn't started rolling there just yet.

Something was left in maintainers.txt -

Patch of the year, hope we remove some more question marks from that file soon however that happens.

I think it's premature to remove this before we have an upgrade path. Haven't we learnt all about technical debt? This has just taken out a huge loan :/

We could open a critical task for an upgrade path. But an upgrade path can be worked on without having any profile module code in core at all.

Committed to 8.x.

chx opened an upgrade path issue here #1261576: Profile module data is not upgraded.

I added a change notification: http://drupal.org/node/1261964
Could use some love, though.