Problem/Motivation

Profile module was removed from D8 #301071: Remove profile module from core . The data is not in the entity-field system and needs an upgrade path. It has been suggested that Profile2 should be included in core #1726822: Port Profile2 to D8 and the upgrade path from Profile2 can be done in contrib.

Proposed resolution

There are three possible resolutions:

1. Add profile module back to core and migrate the data into it.

2. Migrate the data into fields on the user entity in core

3. Say that since profile module was removed from core, the upgrade path was removed from core as well - which is effectively #1 with a contrib module.

Remaining tasks

Once it is determined #1668292: Move simplified Profile module into core gets in or not, write the relevant upgrade path.

User interface changes

This issue is about an upgrade path so n/a.

API changes

This issue is about an upgrade path so n/a.

#1668292: Move simplified Profile module into core
#1726822: Port Profile2 to D8
#394720: Migrate profile module data to field API

Original report by [chx]

There's a mess of an issue at http://drupal.org/node/394720#comment-2009166 but the patch is a great start, so let's start fresh. This is obviously critical.

Comments

chx’s picture

Category: bug » task
catch’s picture

Copying some thoughts from other issues.

There are at least two legitimate destinations for the data to be migrated:

1. profile2 - see http://drupal.org/node/1068446 (this project could now be renamed 'profile' for D8 if we wanted to)

2. User fields in core.

IMO this issue can be marked fixed if either of these is in place (that would include a migration path in Drupal 7 contrib- that lets people switch even earlier instead of waiting for D8) - as long as there is somewhere sensible for the data to go.

Since there's a couple of ways to do this, I do not think we should have a hook_update_N() in core whatever happens, for the user fields one, we can have a contrib project for that as well and that gives people a choice of what they want to do.

If we eventually fix the migrate/update.php refactoring issue, we can provide a migration source from profile module, and users will need to be a migration destination anyway. That's another way to approach this.

I agree this is a critical task for Drupal 8, it also blocks a Drupal.org upgrade.

KarenS’s picture

The http://drupal.org/project/profile_migrate module might be useful. It was created to convert D6 profile fields to D6 CCK fields. It has no D7 port since I didn't need one myself, but it could potentially be extended to work in D7 or D8 to migrate profile fields to Fields fields.

There is a discussion at http://drupal.org/node/560324 about how to migrate D6 Content Profile to D7 Profile2, and some the tasks and issues that are needed are similar, and there is a discussion about the possible destinations for these fields (Profile2 or a D7 version of Content Profile).

At http://drupal.org/node/560324#comment-4817254 I described a way the process could work for a D6 to D7 upgrade.

I don't have a lot of time to work on this, but if anyone is interested in using Profile Migrate as a base for this and wants to work on it, I'm certainly open for that.

dawehner’s picture

So now that profile module got removed out of core, this seems not to be required anymore.

Just adding a tag to move the issues once there is a profile contrib module which takes this stuff.
Is closed won't fix the right status for this?

dawehner’s picture

Status: Active » Closed (won't fix)

And marked as won't fix

KarenS’s picture

Status: Closed (won't fix) » Active

If this is marked won't fix, it won't get done. At the moment Profile has been removed from core and there is no upgrade path for anyone who was using it, nor is there even a plan for how it will be done. Doesn't this issue need to stay open until that is addressed?

catch’s picture

Yeah I think we need to keep this open. Core in Drupal 6 and 7 shipped with a profile module, people who upgrade only core to Drupal 8 that used this module will have orphaned profile data in their tables belonging to their users. It's core's responsibility to ensure that there is a way for this data to be re-integrated back into their site. I completely agree with removing profile module before that's in place - there's no point keeping the functionality when we definitely, definitely weren't going to do anything with it. But I also agree that this task should hold up the release of Drupal 8 until it's done at least to the point where you can point people in the right direction.

KarenS’s picture

Also adding a link to #301071: Remove profile module from core, which is the decision to remove profile from core.

catch’s picture

Just on #4, the decision wasn't to make a contrib profile module, it was to just nuke it completely and let profile2 and user fields (or whatever else might arise) take over. This is why core needs to keep a release blocking note of whether there's a migration path or not - since there'll be no D7 profile module -> D8 profile contrib -> somewhere else route to take.

joachim’s picture

The plan with profile2 was that it could become the new profile module in core. It missed the boat on D7, but perhaps it can go into core on D8?

Regarding adding fields to users -- there are several reasons why you don't want too many fields on the user object, though some of them may have been resolved.

xmacinfo’s picture

I don’t know yet if Profile 2 or Fields to the users is the best way to upgrade profile fields.

@joachim: Can you list a few reasons why it's not a good idea to have too many fields on the user object?

joachim’s picture

Some issues in the profile2 queue which explain some of the reasoning:

#1006442: Provide a comparison with core user module + fields
#1223224: Still not understanding profile 2's uses and purpose

Another reason is that migrating a D6 site's profile data to fields on users will lose a whole load of functionality, such as categories, field privacy, and field edit permissions.

xmacinfo’s picture

@joachim: You list a lot of compelling reasons. Looks like we need Profile 2 to take over, not user fields.

Thanks.

KarenS’s picture

We probably need to provide for both alternatives, either attach the fields to users or Profile2. Don't know if any work is being done on Content Profile for D7, but if so, that is another alternative. If someone has only a couple of fields and wants them attached to users and they don't care about the features they will lose, I don't think we need to require that they install and configure Profile2 (which is a fair bit of overhead if you don't need/want it). The basic task is the same either way, it's just a question of what entity the fields get attached to.

bryancasler’s picture

I would prefer a Profile -> Fields API solution. My simple reasoning is that if I had a fresh D7 site, that is what I would be using, so any path to that state is preferred over the alternatives.

I see the profile 2 module as only postponing the inevitable.

geerlingguy’s picture

Major +1 for Profile2 supplanting Profile in core (though, of course, Profie.module's already gone...).

Users with fields is already much nicer than either the old Profile module or Content Profile, but Profile2 is the realization of many dreams for a community site.

joachim’s picture

@animelion: I'm not really following you there -- Profile2 is based on Fields API.

Alan D.’s picture

Here is a link the Profile2 issue for providing an upgrade path. No work has started yet.

#1068446: Migration path from core Profile

Alan D.’s picture

Priority: Critical » Major
Issue tags: +D8 stable release blocker

My 2 cents on this issue.

Leave things for D7. As Profile2 matures, start porting this into D8 core, (renaming: profile2 > profile) with upgrade path that has been hashed out in contrib over the next two or three years. A Drupal 6 > 8 upgrade would then be seemless as the core module would still active during the upgrade.

Bumping this from Critical to Major, to free up the critical issue queue. Resolving issues like #1126000: [meta] hook_field_*() called on fields not set in the $entity object (partial updates) would help speed the maturation of Profile2, that will assist everybody in the long run.

webchick’s picture

Priority: Major » Critical

No, we don't get to free up the critical queue by falsely marking critical issues not-critical. We do not break peoples' data.

markwk’s picture

Not sure this is helpful or not, but I made this simple module for D7 converting core profile (ick!) to user entity (horray!): https://github.com/markwk/profile_entity. Seems to work for me but perhaps not general enough to solve all situations...

bryancasler’s picture

@markwk Thanks so much for sharing!

markwk’s picture

my pleasure... it seems like I made a mistake though. Apparently I forgot to check whether the profiles wer empty or not... so sorta need to add a bit more so it doesn't start multipling DB space with empty rows... ;-) oops

xjm’s picture

Is there any reason not to go the user entity route?

(I'd also think this is a bug but apparently not.)

catch’s picture

A lot of people prefer having a separate entity (or entities) to hold profile data - for example to avoid loading them automatically in user_load(), which often happens for the current user. It'd be possible to provide an upgrade path from profile.module to user entities in core, but then someone wanting to go from profile module to profile2 would have to re-do that upgrade path to profiles and remove the user conversion.

This still feels like a critical task to me because it's "something that has to be done" (provide an upgrade path somewhere from profiles to something else, or even port profile module to D8 in contrib would cover it), rather than "something that is critically broken" - like having actual data loss during an attempted update for example, but wouldn't really object to re-classifying either.

sun’s picture

Title: Profile module data needs to be upgraded » Profile module data is not upgraded
Category: task » bug

Agreed, this is definitely a bug.

#28 still makes sense, especially from a performance perspective. Most sites I've seen using Profile module have not only a decent amount of profile fields, but also actively leverage the category feature. Loading all that data on every user_load() would constitute a measurable performance impact both in processing time and memory, even on smaller sites.

That said, let me go out on a limb and ask something simple:

What's the chance for moving Profile2 module's functionality into core for Drupal 8?

With the removal of Profile module from core, Drupal has silently and secretly lost its very origin. "Community plumbing" is no longer possible. There's not even a simple way to list registered users on your site. With the Views in core initiative, there's some hope to bring back some of the essential functionality. But there'd still be no sane way in core to create real/sophisticated user profiles, which, based on my knowledge/experience, is an absolute basic feature that almost everyone expects from a WCMS that Drupal is.

While this might sound off-topic for this issue, I think it is relevant, since we're essentially discussing how to resolve a upgrade path problem, for which no suitable/equivalent target storage/functionality exists; at least in core. At the same time, a simplified implementation of profile2 strategically makes sense for Drupal core, and alas, shouldn't be that hard to implement. Doing so would resolve the upgrade path problem.

I'm certainly aware that Profile module supported field types for which no equivalent Field API field types exist in core yet. Namely, Link and E-mail fields. However, non-deterministic polls showed that (almost?) everyone considers those field types as core material. The modules already exist in contrib and are of good quality (at least last time I checked); Link could possibly even dumped as-is; E-mail contains some add-on features that can be removed. Hence, that shouldn't be a blocker either.

I'd be highly interested in working on this, and I'm pretty sure we won't have troubles to find other interested contributors. But without a strategic community agreement, I wouldn't want to work on it.

xmacinfo’s picture

I agree with @sun. We needs enhanced user profiles, users lists, etc. Almost all sites I am working on needs a rich profile page, sometimes just to add newsletters links but most of the time, a lot of various fields. So yes, we need a full blown rich profile in Drupal 8 core.

I've implemented Profile 2 and I like it's architecture, since it does not make the user object bloated.

By integrating Profile 2 in core, we could provide a clean upgrade path, which would also make the user object leaner for those who upgrade to Drupal 8 (provided we do move Profile 2 in core).

What is the best way to get this forward?

sun’s picture

Issue tags: +Profile in core
sun’s picture

Alright, in order to not potentially hi-jack this issue further, I've created/updated dedicated issues for the suggested solution proposal in #29:

#1668292: Move simplified Profile module into core
#501434: Move Link/URL field type into core
#1668332: Add an E-mail field type into core

...in general, using the Profile in core tag.

sun’s picture

webchick’s picture

Exciting progress! :)

andypost’s picture

When profile2 patch lands core will require upgrade path from both modules.

catch’s picture

The upgrade path from profile2 itself can be provided by a contrib module - same as with Views, CCK and others.

sun’s picture

#501428: Date and time field type in core landed! This means that #1668292: Move simplified Profile module into core is the only remaining blocker (but it is quasi-RTBC already).

jaredsmith’s picture

This issue could use an updated issue status summary based on the templates at http://drupal.org/issue-summaries.

jaredsmith’s picture

Oops

nategasser’s picture

Issue summary: View changes

Updated issue summary.

nategasser’s picture

Issue summary: View changes

Updated issue summary.

nategasser’s picture

Issue summary: View changes

Updated issue summary.

nategasser’s picture

Issue summary: View changes

Updated issue summary.

nategasser’s picture

Issue summary: View changes

Updated issue summary.

nategasser’s picture

New issue summary posted.

nategasser’s picture

Issue summary: View changes

Updated issue summary.

YesCT’s picture

@Nathan Gasser Thanks!
@chx also updated the details.

Removing the needs tag. :)

catch’s picture

catch’s picture

Issue summary: View changes

rewritten summary

catch’s picture

Updated the issue summary. There's approximately three ways this issue could go.

Berdir’s picture

Wondering how this is different to the other removed modules. We don't have critical issues about openid/poll for example and it was just decided that translation.module will be removed without upgrade path too.

Given that, seems like this issue can go the same way?

catch’s picture

Assigned: Unassigned » Dries

openid and poll were moved to contrib, so the 'upgrade path' would be installing the contrib module.

Translation module is closer to this though, the arguments are similar in that an automated upgrade path is going to be very tricky, and it's too late for profile2 in core I think.

Let's see what Dries thinks.

Dries’s picture

Assigned: Dries » Unassigned

I'm ok with moving the upgrade path to contrib, along with the module itself. It seems consistent with what we did with other modules.

It was not clear if catch is on board with that (he wasn't always in the past). If not, I'm happy to discuss and re-consider.

Dries’s picture

Status: Active » Closed (won't fix)
Issue tags: -Profile in core
David_Rothstein’s picture

Status: Closed (won't fix) » Active

The code can live in contrib, but I think its existence is still a release blocker for Drupal 8 core? (Unless we're going to open a discussion about getting rid of or completely changing https://drupal.org/node/65922.)

In other words, it's one thing to not have an upgrade path for configuration (example: Dashboard module, which seems unlikely to ever have a D8 upgrade path) because it can be recreated or replaced relatively easy. But user profiles are pure data; if those are left behind that's pretty much the same as saying there is no upgrade path.

It also would be a good idea to look at the stats for how many Drupal 7 sites actually have the Profile module enabled. (In theory that data is sitting in the drupal.org logs waiting for someone to look at it, as a result of #1036780: Drupal.org should collect stats on enabled sub-modules and core modules.) Unfortunately the data doesn't exist for Drupal 6 and that's where it would be really useful because that's where most of the sites using this module likely are, but the Drupal 7 data might still provide some indication of how big of an issue this is.

chx’s picture

Well, the thing is, poll (contrib) has not been updated for 14 weeks now and so I have some doubts whether it would work *at all* (the drop is always moving and four months is an eternity in this cycle) and so indeed the question becomes: how strict are we with the upgrade policy? Are we going to block D8 release until some unicorns show up with a profile upgrade or migrate in contrib and a working poll module?

catch’s picture

Priority: Critical » Normal
Issue tags: -D8 stable release blocker +revisit before beta

It comes down to whether we support features that have been removed from core after they're removed.

We always upgrade data for features that stay in core, increasingly it's not possible to provide a useful upgrade path for data that's moving in or out of core (i.e. CCK -> Drupal 7, or Views -> Drupal 8, although views are config so that's less of an issue).

If we'd gone with migrate for the 7-8 upgrade path, then it would be relatively simple to provide an option to migrate profile data into core user fields - and alternative upgrade paths could have their own migrate classes in contrib. But we don't have that, so there' s no concept of an optional 8.x upgrade path for this data.

Downgrading from critical and tagging 'revisit before release' rather than marking won't fix again - even if it holds up the release, it shouldn't hold up an RC because we know we're not going to have core code that does this and needs testing.

hawkeye.twolf’s picture

hawkeye.twolf’s picture

Issue summary: View changes

Update possible resolutions

catch’s picture

Issue summary: View changes
Issue tags: -revisit before beta

Migrate is happening. Whether there's a default migration we could possibly offer is still an open question. Untagging though since answering that question doesn't need to be tied to the release at all.

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.5.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

heddn’s picture

Status: Active » Closed (duplicate)
Related issues: +#2957256: Migrate data from Profile2