Sadly, Profile => Field API did not happen. This means Profile module is staying exactly where it is, in 4.6-esque code. We're all hopeful that a much better profile solution that leverages Field API will emerge from contrib which we can then hastily add to Drupal 8.

In the meantime, it's a critical UX issue to ship Drupal with two different ways to add fields to users. So with heavy regret, I must file this issue that asks for the various tabs on admin/config/people/accounts to be removed from core.

Files: 
CommentFileSizeAuthor
#107 608894-profile-hidden-default.patch1.55 KBmr.baileys
PASSED: [[SimpleTest]]: [MySQL] 28,778 pass(es).
[ View ]
#105 608894-profile-hidden-default.patch1.57 KBmr.baileys
PASSED: [[SimpleTest]]: [MySQL] 28,783 pass(es).
[ View ]
#101 608894-profile-hidden-default.patch1.32 KBmr.baileys
PASSED: [[SimpleTest]]: [MySQL] 28,777 pass(es).
[ View ]
#67 sniff_we_really_wont_call_it_abomination.patch1.34 KBchx
PASSED: [[SimpleTest]]: [MySQL] 26,370 pass(es).
[ View ]
#66 sniff_we_wont_call_it_abomination.patch1.29 KBchx
FAILED: [[SimpleTest]]: [MySQL] 26,458 pass(es), 1 fail(s), and 0 exception(es).
[ View ]
#59 abomination.patch613 byteschx
PASSED: [[SimpleTest]]: [MySQL] 26,385 pass(es).
[ View ]
#52 user-fields-ui-608894-52.patch683 bytesDavid_Rothstein
PASSED: [[SimpleTest]]: [MySQL] 25,212 pass(es).
[ View ]
#48 make_users_crap_cos_profile_module_is_even_crapper.patch652 bytescatch
FAILED: [[SimpleTest]]: [MySQL] Invalid PHP syntax in user.module.
[ View ]
#40 deprecate_profile.patch2.15 KBcatch
PASSED: [[SimpleTest]]: [MySQL] 28,780 pass(es).
[ View ]
#26 608894-death-of-profile.patch73.8 KBDamien Tournoud
Failed: 14372 passes, 9 fails, 336 exceptions
[ View ]
#23 608894-death-of-profile.patch74.11 KBDamien Tournoud
Failed: Failed to apply patch.
[ View ]

Comments

Issue tags:+Novice

On the plus side, this is probably really easy to do. :P Tagging as a novice issue.

Title:Remove UI for adding fields to users in coreRemove fieldable users

My statements in IRC were wrong.

All attached fields are loaded + cached in user_load().

However, the other statement still holds:

- Displaying a user as "user picture" is, btw, a build mode. If it was done properly. Since we don't do anything here properly, I'd say that the entire fieldable users story belongs into contrib.

True is, the core functionality could be used to add a "Full name" field or whatever.

True is also that you potentially wreck your site when adding countless of fields + flushing your caches.

True is also that it's hard to explain when users should use which feature (fields/Profile).

True is also that just removing the UI doesn't make things better.

I have no clue how to proceed here.

Issue tags:-Novice+D7 API clean-up

This is not at all novice ;)

Nobody ever said that the conversion to the field API was something easy to do. Nobody said that it will be quick and painless. But it really worth it.

I have no clue how to proceed here.

We have to change the assumption: "Sadly, Profile => Field API did not happen." It CAN and still MUST happen. I don't care about the code freeze. We NEED to do it.

Are we giving up on "user picture as imagefield" ?

yched: I think we need to, for core at least.

Damien: I really don't want to hash this out here yet again. We are not going to get a usable profile module utilizing Field API at all, let a lone in core, by D7's release (assuming we do not want to completely waste the opportunity for Drupalcon SF to be a rallying point for 2,000+ Drupalistas to hammer out Drupal 8 architecture discussions, and instead be forced to use that power on "clean up the critical queue" -- I know what my vast preference would be...).

There are simply way too many architectural questions that were not hashed out early enough: fieldable users vs. fieldable profiles, how/whether to support multiple profiles, how to support field privacy and grouping without relying on contrib modules, how to get fields of certain entities only on the registration form -- oh, and a full upgrade path for all of this too, btw. Please drop it. It's done. Help joachim and fago in contrib so we have something usable for D8.

As far as #2 goes, even just removing the UI already is a huge improvement, because we don't ship with two totally incompatible ways to add fields to users in Drupal 7 core. So I would be perfectly happy with a patch that did just that, since that's the original scope of this issue.

On the rest, the only open question in my mind is whether core providing a fieldable users API out of the box helps or hinders an effort in contrib to build Magical Unicorn Ponies Profile (MUPP) module. Fieldable users forces the assumption that you want to add fields directly to the $user object, which leaves MUPP with the very sticky problem of having to provide a UI that distinguishes between a user (for small, 'native' fields like first/last name) and a profile (for bio, my favourite bands, and basically everything else).

It *seems* like it makes more sense for MUPP to figure out how/whether to support adding fields directly to the $user object, and provide fieldable users itself, if so. However, what I dont know is whether there is any code in core currently (esp. RDFa) that is relying on this functionality.

I'm not sure that altering an entity into being fieldable from contrib is feasible. That's an edge case we didn't really focused on supporting.

For one, being fieldable has some constraints on the form workflow (there's an attempt to simplify this a little in #367006: [meta] Field attach API integration for entity forms is ungrokable, not sure what the outcome will be), and that is not easily alterable from the outside if the original entity code doesn't play nice.

It also means that the various field_attach_[op]() calls (which are the bulk of what 'being fieldable' is) are deferred into hook_{entity}_[op](), instead of at a fixed spot in {entity}_[op]() workflow. Execution order changes, might have nasty hidden consequences...

Er. Wait. So it's not possible for contrib modules to implement hook_entity_info()? That sounds like a problem. :P

No, I mean what we focused on was:
declaring your (core or contrib) entity as fieldable is "easy"

But having a contrib module turn an existing entity into being fieldable while it originally doesn't intend to, is more tricky.

Oh, wait. I think I see what you're saying. So basically core will implement hook_entity_info() for user module, contrib would have to implement hook_entity_info_alter() to set fieldable to TRUE, and it's unknown what consequences that'll have.

IMO if that doesn't work from contrib, we need to fix it. Core didn't manage to make files fieldable, for example, so this is something that'll also need to be supported in contrib.

(Oops! Cross-post! :D)

Well, 'fieldable comments' and 'fieldable taxo terms' patches had quite a few preliminary patches to prepare the work.
IIRC, those were mainly:
- cleanup awful D4-or-so code and workflow
- upgrade to D7 'standard' way of doing things (render workflow, build modes...),
- adapt form handling (fieldable = your edit forms need to be multistep, because of the 'add more' button).

So building a new fieldable entity type from scratch is not too complicated if you follow good practice. Taking a random entity and making it fieldable just through _alter stuff is not doable IMO.

Now, I'm not really familiar with the 'file' entity. It's a D7-era thing to a large extent, so possibly the amount of 'cleanup and prepare' work is minimal compared to poor comment.module..

@yched: Do you have a sense of how much of that was required to make legacy entities fieldable vs. how much was "Oh, god. I can't even stand to look at this crap."

I suppose with the pluggable storage back-ends it does make things more complicated. I remember catch and bangpound encountered all sorts of "fun" with taxonomy.

Welll, for comments:
#502538: Multiple load comments
#504678: Use objects in the comments API
#523950: Update comment rendering
#524652: Overhaul comment form and preview
IIRC, those were required steps, not "oh, let's cleanup this part while we're at it". Then again, comment module was, like, really out of date and quite entangled, so pulling one thread unraveled other stuff and those preliminary patches quickly grew.
After all of those got in, #504666: Make comments fieldable was a 12k patch.

I suppose with the pluggable storage back-ends it does make things more complicated. I remember catch and bangpound encountered all sorts of "fun" with taxonomy

That was not for 'fieldable taxo', but for 'taxo as field' ;-).
Typically, 'fieldable X' work is not really affected by field storage considerations. 'feature Y as field' possibly are.

1) Channeling scor: RDF does not depend on fieldable users. The folks working on that actually took special care, because of the hypothetical state.

2) If we'd remove the UI only, then MUPP in contrib could easily hook_entity_info_alter() back the UI. Not sure whether we have to remove the 'fieldable' property. (perhaps Performance only?)

3) User module is already prepared for a field attach workflow. Even if we would remove all field_attach_* invocations, the new User API hooks I implemented elsewhere would allow a MUPP module to invoke them on behalf of User module via hooks.

4) The actual Form API + Field Attach API workflow is a horrible mess, and no one really understands what's happening. There is no way around fixing this in #367006: [meta] Field attach API integration for entity forms is ungrokable and we absolutely have to fix it, but that shouldn't affect this issue, because it applies to all fieldable entities.

--

Hence, we have multiple options here:

a) Remove fieldable users entirely, including Field Attach API invocations, leaving that to MUPP.

b) Remove the UI and the 'fieldable' property for users, keeping the Field Attach API invocations.

c) Depending on whether b) will break that way, only remove the UI.

d) Keep fieldable users, but clarify the difference to Profile.

Especially d) would make more sense, if we had already made progress on build modes. Because, currently, you can attach fields to users, and those fields are loaded (and cached), but there is only one build mode, and that build mode is for the "User account" (user-profile.tpl.php). If I would be able to output a list of users using a different build mode, and say, render the user's full name + picture in there, both being fields directly attached on the user, then this whole thing would start to make more sense. For example, think of the "Who's online" or "Who's new" blocks.

So. Given that we need to do something with build modes anyway, I'm slowly leaning towards favoring d), keeping it.

a) Remove fieldable users entirely, including Field Attach API invocations, leaving that to MUPP

Might be minor to fix, but there's currently no hook that would allow the field_attach_submit() call in user_profile_form_submit.
+ as I wrote in #8, this changes execution order. If f_a_*() is called within a hook_user_*(), then hook_user_*() implementations cannot rely on the fact that field data has been processed.

b) Remove the UI and the 'fieldable' property for users, keeping the Field Attach API invocations.

Mh, that would mean all f_a_*() functions need to check whether the entity is actually fieldable and not die horribly or generate tons of warnings. Code cruft, + calling f_a_*() while you're not fieldable sounds like broken code...

I'd also favor d) and actually building stuff around user build modes...

There is only one way forward: gathering energies around completely migrating the Profile module to the Field API. There is no value in shipping with this 4.6-ish Profile module.

As sun and yched noted above, the hard part is *not* the Profile module part itself, but making sure that the User module is doing the right thing (defining build modes, etc.). This part is REQUIRED if we want contrib to be able to implement that anyway.

Like yched said, everything we did for comments, was completely necessary to do for comments, cleaning up comment module is not fun work. User module is almost as bad, relying on doing the full fieldable conversion from contrib would be a very big risk, and it's been in core for approaching a year, so it's possible (although not that likely) that existing modules porting are relying on it. Removing anything other than the UI for it is a no-go.

Otherwise I agree with Damien, don't really care about whether Drupal 7 is released before or after DCSF ("when it's ready" no?) but the general situation here ought to be a release blocker since it doesn't look good from any angle at the moment.

> This part is REQUIRED if we want contrib to be able to implement that anyway.

Side note - Indeed, OG7 for example, is taking advantage of fieldable users, which will allow any fieldable entity to become a group - so just by creating a user and checking the 'og_group_type' field - that user also becomes a group.

Title:Remove fieldable usersRemove the UI for fieldable users

"There is no value in shipping with this 4.6-ish Profile module."
Yes, there's a huge value. It's a several-month project which so far has not been done even after two code freezes, which we don't have to tackle in core amongst the 400+ other critical things we need to get done for D7 to release. catch/DamZ/whoever else: Over here, please. #623210: Architecture and roadmap

Sounds like the safest thing to here is just remove the UI, since there are contrib modules relying on the API (indicating that it's useful and having it be in core does not limit them unnecesasrily as I initially feared), and making a non-fieldable entity fieldable from contrib through entity alters sounds like it's something that is way more of a hassle than it initially sounds. User build modes are a completely separate topic altogether. So moving this issue back to its original title.

Title:Remove the UI for fieldable usersRemove the Profile module and the UI for fieldable users

Let's remove both then. And let contrib deal with the mess. Apparently, we entered the "let's just give up" phase.

Title:Remove the Profile module and the UI for fieldable usersRemove the UI for fieldable users

We are not stranding our users with no upgrade path, and we are not shipping a CMS in 2010 that has no ability to create user profiles. Chucking Profile module out the window is not an option. This has already been discussed. To death. And has derailed multiple issues that had very good technical/architecture discussion going on. Let's not let it happen again here. If you want to help, you know where to go.

Title:Remove the UI for fieldable usersRemove the Profile module and the UI for fieldable users
Status:Active» Needs review
StatusFileSize
new74.11 KB
Failed: Failed to apply patch.
[ View ]

Here is a patch.

We are not stranding our users with no upgrade path, and we are not shipping a CMS in 2010 that has no ability to create user profiles.

Even the *Poll* module has received more attention then the Profile module in D7. We already removed a few other unmaintained modules (Ping, Blog API, ...). There is no way we ship a CMS in 2010 with that kind of crap in it.

Status:Needs review» Needs work

The last submitted patch failed testing.

Title:Remove the Profile module and the UI for fieldable usersRemove the UI for fieldable users

We ship lots of unmaintained code in core. Blog. Forum. Book. It'll be a D8 discussion whether we remove those from core, just as it'll be a D8 discussion whether we remove Profile from core. Hopefully because we create a FileField / Upload module situation where a vastly superior solution gets in that makes the old one just plain silly.

Additionally, if you read through the responses on that Profile2 architecture issue, I think it's patently obvious that this conversion is something that is way more complex than initially meets the eye, and really needs time to simmer and mature before we lock its behaviour down for 3+ years. In the meantime, there is absolutely no point in ham-stringing our users with forcing them to go seek out one of 3,000 contributed modules to obtain this basic functionality that came for free in earlier releases. If it's not sufficient for their needs (and the current one is plenty sufficient for many sites, including Drupal.org), then they can seek out MUPP.

Seriously, enough. I am not at all interested in squabbling back and forth on this. The decision to keep Profile module in core has been made, by both core committers. We were forced to make this decision because the Profile => Field API conversion did not get done, despite repeated pleas, and even promoting it as one of the 10 feature exceptions.

Status:Needs work» Needs review
StatusFileSize
new73.8 KB
Failed: 14372 passes, 9 fails, 336 exceptions
[ View ]

This one should apply.

@DamZ, we're not removing profile.module from Drupal 7. For a lot of people -- including drupal.org -- profile.module gets the job done. Having the current profile.module is better than having no profile.module.

Status:Needs review» Needs work

The last submitted patch failed testing.

I need to make clear that neither "Fieldable users" nor the Profile module have anything in common with the current Profile2 initiative.

  • "Fieldable users" are just the direct decedents of the Profile module. The idea is to add fields to the User entity.
  • "Profile2" is really the port to Drupal 7 of the "Content Profile" module. The idea is to create a "Profile" entity, that is in relationship with the User entity with a "can have at most one of each type" relation. Each User can be linked with at most one Profile of each type.

Those serve vastly different purposes, are not interchangeable and need to coexists.

Drupal 7 need proper fieldable users. The only way to do that is to deprecate the Profile module.

> d) Keep fieldable users, but clarify the difference to Profile.

I would vote for sun's last suggestion. I think that by removing the field UI we are mostly thinking about confusion the end users might have. However, I can already think about many examples where I'd like to have fieldable users (not profiles - users), and I'm sure contrib will take advantage of it as-well. I think this can be compared to the confusion of people looking at create content page and ask themself "should I use a story or a page?" -- which can be solved with good documentation.

Here's my interpretation of the problem:

1. The new thing is better.

2. Right now, it's way-too-hard to provide an upgrade path for people who used the old thing to get from the old thing to the new thing. That's not going to happen for now. (Really.)

3. It would suck to ship D7 with both, because letting people see both interfaces at the same time is confusing and makes them feel dumb.

I think this is what we want, in core, in the world with half a unicorn:

1. Anyone building a new site in D7 uses the new thing. Fields on user profiles. Yummy.

2. Anyone upgrading to D7 who did use the Profile module will still use the Profile module in D7. And they don't see the UI for fieldable user, 'cause they've already got something going.

3. Anyone upgrading to D7 who did NOT use the Profile module gets the new thing. They have no old data to port. They get yummy fieldable users because who knows, they might want to do something with users later, and they should get the good stuff. (This will be a lot of sites since Profile module was off by default in D6, and many people never used it.)

So. What if we do this:

1. Ship Drupal 7 with profile module. Off by default.

2. Also ship Drupal 7 with fieldable users, UI and all. (On by default, but with some back-end mechanism to have it off.)

3. When someone upgrades to D7, the upgrade script checks to see if they have data for User Profiles. If they do, then the Drupal robots turn off the fieldable user UI. Off. They can't use it anymore.

4. Get rid of the ability to turn on Profile module manually. No more checkbox on the modules page.
-or-
Put a warning message on the Profile module so that anytime anyone turns it on, it says very clearly in scary text someplace really obvious: ARE YOU SURE? ie: "This module is not recommended for new websites. Only use this module if you are porting legacy data from an older version of Drupal. This technology has been replaced." Repeat the WARNING on the profile config page.

Ideally user pictures would get the same fate as Profile Module, so that people are disabled from using it unless they have ported a database from an older version of Drupal.

This does require doing some non-standard things with the Profile module (lack of checkbox, extra error messages, etc), but since the module will be ripped out eventually, I think the deviation from the norm is justified. Plus we get 1/2 a unicorn in core.

Just an FYI, there is an upgrade path from core profile: http://drupal.org/project/profile_migrate

Michelle

My idea in #31 was based on my impression that fieldable users is ready and working, and the problem was the upgrade path. But now (talking to webchick in IRC) it sounds like my impression was wrong — and putting fields on users needs more work. So... maybe nevermind.

@Michelle: Er, no. That's an upgrade path from Profile module to Content Profile. It says that it may create an easier upgrade path from Content Profile to Profile 2, but since Profile 2 has yet to be built, we have absolutely no idea what that's going to look like.

In #33 Jen is referring to my comments on IRC about the fact that fieldable users stuffs its fields into the $user object on every page load, as opposed to pulling it in explicitly during user_load(), leading to performance penalties. But I see that it no longer does this, so that concern is more moot now. Though it's pretty buggy still. ;)

On the specific proposal in #31, this strikes me as a support nightmare:

"My user fields aren't showing up."
"Oh, ok. Could you go to the profile module settings page?"
"The what? What's profile module?"

"I want to add a taxonomy term to my user. I can do it on xyz.com but I can't on abc.com, and the screen looks all funny. What gives?"

"Why is Drupal yelling at me to not use it?"

Sorry, but -1 to different behaviour for different people, and a big -1 to nagging/strong-arming people out of options, esp. when this strong-arming is done by dark internal magick involving one-off hacks.

@webchick: I realize that. My point is that sending profile off to contrib wouldn't leave people stranded because there is a path forward to fields using nodes for now and eventually to fieldable profiles. It's a moot point, I guess, since you made up your minds already but I wanted to clarify that there is a way forward for those on core profile currently.

Michelle

> 4. Get rid of the ability to turn on Profile module manually. No more checkbox on the modules page.

I think it enough to add some explanation about the situation in the module's help - like this we won't introduce even more weird things than we have to.

Priority:Critical» Normal

Per #29, downgrading to normal.

Priority:Normal» Critical

Hm. I don't think this is normal. It's a tremendous wtf. We need some sort of resolution here.

Priority:Critical» Normal

Not critical. Please read and understand Priority levels of Issues, thanks.

Title:Remove the UI for fieldable usersMark profile module as deprecated
Status:Needs work» Needs review
StatusFileSize
new2.15 KB
PASSED: [[SimpleTest]]: [MySQL] 28,780 pass(es).
[ View ]

Patch per #29 and #36, let's just admit we left a huge wtf in core and explain it. I'm currently working on a site which needs a few fields on users, and it's 100% a valid use case. I also remember doing some horrible things with 'administrative' fields and hidden profile fields, which you can also do with fieldable users when you need those things (like boolean fields to indicate some random thing set somewhere else). Let's not hamstring user module further because profile module is still a pile of crap.

Profile 2 is still a pipe-dream last I checked. It hasn't had any dev on it since Jan 20. No official releases. I see absolutely no reason to link to it explicitly in core.

I'm also not sure of this option, in general. There are indeed reasons to use Profile module: if you need more fully-featured profile features than simply sticking fields on users. Which is why it's sitting in /modules to begin with; we don't have a replacement for it.

Title:Mark profile module as deprecatedResolve the conflict between the fieldable users UI and the profile module

Sounds like there is still absolutely no consensus on what to do here.

subscribing

I don't see how this issue is "Normal" - it certainly qualifies for this portion of Critical - "Basically if the project (core, module, theme, etc.) can't be used as intended, then it is a critical problem. "

Priority:Normal» Critical

I think this is critical. The profile module uses the word "fields" all over the place, and no normal user is ever going to understand that there is NO relationship whatsoever between those fields and user fields. (I've lately seen even experienced Drupal users be confused by this.)

So, rereading this issue, since the DrupalCon San Francisco release "deadline" for D7 came and went, is there now no longer any rush - i.e., can a fieldable profile module still happen? :) :) If not, then the only thing that makes sense is to remove the fieldable users UI from core.

subscribe

Subscribing.

Priority:Critical» Normal
StatusFileSize
new652 bytes
FAILED: [[SimpleTest]]: [MySQL] Invalid PHP syntax in user.module.
[ View ]

This confusion exists even in Drupal 6 - someone in #drupal two days ago wanted to know which module was adding 'taxonomy terms' to Drupal.org user profiles. The only way this could be critical, is if an(other) exception was made to rip profile module apart and put it back together again, the decision was taken not to do that several months ago.

So back to normal, but here's patch which does what David suggests.

The only sane thing to do here is to remove the profile module from core. The whole "profile2" discussion stalled this issue with no good reasons: profile2 is more the successor to "Content profile" then to fieldable users.

Status:Needs review» Needs work

The last submitted patch, make_users_crap_cos_profile_module_is_even_crapper.patch, failed testing.

When this issue #501408: Display user fields on registration form get's submitted (to core), we're one step closer to solving this issue, I guess.

Priority:Normal» Major
Status:Needs work» Needs review
StatusFileSize
new683 bytes
PASSED: [[SimpleTest]]: [MySQL] 25,212 pass(es).
[ View ]

This was originally marked critical, so I'm at least bumping to "major" - this has the potential to really confuse people.

Here is a reroll that doesn't have the PHP syntax error :)

An alternative (perhaps strawman) proposal: Instead of removing the user fields UI completely as this patch does, maybe we could have this code live in profile_entity_info_alter() instead (plus some text in the profile.module description explaining the difference in the two approaches). That way, core still ships with a user fields UI, and you can use either that OR the profile.module, but are not allowed to use both at the same time.

-1 for this. We are not removing the recommended way to extend users because some folks were not pleased with how completely or quickly we removed the old one. We tried really really hard to remove profile module, and the thanks is to remove Field UI instead. No No No.

Feasibly, if Profile2 got into D8 we would still want fieldable users then -- things like an avatar or signature probably belong on the user object rather than profile items.

> Feasibly, if Profile2 got into D8...

We don't have to wait for D8 for use cases -- OG7 is already relying on fieldable users.

Status:Needs review» Needs work

Feasibly, if Profile2 got into D8 we would still want fieldable users then -- things like an avatar or signature probably belong on the user object rather than profile items.

Profile2 implements profiles as separate entities, which makes much sense to me and I think this should be the way to go for D8 too. With that, fieldable user accounts still make sense for creating account settings, e.g. to add a simple checkbox "Yes I have and acknowledge your ToS" or whatever *or* even as simple profile solution.

So in regard to UX I'd prefer trimming the account settings fields to them what they are already are, account settings fields + advocate profile as the core profile solution (as it is). This would also fit to separating profiles and accounts in d8 as per #301071: Remove profile module from core. Of course this doesn't keep users from using account settings fields as a simple profile solution if they prefer.

-1 for remove the fieldabe user account settings UI too. People very much like that.

I'm with Fago. There are a lot of small things where you might want to add a field to a user without it being a full blown profile. And a full blown profile really is a separate piece of content and not really part of the user even though it's connected to the user.

Michelle

Priority:Major» Critical
Issue tags:+beta blocker

I'm still not ultimately sure what to do here, but we have to figure it out soon.

Status:Needs work» Needs review
StatusFileSize
new613 bytes
PASSED: [[SimpleTest]]: [MySQL] 26,385 pass(es).
[ View ]

How 'bout this?

Looks good to me:

D6 sites with it installed get an upgrade path.

New D7 sites are protected.

Masochists can alter it back in again with profile_module_unlock_system_info_alter() from contrib if they so desire.

Said contrib module does not need an alter, all it needs to do is include the profile.install and call profile_schema from its schema. 0 byte unlock module.

Status:Needs review» Reviewed & tested by the community

+1 for chx patch in #59. Tested and loved. And apologies for writing so much. You'd think Profile module killed a member of my family, but really, it's nothing personal.

This goes against webchick in #34, but the thrust of that argument is to not sow confusion and make support difficult. And there i think we are all in complete agreement. Here's the case for minimizing the presence of Profile module as it exists in D7 today.

Hiding Profile module from new Drupal 7 sites is the most honest thing to do. While Profile module works, and D6 sites using it will be able to upgrade to it, few Drupalistas have recommended it for at least two Drupal versions now. Dries prematurely showed its tombstone two and a half years ago in Boston. It will be reborn in Drupal 8 with Fields – the main thing that held it back in D7, other than the timing of Fields UI getting in, was the upgrade path, and i bet this gets worked out in contrib - but simply having the module selectable in core is an implicit endorsement that will irresponsibly encourage people to use it, when we have no one willing to step up and support it.

To quote the eloquent MAINTAINERS.txt:

Profile module
- ?

As far as support, the first question for user field / profile related questions can simply be asking people if they have Profile module enabled. Reducing the number of people who do have Profile module enabled will greatly reduce the support requests and confusion surrounding this. More important, while fields on users will have unpolished bits, and Profile2 is a whole other beast (in alpha now), at least the community at large is actively working on all things Fields and there will be people who actually can answer support questions.

There is no actual conflict between the UIs. User fields as provided by core are managed at /admin/config/people/accounts/fields. Profiles are managed at /admin/config/people/profile. If a Profile category is created, new fields added (unlike the existing username/password and timezone fields) do show up on every Profile category, but this is not a showstopper— it might be the intended behavior for someone.

Yes, there are a lot of confusing things here no matter what (why aren't user pictures a field? What about user signatures? Why don't pictures, user signatures, and user Fields i add show up on the user registration form?). However, getting Profile module out of the way for the vast majority of D7 users vastly reduces the confusion and makes the confusion we will get much more manageable.

"I want to add a taxonomy term to my user. I can do it on xyz.com but I can't on abc.com, and the screen looks all funny. What gives?" — This is a perfect example of why Profile module has to be hidden for all people not already using it in D6 (who likely understand it's historical different path), so that people add real taxonomy terms with core Fields for User accounts or with contrib's Profile2.

The only way to make Profile module – in its current non-Field form – not be horribly confusing for D7 users would be to throw out all of D7 fields.

Please, let us minimize the wasted time Profile module will cause by hiding it from everyone but D6 Profile upgraders.

+1 for chx's patch. No one recommends core Profile.module anymore that I know of. If people ask questions on IRC, I will ask them if they upgraded from D6 & are using Profile module :)

I think I'm OK with chx's patch but I'd love to see some better phpDoc though. Not everyone that looks at the code understands the background and the path we're on. I think the documentation can be made more helpful for those new to Drupal 7.

Status:Reviewed & tested by the community» Needs work

That's a needs work.

And also needs a @todo for D8.

I think I'm okay with this, too. The primary motivation for retaining Profile in core was:

1. No suitable replacement for Profile module in core. Fieldable users is not even half the battle. We also need dynamic listing pages, the ability to assign fields to the user registration form, the concept of field privacy, etc.

2. No suitable replacement for Profile module in contrib. Even MUPP is only at beta-1 atm, and there's still no upgrade path from Profile module more than a year later.

3. The entire concept of "Fieldable Users/Profiles" is something that needs to get vetted before we lock it into core for 3+ years. It looks like Profile2 is poised to fill this niche nicely, however.

4. We can't ship a CMS in 2010 (or possibly 2011 at this point, sigh) that doesn't have the social networking features offered by Profile module out of the box. On this point, with this patch, we'll fail. But one could argue (and many have) that the trade-off of sticking users with a dead-end social networking solution is even worse.

So in the end, I guess this is the least horrible solution to a truly horrible problem, and I support its inclusion in core as well. I only hope people passionate about seeing this situation fixed get on it early in the D8 cycle so we are actually in a position to follow through with the desires of many people to see an entity-based profile system in core.

Status:Needs work» Needs review
StatusFileSize
new1.29 KB
FAILED: [[SimpleTest]]: [MySQL] 26,458 pass(es), 1 fail(s), and 0 exception(es).
[ View ]

StatusFileSize
new1.34 KB
PASSED: [[SimpleTest]]: [MySQL] 26,370 pass(es).
[ View ]

Even better docs.

Status:Needs review» Reviewed & tested by the community

RTBC, webchick will fix the s/,/. after path on commit apparently.

Status:Reviewed & tested by the community» Fixed

Boom.

Thanks, all. See you in D8.

2. No suitable replacement for Profile module in contrib. Even MUPP is only at beta-1 atm, and there's still no upgrade path from Profile module more than a year later.

Indeed. If I'd have known back in sep. 09 how much time is left to get it done, I'd have certainly not stopped working on profile2 for core. Hard luck. :/

Anyway, I'm looking forward to an evolving profile2 in contrib, so we have it ready for d8.

Status:Fixed» Needs work

I'm confused.

If requiring people to download a contrib module to "unlock" the core profile module is OK, why isn't simply moving the profile module to contrib OK? That would be the same experience for end users, and a lot more normal.

By leaving it in core but making it impossible to turn on, we are left with semi-dead code that we have to maintain. So, would a critical bug in the profile module hold up a core release, even though new sites can't turn it on? Or what about a security issue; if someone discovers a security issue in profile module, we obviously still have to release Drupal 7.1 for it. What would the S.A. look like? "This vulnerability is mitigated by the fact that it is impossible for most Drupal sites to turn on this module." That's just silly.

I don't understand why we can't do one of the following:

  • Just move the module to contrib. Someone needs to explain why that is materially different from the committed patch. Sites upgrading from D6 can download it (just like they have to download any other module that was moved from core to contrib if they want to keep using it). I completely do not understand the difference, except that the situation introduced by the patch that was committed here is way more confusing to explain to normal humans.
  • Or, if it's important to leave the profile module in core, we could simply discourage people from using it by renaming it to "Profile (Legacy)" and changing the description. There is already a patch in #40 that basically does that. That seems like an honest approach also. (Its architecture is legacy, but it's still functional, and it has some features that other modules just don't have. For many sites, especially simple ones, there is no reason not to use it.)

Your second solution won't work, thats simply moving the problem towards the interface.

+1
http://drupal.org/project/profile
seems to be unused currently (unpublished?)

Let's see what Dries or webchick have to say.

Heh, if you're going to use http://drupal.org/project/profile, we might as well move Profile2 into that namespace as the D7 branch...

http://drupal.org/project/profile dates back to 2003. Looks like it's just a placeholder to prevent anyone from naming a contrib module the same as core. The commits associated with it look like very old core: http://drupal.org/project/cvs/3280

Michelle

Priority:Critical» Normal

@David: leaving it in core means that there has to be a resolution to the upgrade path early in the D8 cycle (or it's going to look very stupid), moving it to contrib leaves it completely in the wild. It also means that D6 sites upgrading have the same experience as they do now.

If a D8 solution materializes, it may well be possible to backport that to profile2 in contrib (or it might be a forward port of profile2, or a bit of both) - that could even use the 'profile' namespace even while the module is in core - this is the case with simpletest 7.x-2.x at the moment.

Also this isn't critical any more, but not closing it again since these are valid points.

One more thing - absolutely no-one has volunteered to maintain profile module either in core or contrib, so it would be completely abandoned in contrib, even hidden in core it will get basic maintenance for security etc. It's very likely that the Drupal 7 Drupal.org will still be using it, for example.

I'm not aware of any core modules in Drupal 7 that actually store publicly facing data which were moved to contrib. Some features got removed but that was only config stuff, or oddities like taxonomy synonyms which didn't really have a user base in the first place. Getting modules ripped out of core is not easy, saying this as the person who opened many such issues this release and succeeded with a couple of them.

flobruit did offer to maintain Profile module in core back in Paris, but has not been very active since, so my confidence level is not high. I agree with catch's objection to moving Profile module to contrib, especially now.

However, David's "rename + warn" approach actually sounds quite appealing. No black magic & user confusion involved, and we did once ship with a blanket "Legacy" module in core for a similar purpose. Not sure how I missed that suggestion in all the back-and-forth above, sorry.

Sorry, but shifting this problem to the UI is really a bad way of dealing with this issue. It shows how little we know of our users, because even the idea of a legacy module is pretty confusing - requiring the user to also read a warning (which is tucked away in an area, most users dont read) to somewhat understand what is going on, is even worse. Sorry, but you are now just opting for the fast track that just moves the problem to the UI, it does nothing to actually solve it.

I dunno, Bojhan. The problem is already shifted to the UI given the patch in HEAD. "How come on foo.com I have a Profile module, but I don't see that option on bar.com?"

A minimal UI change could be just in the modules page (which is already directed towards technical users) and says:

"Profile (legacy) / Supports configurable user profiles for sites upgraded from previous versions of Drupal."

Then a sentence added to the Profile module help page to direct them to admin/config/user instead.

This approach would at least provide more consistent UX across all D7 installs.

If it helps, in the event it got moved to contrib, I'd be willing to sign up to maintain it, at least at the same level the community currently "maintains" it in core (which basically means, fix critical bugs as they come up, and otherwise review/commit smaller bug fixes only if anyone else happens to actually write patches for them). The profile.module issue queue is not exactly overflowing with activity :)

There's also no reason it couldn't be renamed 'profile_legacy' in contrib, to free up the namespace - although obviously the upgrade path would be simpler if it kept the same name.

I'm happy with either solution, though.

@webchick Sorry, but I don't think we should think so lightly of introducing the concept of a legacy module. You are weighting two UX problems against each other, and in my eyes choosing for the one with the biggest impact. You are in a sense telling our users that there can be normal modules and legacy modules, this is a confusing model.

I would rather have a smaller amount of people be confused by Profile & Profile fields, than impact the majority with the concept of two different kind of modules, legacy and non legacy ones. Please consider a different solution, introducing a new UX WTF to solve another UX WTF is a lose-lose situation.

If it *is* still an option, then I'd also vote to move Profile into contrib as is. That would

1) completely avoid confusion, regardless of whether for new or existing users.

2) allow fago + others to work on Profile 7.x-2.x, possibly based on Profile2; ditching that separate project, plus potential re-inclusion into Drupal core for D8. And FWIW, if there is a sign of agreement, I'd immediately go ahead an assign fago as new owner of Profile project.

From all possible options, this one makes most sense to me.

@Bojhan: I strongly disagree with you on the relative confusing-ness of these two proposals.

The difference between fields in Profile module and fields in D7 is categorical, both in terms of UI and in terms of how they are represented in the system. I can't imagine how difficult it would be to try to debug issues with people in IRC or the forums if they are talking about fields, and I have to ask, "Do you mean fields-in-profile-module or fields-attached-to-users", or the like.

I think we should just keep the module hidden. Moving it to contrib would be terrible for security, unless you want to leave D6 users with no upgrade path, other than a one to Profile2 that may not materialize for months, if ever.

Moving it to contrib would be terrible for security, unless you want to leave D6 users with no upgrade path, other than a one to Profile2 that may not materialize for months, if ever.

I don't understand this statement. Why do you say that moving it to contrib would be terrible for security?

And D6 users who want to stick with the profile module in D7 already have an upgrade path (not that there's much upgrading to be done, of course, since barely any changes were made to the module).

It would be terrible for security because if there is a widespread sechole that requires patching up say every form with a checkbox in core then profile might get left out. I presume that's the problem? (Oh Lord, that would be so much fun)

Fwiw I 'd personally be fine with profile being moved to contrib, I just don't think anyone will persuade webchick or Dries, and there are some valid arguments not to given where we are in the release cycle. However if David is offering to do emergency maintenance that would be my only real concern taken care of. One more thing to bear in mind is the various crap in user module like categories that in practice only caters to profile. I don't know if it will be easier or harder to rip that out for d8.

Yet another option. If Dries is concerned about dropping profile from core and it never getting back in, nothing stops it being immediately recommitted to head as is on the day Drupal 8 opens up. The only question then is it's fate during the d7 release, locked in the cellar or out in the cold :p

What chx says in #86 is what I was thinking of - I thought that was a possibility people raised earlier in the thread.

But I will defer to more experienced people on this. I just don't think Bojhan's idea in #82 (essentially revert the hiding of Profile module) is a good one.

I'm removing the beta blocker tag for this. If this ends up getting moved to contrib, the default Drupal 7 UI will be exactly the same.

@EvanDonovan Sorry, I didn't mean to purpose reverting the hiding. No UI is a good UI :) I am just against moving the problem towards the UI. Even then I don't really concider the difficulity it would be for support requests.

@Bojhan: Ah OK. I misunderstood you. If you are in favor of the status quo as of #67 I am in agreement :)

Just need to keep track of this thread... I thought this was resolved, but apparently not?

@BenK: as far as I can tell, everyone is happy with the status quo (profile module will only show up for people who are upgrading from D6, and have already used it), but David Rothstein suggested that simply moving profile module to contrib would be better, and some people agree. However, there's not really anyone who offers to maintain it.

I think this should be moved back to fixed, but it would be webchick or Dries' decision.

I offered to maintain it in contrib (in one of the comments above), and my offer still stands.

Or if we keep it in core and decide to let it be enabled, one thing to keep in mind is this: In addition to (or instead of) using the module name/description to inform people that it's a legacy module, one simple thing we could do is stop using the word "field" anywhere in the profile module's user interface. The use of that word is likely what leads to the biggest confusion between this and user fields when both are enabled. If we replaced that with a different word, I think that would mostly solve the original critical bug that started this issue.

Today I had a minor WTF moment when I went to revisit this issue #776936: PHP Warning when viewing /profile after adding field and couldn't even find the profile module. How should I go about working on a profile module bug without an easy way to turn on the profile module?

FWIW, I dont think this kind of bizarre exception should be allowed. I support the move profile to contrib suggestion...

I had the same WTF moment that bleen18 had in #96: I picked an item from the NR queue for Profile, installed a fresh copy of D7, went to the modules page in an attempt to enable the Profile module and scratched my head.

I first verified that the profile module did exist in the modules directory. Then opened the .info file to see if maybe it was renamed. Then re-opened the modules page and read through it carefully. Then tried my browser's 'find-in-page' function to see if I somehow missed it. Then went to Core's Profile issue queue to see if anyone else was having this problem, which is where I saw #958086: Profile module missing from module list.

My concerns with the current solution are:

  • Advanced users won't be able to figure out why they can't see the Profile module even though it's there. They'll need to dig through the code to find the hook_system_info_alter, or they'll need to visit drupal.org to figure it out. AFAIKT, the pattern of hiding modules through hook_system_info_alter based on certain conditions is unique to this issue, and as such won't be recognized by most.
  • For those users that are aware of the reasons why Profile is hidden but still want to enable the module (for example, bleen18 and me ;) ), un-hiding the module seems less than trivial. Do I write my own hook_system_info_alter_implementation to override user_system_info_alter? Do I create the profile tables manually and then try to install the module?

tl;dr: subscribe ;)

We know it's confusing, but at this point it's really the best we can do.

  • We cannot remove the Fieldable User UI in the profit of the legacy profile module (no way!)
  • We cannot remove the Profile in the profit of the Fieldable User UI either, because a few things are missing (from the top of my head):
    • A migration path (that's actually easy, once we have the other things)
    • Ability to show fields on the registration page
    • A URL field (probably easy)
    • A date field (probably hard)
    • Support for profile categories

I believe that the solution that got implemented here is the best we can do. It clearly gets the Profile module out of the way for new deployments, and keep the upgrade path for legacy use cases.

Status:Needs work» Needs review

#40: deprecate_profile.patch queued for re-testing.

Catch's patch from #40 labeling the Profile module as deprecated should be applied as well. At least mr.baileys would have had a heads up on his second step! Also i will add how to unlock it to the Drupal 7 handbook page.

StatusFileSize
new1.32 KB
PASSED: [[SimpleTest]]: [MySQL] 28,777 pass(es).
[ View ]

Can we reverse the logic? The current situation has the Profile module visible by default, and then hides it in user_system_info_alter() if the profile tables are missing (ie not an upgrade):

<?php
function user_system_info_alter(&$info, $file, $type) {
if (
$type == 'module' && $file->name == 'profile' && !db_table_exists('profile_field')) {
  
$info['hidden'] = TRUE;
}
}
?>

Given that we only want Profile showing up for a small fraction of sites (sites that were upgraded from D6 and use the profile module), it makes more sense to hide the profile module by default ("hidden = TRUE" in profile.info) and then set hidden = FALSE in user_system_info_alter() if we need the legacy support for profile.

Since profile.info is one of the first places to look at if you're trying to troubleshoot why profile is missing on the module page (rather than user.module), this would give an additional clue as to why that is.

(btw, the shortest way to enable Profile for development purposes I could find is drush en profile -- might be good to mention this option in the "unlock handbook page" mentioned in #100)

Re #98: Other than "its just too late with RC1 right around the corner" what reason is there not to move profile to contrib and then change the upgrade path to "if you are using profile module in D6, install the contrib profile module for D7"? In theory we could even use the update manager to do the download/install during the upgrade... This strategy would satisfy:

  • pushing field UI as the new/best practice for D7
  • create a simple upgrade path
  • avoid the big WTF described in #96,#97

Of course, "its just too late" is probably the answer right now ... but it makes me sad

#101 looks great. RTBC if the test bot comes back green.

Status:Needs review» Needs work

Let's also add a code comment above hidden = TRUE to explain why this is done. That would also alleviate the WTF in #96/97 without affecting the UI, which Bojhan was concerned about.

Otherwise, this approach looks great.

Status:Needs work» Needs review
StatusFileSize
new1.57 KB
PASSED: [[SimpleTest]]: [MySQL] 28,783 pass(es).
[ View ]

New patch attached that adds some comments to profile.info and refers to user_system_info_alter for additional information.

Status:Needs review» Needs work

+++ modules/profile/profile.info
@@ -10,3 +10,8 @@ files[] = profile.pages.inc
\ No newline at end of file

Please add one :)

Powered by Dreditor.

Status:Needs work» Needs review
StatusFileSize
new1.55 KB
PASSED: [[SimpleTest]]: [MySQL] 28,778 pass(es).
[ View ]

One newline coming up!

Status:Needs review» Reviewed & tested by the community

Great, thanks. RTBC per #103 and self-review.

Status:Reviewed & tested by the community» Fixed

Awesome. Committed to HEAD, thanks!

And yes. "It's too late" is the answer. I keep repeating this over and over, so I guess I'll do it again here. Remember, folks. D7 is done. We got to 0 criticals two weekends ago. We're currently living in a strictly timeboxed "RC slush" phase to try and suss out any last minute horrifyingly bad things, but we're not doing anymore major architecture changes (like ripping a module out of core) at this point.

Status:Fixed» Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

Yay!