I think this module could use porting to D6. Views integration may be an issue initially until things get fleshed out with Views 2. But I think it wouldn't hurt to begin the process. I am taking some initial steps at the moment, mainly out of personal interest in what goes into updating modules.

I will post patches for review as they come.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

rho_’s picture

Status: Active » Needs work
FileSize
11.64 KB

This patch will get the basic Bio module working for D6. Views has not yet been tackled though the original files/functions are still there. So I must say this patch will NOT yet work with views in D6, also CCK has only been lightly tested. It is only the "core" bio module functionality that has been updated thus far.

View I am afraid is going to have to wait until we see where we are when Views 2 releases. CCK is in the works, as well as cleaning things up a bit and commenting. So checkout the patch if you would like to see the progress in updating this module to 6.

The patch was rolled from the modules directory against the 5.1.1 release of Bio.

webchick’s picture

Hey, thanks a lot! I'll try and test this later.

rho_’s picture

FileSize
10.46 KB

Update:
Posting a new patch that fixed a pretty critical issue in the previous one. Another bug remains that I have yet to find the cause of. In the function bio_profile_alter:

<?php
function bio_profile_alter(&$account) {
  if (variable_get('bio_profile_takeover', 0) && $bio = bio_for_user($account->uid)) {
    $bio = node_load($bio);
    $typename = node_get_types('name', variable_get('bio_nodetype', 'bio'));
		foreach($account->content as $key => $content) {
			if($key != node_get_types('name', variable_get('bio_nodetype', 'bio'))) {
				unset($account->content[$key]);
			}
		}
    $account->name = $bio->title;
  }
}
?>

$account->name is being set to the title of the bio node. However when viewing the profile the account name has not changed from the default username. Not sure if this is a bug here or if this is a core bug in hook_profile_alter. Going to keep fishing around before an issue is submitted. Any ideas or input would be helpful. Also, all views and CCK related functionality has been commented out for the time being.

Once again this patch was rolled against Bio module version 5.1.1 from the sites/all/modules directory.

fago’s picture

also check out http://drupal.org/project/content_profile
Read about it here

flickerfly’s picture

Title: Porting to D6 » Port of Bio to D6

I was just listening to http://geeksandgod.com/episode83 and they were saying they'd use this module so I'm looking for it on D6 to check out. :-)

bonobo’s picture

For D6, is bio going to be phased out in favor of content_profile? Personally, I like the simplicity of Bio, and would like to see Bio continue on. If the maintainers of Bio are planning on keeping it around, we'd be glad to put some time into the port.

NikLP’s picture

Anyone making any moves to continue the port to D6? Views is going to hit RC *very* soon now, and CCK is right on its heels...

webchick’s picture

If anyone submits a patch, I'll look at it. This isn't on my radar anytime soon. It'd be neat if said someone reviewed content profile module to figure out if we do indeed need to port this module to 6.

bonobo’s picture

I'll try and check out content_profile in the next couple days --

One of the things I like about bio is the simplicity of it -- it doesn't overreach, and it works. I hope that simplicity is retained in content_profile -- if not, we might port bio over to D6

NikLP’s picture

Since I've given this more thought in the last couple of days, I realise that I will probably require more than one profile type on my site, which I expect falls into the node_profile camp much more than Bio's sphere (arf).

I suppose the most obvious question should be: will content_profile support both single AND multiple profiles (per site/role), and will it retain enough simplicity that bio can be "dismissed"?

webchick’s picture

I don't know. :) I would appreciate it if someone would investigate that and let me know. I won't have time to sink time into this unless it falls under work-related stuff.

fago’s picture

content profile supports multiple profiles and is intended to be simple. So please check it out and help improving it.

NikLP’s picture

@Fago, cool - at the risk of incurring your wrath, would you be able to elaborate some on how the c_p module differs from bio/n_p? Perhaps on the module page? I tried to find more but I couldn't find the link I did have, and there is little in the way of comparative information on the project page.

Many thanks...

fago’s picture

I don't think it makes much sense to make a comparative page for 6.x before the modules are finished..

Anyway, so far content profile supports multiple profiles but is kept simple, so far it doesn't support:
* user registration integration
* user edit categories integration like nodeprofile had in 5.x
* profile page take over like bio had in 5.x
* content links to author's bio like bio had in 5.x

Although imo the last one might make sense to be in the content profile base module. For the other ones I think extension modules are the right choice. Content profile already comes with a light-weight way for storing profile specific settings for extension modules.

Furthermore there isn't any views integration yet.

bonobo’s picture

Have done a quick comparison of content_profile (in D6) and bio (in D5) --

Some quick thoughts:

1. The way Bio integrates with the default registration process is a killer feature. The absence of this in content_profile (at least in its current version) is significant.

2. The admin features of content_profile are linked to node types, so to administer a user profile you are administering a content type. In practical terms, this means that only users who can admin content types can admin profiles; these rights should probably be separated. With that said, actually changing the structure of the bio node type could only be done by users with admin content type rights, so this is somewhat of a wash.

3. The ability to have the bio node take over the user profile page is a nice feature. While this could easily be accomplished using content_profile using the theming layer, given that it could be done without touching the theming layer using bio in D5 this feels like a step backwards.

4. As noted by fago in #14, the ability to link to a users profile/bio from posts is not present.

In short, bio does a few things well:

a. integrated with the default registration process;
b. exposed some flexible presentation options via the admin UI;
c. tied a node to a profile, thus allowing the flexible use of cck and taxonomy for profiles

Content_profile does c, but does not currently implement a or b.

My preference moving forward:

Option 1: port bio to D6. For use cases requiring multiple profiles, extend bio with a helper module.

Option 2: develop a and b into content_profile --

Of these two options, I am leaning toward Option 1.

Thoughts?

webchick’s picture

Wow, excellent! Thank you for investigating into this, Bill!

I'll defer to fago on whether Option 2 is on the table, since he wrote content profile. It seems to me that a) in particular is going to need to be implemented by both Bio and Node Profile, so it makes sense for that much at least to be in Content Profile. Probably Views integration, too.

fago, what are your thoughts?

NikLP’s picture

I concur with 1), because for a start it seems to be a lot closer, although again I think that multiple profile types is definitely missing from this (the fact that Bio is designed to be lightweight/simple/etc notwithstanding).

I need something akin to this (with multiple profile type support) in the near future and probably can justify some spend if someone wants to investigate the multiple thing further for me. I can't totally commit to this yet as I have more preparatory work to do, but a large part of my current project is going to depend on a solution to this, so I'm all ears.

fago’s picture

as already discussed here - I think we should have at least a common base module - for which I've created content profile. So far there was unfortunately no further input, so what's left there is my work. I encourage everyone who wants to work on profiles as nodes to help developing content profile.

To the points:
a. integrated with the default registration process;

yep, that's needed. However there are different approaches for this, so imo this goes best into a content profile extension module.

b. exposed some flexible presentation options via the admin UI;

There are presentation options per content profile? If there are not the right one - let's include them.

And to the options:

Option 1: port bio to D6. For use cases requiring multiple profiles, extend bio with a helper module.
Imo this would be totally unnecessary duplication of code and a duplication of the needed effort. Then furthermore things like views integration have to be developed twice and further modules extending a profile as nodes solution would have, if they'd do, to write support for both modules. Imo that's the worst possible "option" that has to be avoided and this is why I started the above linked discussion.

Option 2: develop a and b into content_profile --
Why not? However personally I'd prefer to keep the "base module" as simple as possible. So complicate things should go into extension modules - of course what things should go in there and what things should go in extension modules needs discussion.

@concur with 1), because for a start it seems to be a lot closer, although again I think that multiple profile types is definitely missing from this:

Where is this closer? content profile already works and supports multiple profile types. "Extending bio" to do that won't work without changing its whole code.

bonobo’s picture

Hello, fago,

I followed the g.d.o thread closely as it unfolded, although I didn't chime in.

Some thoughts here:

1. Basic multiple profile types would be readily available in D6 using either profile field access control (which works our of the box w/cck) and/or a combination of core profile fields and bio nodes. Given that views2 can pull profile data, there are some options here that would support at least three different profiles with little fuss (first profile, use core profile module; second profile, one set of fields on the bio node, third profile, second set of fields on the bio node). With that said, I've never needed multiple profile types, so it hasn't been a pressing issue for me. But this seems achievable now, with a port of bio to D6, with *no* additional code.

RE: "There are presentation options per content profile? If there are not the right one - let's include them." -- the admin screen for the bio module (seen at admin/user/bio ) exposes some very useful functionality. And when I say "very useful" I mean essential. Without this functionality in place, the rest of this conversation is moot.

As to the conversations about duplication of code/effort, I agree that duplication should be avoided whenever possible. I actually wondered why you didn't start with a port/refactoring of the bio module from D5 to D6, but assumed that your past work on usernode/nodeprofile/nodefamily inclined you away from that direction.

Right now, the functionality of the bio module in D5 comes close to being ideal for our needs.

The core pieces:

1. works with the default registration process;
2. Can be used alongside default profile module, or as a drop-in replacement;
3. Has useful admin options at admin/user/bio; and these options are separated from the administer content types options

And, assuming this basic functionality existed in D6, three different types of profiles could be supported with no additional code.

Which leaves views integration, which will need to be written in any case. So on the basis of this, yes, using bio does feel closer.

A simple base module is a great place to start. However, sacrificing needed functionality is too high a price to pay. I would like to get consensus on this, and we are willing to put developer hours into making this work, but at this stage of the game I am not convinced that content_profile is the way to go -- which was the reason for my original question in this thread. Also, a web of dependencies (ie, a simple base module requiring extension modules to deliver advanced functionality) can be unnecessarily complex for end users to navigate -- while the simple base module makes sense architecturally, building off that simple base needs to be invisible to the end user -- and this is where bio's scope was very well conceived.

bonobo’s picture

One other thing --

I recognize that using profile field visibility for multiple profiles is a dirty ugly hack -- it would work, and even work well for many use cases, but it's not elegant.

However, from a development perspective, setting up relationships between nodes is pretty straightforward -- and given that views2 supports nodereferences, supporting multiple profile types doesn't seem that complex, and certainly shouldn't be a showstopper.

My concern: most of the sites we develop has a rich user profile component. This piece needs to be solid, and relatively future proof. Bios' simplicity is its greatest asset -- both for use now, and for upgrades later.

NikLP’s picture

I honestly don't care which option is taken, I just need it pretty darn quickly. So if we have to get together at some point to thrash this out, all well and good, and I potentially have a few hundred dollars to throw at it.

@bonobo: The Bio approach to multiple profiles using field visibility is pretty grim, I concur. Ok for "slightly" different profile types, but not completely...

fago’s picture

>I actually wondered why you didn't start with a port/refactoring of the bio module from D5 to D6, but assumed that your past work on usernode/nodeprofile/nodefamily inclined you away from that direction.

I'd thought about just using bio as "base" module, but I think the base module should support multiple profiles - or say it in another way - different profiles for different user roles. Which is absolutely no big deal with nodes - as it's basically there, so I don't think it makes much sense to restrict the profile to one content type.
So it was much easier to start with the nodeprofile port, as it already did that. And of course, as I unfortunately no one was helping me, it was more straightforward for me as I know the nodeprofile code. Furthermore I think it's code is cleaner.

>However, from a development perspective, setting up relationships between nodes is pretty straightforward -- and given that views2 supports nodereferences, supporting multiple profile types doesn't seem that complex, and certainly shouldn't be a showstopper.

Yep, that's an interesting option - but this is how I see "complex profiles" - being one profile consisting of multiple content types. For this I'm using nodefamily - which I also plan to do for 6.x as content profile extension.

My concern: most of the sites we develop has a rich user profile component. This piece needs to be solid, and relatively future proof. Bios' simplicity is its greatest asset -- both for use now, and for upgrades later.

I agree, but putting every feature in a single big module is not what I'd call a simple, solid code. It's simpler to install.

>3. Has useful admin options at admin/user/bio; and these options are separated from the administer content types options.

Does that make much sense? What does it help when I can select the content type that is the user profile, when I can't administer this content type?

>1. works with the default registration process;

Of course this is needed for content profile too. If someone helps maintaining it, I can think of putting the "bio way" of doing this in content profile - so this doesn't depend just on me.. But if no one steps in and helps, I'll probably do it that way I'll think it's best or perhaps I won't do it all.

bonobo’s picture

RE: "I'd thought about just using bio as "base" module, but I think the base module should support multiple profiles"

Now I think we're getting somewhere --

For our needs, multiple profiles is less important, particularly as leveraging it requires another module (nodefamily) to access it. When we deliver sites, as much as possible, we attempt to be wary of YAM (Yet Another Module) Syndrome. Having multiple profiles as part of the base module is less important that user registration piece, and a clean admin UI.

RE: "but this is how I see "complex profiles" - being one profile consisting of multiple content types." That is one way of doing it; but certainly not the only way. A base module should support the framework, but not mandate one specific approach to the exclusion of others, especially on something that can be achieved in different ways. Different orgs use profiles for different things.

RE: "putting every feature in a single big module is not what I'd call a simple, solid code. It's simpler to install." Crap code is crap code. Period. However, what I refer to is clearly defining a scope that identifies primary and secondary needs. Primary needs get addressed within the base module, and secondary needs can be addressed via helper modules. And obviously, the execution of the clearly defined scope requires well-written code.

And "simpler to install" matters -- this is a usability issue. A clean, intuitive admin UI is invaluable, and needs to be considered when clarifying the initial scope.

At the risk of stating the obvious, we are looking at a solution that we can use as we transition from D5 to D6, and we are doing this *prior* to putting development hours into the project, as we want to avoid duplication of effort. We also recognize that our choice could potentially have us working on a specific piece of code for the entire D6 lifespan. Given that we already maintain or co-maintain several modules on d.o, we're obviously fine with that. However, statements like "But if no one steps in and helps, I'll probably do it that way I'll think it's best or perhaps I won't do it all." don't inspire confidence in a collaborative working environment -- I'm not reading too much into it, as it's way too easy to misunderstand someone's intentions in a text discussion, but one possible interpretation of this statement is that you are only really open to patches that support your specific roadmap. Given that this conversation has shown some differences between your goals and what we need, part of what I need to evaluate as we move forward is how easy any resulting code would be to maintain over time.

If I'm missing something, please let me know.

fago’s picture

>For our needs, multiple profiles is less important, particularly as leveraging it requires another module (nodefamily) to access it. When we deliver sites, as much as possible, we attempt to be wary of YAM (Yet Another Module) Syndrome. Having multiple profiles as part of the base module is less important that user registration piece, and a clean admin UI.

Do content profile require any further modules? no.
Multiple profiles means that you can mark multiple content as independent profiles - no more, no nodefamily requirement.

>A base module should support the framework, but not mandate one specific approach to the exclusion of others, especially on something that can be achieved in different ways.

agreed. But that's hard to achieve if one person is developing the base and others, possible creators of other ways, don't care about forming it.

>Given that this conversation has shown some differences between your goals and what we need, part of what I need to evaluate as we move forward is how easy any resulting code would be to maintain over time.

hm, obviously I started the discussion about how the solution should look like because I planned to do it like I want? hm..

I've always invited others to join content profile development - just read above. But of course I'm looking at my use cases and plans, as it's the solution should - at best - cover all.
As no one cared, I started writing the base on my own and did my best to make a clean and simple base module, which we could be built upon. With the result of getting blamed about just coding for my needs and to scratch my own itch, but it looks to me thats that what you want - so do it.

webchick’s picture

Fago's original proposal of taking the similarities between the various "user profiles as nodes" modules and moving them to a central, single module that handles all the "plumbing" that each module can layer on top of, sounded really good to me when it was proposed. There's a lot of code in Bio and Usernode that are essentially complete duplicates of one another -- for example, CRUD synchronization between users and their nodes (I delete a user, and its profile is deleted as well), adding CCK fields to the registration form, Views integration, etc. Furthermore, it's really difficult to write a module that depends on users as nodes, because both Bio and Usernode do things slightly differently.

Unfortunately, the timing of all of fago's work hit just after I finished up my work on Bio for the project we used it on, and was spending my time working on other projects instead. It also hit during Summer of Code prep time, and the big push toward unit testing in core, which together sapped up all of my non-work "fun" Drupal time. I took part in the discussions, and watched things progress with half an eye, but couldn't jump in and spend the requisite time to help fago in his quest. I had hoped some of the other participants from that thread could instead, but I guess not.

Bill has done a very good job of articulating the fundamental architecture differences between Content profile and Bio module, and moreover making the case for why the use case still stands for each user having only a single node associated with them. So although I'd love to NOT have to port Bio to D6, and instead have Content profile be The Unified Way Forward (tm), it sounds like there are compelling reasons to keep both options.

I've talked to jjeff, and he's fine with adding bonobo (or whoever from FunnyMonkey) to the list of co-maintainers for this project so that you can create and commit the D6 port.

bonobo’s picture

We'll take a look at both, with an eye toward achieving One Way Forward -- eliminating duplication would be a great thing.

@fago -- thank you for your feedback and input.

RE the other maintainer, it will probably be either jgraham or marcp -- we'll sort that out internally. But it definitely won't be me -- they're the ones who do anything useful :)

fago’s picture

@webchick:
Thanks, I know you were busy with other things. I was hoping too that someone engaged with bio steps in and helps making content profile right for the bio users. Maybe the mistake was to keep support for multiple profiles - I don't know.

Anyway, content profile is now here and I'll keep and maintain it as successor of node profile (not usernode - usernode was never intended to be a profile as node solution although some people used it for that. As views supports listing users now, I don't port it to 6.x anyway.).
If bio does its job good, perhaps I won't port the further features of node profile (user registration integration, user edit categories integration) to 6.x - as then it's possible to use bio for that (even together with content profile).

@bonobo: >eliminating duplication would be a great thing.
That was my aim, but obviously I failed :(

NikLP’s picture

I am more confused than ever now...

If there is a need for one profile node per user, and also multiple profile types, one/many per role, then surely it makes sense to make this a core feature as this will clearly go a long way to avoiding code duplication? I can't see that including support for multiple types is going to add all that much bloat to the code, and there are obvious advantages to eliminating the "which module?" question that we currently face with Bio/N_P.

I'm not really sure what, if anything, we've decided on from the comments above...? :/

catch’s picture

It'd be a real shame into have both modules in D6 given both webchick and fago (and everyone else) are keen to narrow down on one implementation (at least for the basics).

Initial patch on this thread has a lot of code style issues making it hard to review, how hard would it be to port the D5 bio stuff that's not in content_profile over?

bonobo’s picture

@NikLP --

We will be looking at porting Bio to D6 -- the following features of Bio in D5 have proven critical over the last year:

1. works with the default registration process;
2. Can be used alongside default profile module, or as a drop-in replacement;
3. Has useful admin options at admin/user/bio; and these options are separated from the administer content types options
a. From end-user feedback, the ability to specify how the bio node relates to the default user page via the ui is a valuable feature
4. Views integration.

One other aspect that has not featured in this thread is an upgrade path from D5 to D6. I haven't tested content_profile in an upgrade scenario, but my (perhaps incorrect) assumption is that transitioning from Bio in D5 to content profile in D6 would not be seamless.

@fago -- does content profile account for an upgrade from bio in D5 to content_profile in D6?

Our first pass goals do not include support for multiple profile types. We have yet to encounter this use case, and given that there is already (limited) support for creating different profile types based on role, it's not on our immediate priority list.

In short, we will port Bio to D6.

HOWEVER: Before we begin work, we will look at the code for content_profile and bio. If at all possible, we will look to unify the work that has already been done -- and if supporting multiple profile types can be done cleanly, then we will consider including it in the first pass.

@fago -- this probably didn't come out in the earlier thread, but I am immensely grateful for the work you have done on using nodes as profiles. You have played -- and continue to play -- a critical role in pushing this forward. WRT "That was my aim, but obviously I failed" -- I definitely do not see it that way at all. You have pushed the conversation and the codebase forward, and have led much of the work that has gotten us to where we are. I am nothing but grateful for your contributions, and look forward to seeing how this can all fit together.

fago’s picture

@fago -- does content profile account for an upgrade from bio in D5 to content_profile in D6?

since February 18, 2008. Have you ever looked at it?
Settings for not (yet?) existing features are of course ignored - so as of now it just marks the bio node type as content profile node type.

@HOWEVER: Before we begin work, we will look at the code for content_profile and bio. If at all possible, we will look to unify the work that has already been done -- and if supporting multiple profile types can be done cleanly, then we will consider including it in the first pass.

If you want a clean support for multiple profile types, build upon content profile.

@points 1-4:
agreed, apart from that I don't see why one should be able to administer profiles as nodes, when one isn't able to administer nodes. If there is a use case for this, I'd like to know (as then it might be worth to improve that).

content profile does so far 2 and 3a.

@I definitely do not see it that way at all.
If there are again two different ways of marking content types as being profiles, my effort failed.

NikLP’s picture

Fago seems pretty adamant that C_P is the way forward, and I have no problem with that, but there is a clear set of stuff that's available in Bio/D5 that needs porting/incorporating into C_P for D6, if that's how it's to be. I have a kind of hunch that multiple profiles should be supported in the base module tho, purely so that we don't end up in the same situ as with ... "all the other modules (that weren't Bio) in D5". That was pretty scary
if you ask me. In the long run, is there some sort of approach we should be taking that could be genericised? Profile API (tm)?

I reiterate that I need this pretty soon (actually, VERY soon), and I really don't have the naus to get involved at a code level - I have way too much else to do, but if someone taps me or whatever .... well, I've made myself pretty clear above I think.

Michelle’s picture

I don't understand what the problem is with supporting multiple content types in the base module as long as that doesn't add any other module dependencies. If you don't need it, then just enable only one node type as a content profile.

Unless I'm misreading this, which is quite possible as it's a long thread and I skimmed a bit, the main hangup is content profile needs to integrate with the user reg process like bio does. That's a priority for me as well and one of the reasons why I switched from nodeprofile to bio on my own sites.

FWIW, here are the features I'd like to see in a combined module:

  1. Mark one or more node types as profile types from the base module without having other dependencies.
  2. Option to auto create a node per user. If there are multiple node types marked as profiles, option per each.
  3. Select which fields on each of the profile node types show on the registration page. These would have to be fields from the node types in #2.
  4. Optionally take over the user view tab like bio does. I, personally, would never use this since I use advprofile, but this is a lighter weight alternative for people who don't to use that.
  5. Editing of the node type(s) as a top level tab like bio does it not secondary tabs like nodeprofile does it.

Once Panels is ported to D6, I'll be turning my attention back to profiles again so I may have more input at that time. But these are my thoughts based on having used both nodeprofile and bio extensively in D5.

Michelle

bonobo’s picture

Basically, what Michelle said.

A few comments here:

RE:

the main hangup is content profile needs to integrate with the user reg process like bio does. That's a priority for me as well and one of the reasons why I switched from nodeprofile to bio on my own sites.

Yes -- this parallels my experience as well.

RE:

1. Mark one or more node types as profile types from the base module without having other dependencies.

Setting this up is not particularly difficult, as has been noted here, based on the fact that it already exists in content_profile, and based on the fact that, off the top of my head I can think of multiple approaches to creating similar functionality. Technically, this is not a showstopper. However, as has been noted here, this functionality introduces the kind of complexity that is best addressed with a clearly defined use case, and reinforced via the registration process and theming -- this level of detail is difficult to achieve with a generalized solution.

Including support for multiple content types as profiles is not difficult, but for simple cases many users will probably be better served by core profile, paired with a single node type and field visibility.

With that said, my opinion is that this is not essential functionality for the core module, but I'm more than willing to shelve that, as any usability issues raised by this can be solved (as Michelle notes) just by not enabling the feature -- and this possibility already exists within the UI of content_profile.

RE:

2. Option to auto create a node per user. If there are multiple node types marked as profiles, option per each.

For the base module, I would prefer to leave this as a setting that could effectively be enforced by requiring a field on a nodetype during the reg process -- ie, if the field is required, the node will be created on registration (unless, of course, users are created programatically, but that use case could safely assume a dev who knew what they were doing, or who should know what they're doing).

RE:

3,4, and 5

Yes, yes, and yes.

My interest in this lies in preserving a balance between useful functionality, ease of use, extensibility, and ease of maintenance over time.

From reading through the issue queue of content_profile and the comments on this thread, it seems pretty clear to me that fago doesn't want to include the user registration within the core functionality of the base module. And that is absolutely his right, and as the maintainer of content_profile, he should follow his inclinations and develop and maintain his code as he sees fit. However, for every site where we rolled out complex profiles last year (in the neighborhood of 5, give or take) we needed this functionality. From our perspective, it needs to be part of the core functionality, and given that it was present in bio in D5 it feels like an unnecessary step backwards to not include it as a central piece of D6.

Truly, we don't care if it's in bio or content_profile -- we are concerned about functionality, a clean upgrade path, and ease of maintenance over time. We can call it the "Drupal Digital Looking Glass" module for all we care. We do, however, want something with well defined core functionality, and clean code. Toward that end -- and to get more robust profile functionality in D6 *now* so folks like NikLP can roll out their sites -- we are putting developer hours into this.

fago’s picture

@registration integration: Hm, why is the registration integration a hangup?
It could be done in extension modules, but I agree that it is a functionality that belongs into the base.

I already said:
If someone helps maintaining it, I can think of putting the "bio way" of doing this in content profile - so this doesn't depend just on me..

So again:
Please join in and help developing content profile! As it should be the base module, it shouldn't be just my module.

@Michelle's features:
1: agreed.
2: I agree with bonobo that for the base it should suffice to use user registration integration. I think it would even create a node if there are no required fields.
3: agreed.
4. I personally don't like it as the module would possible delete profile output from other modules. Anyway as I've already said here, if people want it, let's include it.
5. agreed.

Allie Micka’s picture

Does content_profile intend to have a direct upgrade path for Bio and friends?

While there were other modules occupying this space ( Node Profile, Usernode, Node Family, and other tendrils ), I went with Bio specifically because it wasn't saddled with the interdependencies, talk of base modules, etc. It was simple and sweet.

Bio used UID ownership to link the bio node to its user. It mandated that there be 0-1 bio nodes for each uid. As it matured, I think it was healthy to make additional assumptions, such as putting field information into the registration form. I've built user profile sites with Bio over and over again. And I've found lots of ways to extend bio nodes through node references, field permissions, and other node modules. But I haven't felt a lack of functionality in Bio when it comes to this simple relationship and its views integration.

On the flipside, a series of "partially-functional" or "interdependent" modules is dangerous and needlessly complex. At this very moment, I'm writing a conversion script to address the fallout of a an administrator who was so confused by the limited functionality in usernode, profile, and bio modules; he used ALL of them and is now unable to query his users. Going forward, I'm loathe to explain what a "node profile" or a "content profile" is. Is it content or is it a profile? This seriously breaks peoples' brains.

I think it would be a mistake to overthink the user:node relationship, breaking it into more modules than necessary. And I think it's a mistake to muddy the waters by creating yet another module in the name of reducing duplicate code. There's already too much confusion with the D6 upgrade. Why make it worse by confusing everyone's upgrade paths?

If there's a contingent of people who feel this way, there will almost certainly be a functionally-complete Bio upgrade. If fago is unwilling to participate in that, there will almost certainly be a content_profile module. It's a shame, but maintaining this fork seems healthier than continuing to thrash.

catch’s picture

Allie: please see #31. Fago's already said quite clearly that there's been a minimal upgrade path since Feb 18th - although a minimal one since there aren't (yet) equivalent bio features in content_profile

Also content_profile isn't 'yet another module' - it was an initiative to bring both bio and nodeprofile together in D6 - this was quite clear in the original discussion on groups.drupal.org. I've steered clear of both modules in D5 due to the push/pull between them, and I'm sure others have too. Was really looking forward to a unified solution in D6 which could start weedling it's way into core, but it starting to look like that won't be the case.

fago: would you be prepared to give bonobo commit access to content_profile so he could port some of the bio features over to there?

Allie Micka’s picture

Profiles as nodes is patently hacky. All of these modules are here to sidestep the limitations of Views and the lack of robust fields in Profile. If these limitations were gone there would we wouldn't have to follow users around, trying to pin nodes on them. Especially when that means your 100,000-user site has 100,000 nodes before you add page 1.

Which means that all of these solutions are fairly temporary. That bums me out, but it also excites me. So why not keep one or the other for D6, routing users accordingly. This seems better than expecting everyone to re-learn configuration screens, vocabulary and workflow - just to do it yet again for D7.

NikLP’s picture

Well this is getting off topic... everyone here knows that core profile is pretty crap and not fit for the use cases we're describing here, otherwise none of the modules in question would exist in the first place. The point is, until core profiles support multiple profiles, and more importantly CCK fields, that's not going to change, AFAIK. That, of course, requires custom field support in core, which is another matter entirely.

Views is not a limitation any more but Profile clearly is. The bottom line is, I have a site to build with a minimum of two profile types, 20,000 existing users and I need it done in D6. This is hard enough already without being told that I'm hacking - I knew that already, it's a prerequisite for the job though.

webchick’s picture

@Allie: To summarize:

I'm against "dependency soup" as much as (or more than ;)) the next person. I don't want Bio to be a never ending chain of dependencies, like content_profile.module, content_profile_ui.module, cck_registration_fields.module, node_profile_views_integration.module, node_profile_panels_integration.module, and so on. UGH.

OTOH, I'm also against complete and utter duplication of code, which is essentially what Bio and User node/Node Profile have. Both need to keep track of the node(s) attached to a user, and update/delete/add them as necessary. Both need to provide Views integration. Both need to provide the ability to put CCK fields on the registration form.

When this type of "core" profile functionality is spread across two modules, both are going to do it slightly differently, and both are going to have slightly different bugs. At least that's been the case in D5. It presents users with an impossible choice. It also makes it difficult for developers who wish to create a module that depends on profiles being nodes, as they need to make allowances for both and the weird subtle differences in how they do things.

We could simply port Bio to D6 and use /it/ as the "base" module for all other node profile solutions, except for the fact that fago's users demand the ability to associate multiple nodes (and node types) to users. Bio keeps it simple, by enforcing a simple 1:1 relationship. You can build a 1:1 relationship on top of something that allows 1:M but you can't go the other way.

So what's being proposed here is:

1. A base "core" profile module -- Content Profile -- that handles all the various "plumbing" involved. I actually wouldn't have this module expose a UI at all, beyond perhaps a simple settings page to map the node types, since there is so much discussion here about peoples' personal UI preferences.

2. A port of Bio module to D6 that removes its own plumbing in favour of calls to Content Profile's APIs, and sticks a nice UI on top of it to match what was available in Bio D5.

That's it. No further dependencies.

However, I leave it to the people who are doing the actual work here (bonobo's crew and fago) as to whether or not this approach is actually feasible. It may be that the simplest and best solution is indeed to keep the two modules divergent once again in D6, based on the fact that in D5 they have fulfilled two very different use cases.

fago’s picture

thanks for summarizing webchick.

@Bio keeps it simple, by enforcing a simple 1:1 relationship. You can build a 1:1 relationship on top of something that allows 1:M but you can't go the other way.

content profile does also a 1:1 relationship, but it can do multiple 1:1 relationships if you do different, multiple profiles. But there is no 1:M.

I'd be happy with both solutions 1 and 2, however this already introduces one dependency: the base module itself. Which seems to be a problem for people?

So I'd see 3) :
A base "core" profile module -- Content Profile -- that handles all the various "plumbing" involved. It comes with some basic UI and settings so it's usable for simple solutions. The difficulties here are that we have to agree on
* how the UI should look like
* what should be handled by the base module and how it's done best

This is how I'd see content profile like it is now - with a quite limited "default features set".

@fago: would you be prepared to give bonobo commit access to content_profile so he could port some of the bio features over to there?
Of course! This would be solution 3). As said above, if it should be the base module I should not be the only maintainer.

Michelle’s picture

@fago re: "2: I agree with bonobo that for the base it should suffice to use user registration integration. I think it would even create a node if there are no required fields."

That's fine. That's how it is with bio now. I don't want it with required fields because I don't want any required fields on the profile.

I like the idea of having a base module without a UI, actually. It opens up possibilities of using it as an API from Advanced Profile rather than telling users to go configure this and that thru the UI.

Michelle

bcn’s picture

Trying to distill this down a bit... It seems we are close, but mainly need to agree on the minimum functionality that should go into the base module, and how the UI be exposed.

Base Module Questions

  1. UI
    1. Is there a need for a UI, or should this be handled by a secondary module?
    • If yes, what are the minimum settings needed in the UI?
    • If no, would other agree still to use a module that already introduces a dependency tree? How many modules is too much (two, three)?
  2. Assuming there is a UI, should the settings be located at:
    • admin/user/xyz (ala bio),
    • admin/content/types/[profile node]/xyz (ala the current content_profile)
    • Some combination (eg multiple locations) of the above
    • Would others still use/contribute to the module if their preference from above were not met?
  • Settings
    1. Marking/mapping a node type (or types) as a profile node type
      • Other modules (eg organic groups, fivestar, notifications) have moved to a putting the setting directly into the node type settings page (ie /admin/content/types/[machine-name]), and while that does require a i) different permission set and ii) multiple locations to make settings (both of which are objectionable to some), it seems to me to be more flexible in the cases where there are many node types.
      • Alternatively, you could put the node type mapping on the admin/user/[xyz] page, and use local task menu items for each node type that is set mapped, so you can make adjustment on a per field basis (this is similar to how panels2 handles node overrides for multiple node types)
    2. Allowing fields from the profile node(s) to be pushed to the user registration form. Currently bio does this on an all or none basis (ie either all the fields from a node go to the user registration screen, or not.). Is that acceptable, or could/should this be a per field settings? UPDATED: I didn't see that with bio you can currently choose (one a per field basis) which fields to push to the user registration screen, thus the question should now be where the settings for this functionality should be exposed.
      • Would a setting like this (i.e. something that might be per field) not appear within the field setting (ie /admin/content/types/[machine-name]/fields/[field-name], as opposed to having to list all the candidate node types AND their fields at admin/user/[xyz]?
      • Is it even possible to hook_form_alter the field settings page, and if not where should the per field settings go?
    3. Taking over the user/uid page
    • If overriding the user/[uid] page in the fashion that bio currently provides, i) how do you account for situations with multiple profile node types, and ii) how do you account for (and not destroy) the content that other modules attempt to push to the user/uid page?
    • Is it possible to offer a setting that allows for behavior that EITHER mimics how bio does things now, OR model on how node profiles used to do this. This way, we offer the simple method from bio, along with the possibility for more advanced/complex situations where you don't want to override everything from the user/[uid] page.
  • API
    1. Is there a need for an API (ala views, panels, cck) for other modules (eg Adv. Profile) to determine/provide profile nodes/fields and their settings?
    • If yes, what are the minimum settings this API should include?
    • If yes, would this eliminate or preclude the need for a UI?
    • If no, will others still agree to use/support this module?
  • If we can agree on the locations/look for the UI page(s), it seems that the most efficient solution would be to build the missing (but identified as desired/required) features from bio into the content_profile module. This might mean that the content_profile module has to expand a bit, but it's clear that fago is not only open to this, but is asking for help/patches.

    NB: I was hoping not to have such a long list/post, but trying to capture all the nuances here is a challenge. Hopefully this actually helps the discussion in some material manner.

    NikLP’s picture

    Ok, I did *say* Profile API a while back, but no-one seemed to notice... perhaps for D7? :)

    Also, are there more use cases here than are being recognised currently? I definitely see a possibility for opening up a 1:M relationship as well, unless someone can talk me out of it...

    So I see these cases:

    1:0 - A user, no profile node required (or core profile only)
    1:1 - One profile node, per user
    M:1 - One user/role can have many profiles (one user has multiple profile nodes based on multiple roles)

    The latter case would be useful for me, certainly. Use case? Well, let's say users can just be "normal". They want a profile node. Some of these users are also Article Authors - this allows them another profile node for that (accessed from a different tab on their profile, I assume). Yet further users don't use the site in that way - they are suppliers of goods/services pertinent to the site, and they have a totally different profile, which requires a totally different node type.

    That's three roles, three profile types, with multiple profiles per user based on role memberships. I need this now, so the use case is both present and relevant...

    bcn’s picture

    @fago #41:

    content profile does also a 1:1 relationship, but it can do multiple 1:1 relationships if you do different, multiple profiles. But there is no 1:M.

    Just to be clear, you are saying that content profile currently can handle both 1:1 (one user to one profile node type) AND multiple 1:1 (one user to multiple profile node types)?

    When you say, "there is no 1:M", do you mean content profile cannot handle one user to multiple profile nodes of the SAME type? If yes, I don't see this as a problem, because I can't think of a use case where a single user needs multiple profiles of the SAME type.

    @NikiLP #44
    If I have understood the above questions correctly, content profile should already account for the 3rd use case described in #44.

    fago’s picture

    When you say, "there is no 1:M", do you mean content profile cannot handle one user to multiple profile nodes of the SAME type? If yes, I don't see this as a problem, because I can't think of a use case where a single user needs multiple profiles of the SAME type.

    Exactly. It allows only one node per content profile type.
    The relation is: 1 User x 1 Content type => 0|1 profile node

    It might make sense to support translated profile nodes by the API, so then we would have 1:M.. ;) But better keep things simple.

    Thanks for this great write up noahb. As of now content profile has already a basic API, also for adding settings per content profile, it has UI per content type (admin/content/types/[profile node]/xyz) as well as a setting to mark a content type as profile directly in the content type settings page.

    So what are the opinions? (looking @noahb's questions)

    bcn’s picture

    To me it seems that much of the trouble here come from weighing the benefits and costs of the adding the functionality to allow multiple node types. Once you make the decision to allow multiple types, the single admin page (ie admin/user/bio) would become really muddled, but with a single type it remains reasonably simple.

    Thus key questions to pose to the principals involved here are:
    @bonobo: How critical is it that the the single admin page remains the one and only place to i)map node types ii)choose display/override settings and iii)choose registration fields. Secondly, do you have any suggestions how to incorporate multiple node types into the current bio admin page?

    @fago: Would you consider moving (or possibly mirroring?) some of the settings that currently appear within the content type admin pages, to a single admin/user/content_profile administration page? For example, instead of having a 'content profile' local task/tab under each content type, it could fall (still as a local task/tab) under the (hypothetical) admin/user/content_profile page...

    @all: Would it be acceptable to make the functionality/settings for choosing which fields get pushed to the user registration process into a separate module?

    NikLP’s picture

    It is of little consequence that one admin page would "get muddled" for multiple profile types, as one page simply will not suffice.

    Due to the fact that selection of CCK fields for each profile type will a) require lots of screen space and b) really belong in the content type settings, the admin/user/whatever screen should stay clutter free.

    In the content type settings, because we have created a need to select fields here, this is where we should put the content type settings also. Two ways to do this: a) mimic fivestar (which I don't really like because it clutters the basic content type) or b) create a new tab for the field selection (if this is possible).

    Bear in mind that other things associated with profiles as nodes will be appearing on the content type pages too, such as auto node titling admin.

    webchick’s picture

    I personally really dislike having to go to 30 different screens when I enable a module in order to configure it. There's almost always admin/settings/blah and admin/user/permissions, at a minimum. Now we're throwing in admin/content/types/type-name/blah times however many node types you want to associate with a user. Meh.

    I don't mind mirroring things there if that's what users expect, but I personally prefer just to go to admin/settings/blah, check all the right boxes, give out some permissions, and done.

    NikLP’s picture

    Well, the key here is to strike a happy medium I think, dependent upon the use case.

    For me, I could never find the Bio settings because although they were "settings", they were tied up in the user admin area, which I personally found a *little* confusing. So perhaps we should keep any relevant settings in "settings"?

    As for the multiple places for other settings (I'm chiefly referring to the "however many node types" bit), perhaps if we have a per-type setting on the settings page which reins in some of the excess chatter?

    Maybe on the settings page, we have a fieldset of "applicable node types". In here, we could have a checkbox & radio for each type, the checkbox will confirm the presence of that type as a profile type, and the radio can have two entries: "show all fields" and "pick fields in node type admin".

    Although thinking about it, does that even make sense? We still have to tie each relevant type to the registration process as well, which makes for more checkboxen, so...?

    Deep breath, everyone :)

    bonobo’s picture

    I'm starting to feel like we're building a camel here.

    For the first pass, we will start simple -- As I have said many times before, *client feedback* has singled that admin page out as a valuable feature. For me, the input of a non-technical person who is *using* the system is incredibly valuable. The folks on this thread can figure out how to deal with anything, as we are all reasonably technical. To discard end user feedback, however, seems like the wrong way to go.

    As has been noted in many places, 1:M has varying degrees of complexity that will vary widely based on use case. Anticipating and addressing all of these use cases does not fit in a base module. This is specialized functionality, not generalized functionality. This is a great use case for a helper module.

    Note: this is not the same as supporting multiple node types as profile nodes, as content profile currently does. Ideally, this functionality will be retained in the base module -- it is also worth noting that there are multiple paths that bring this support, and I don't see a need to tether ourselves to one specific method of achieving this.

    This thread is veering dangerously close (or has already plummeted over) the Cliff of Scope Creep -- and down that road lies peril. One of the things that has become abundantly clear over the course of this discussion: no matter what we do, there will be someone out there who wants it done differently.

    Webchick's comment in #40 sums up our approach -- @fago's question in #41: "however this already introduces one dependency: the base module itself. Which seems to be a problem for people?"

    Having the base module as a dependency poses no problems from our perspective. This structure is used in many other modules: Views, emfield, cck, etc. And most people creating profiles will also be installing auto_nodetitle (@fago, sweet module, btw) and possibly token. Going beyond that, however, feels like we are getting into dependency stew.

    So: A clean architecture for the base module. A clearly defined functional scope for the base module. A UI that retains what works in D5, and wherever possible simplifies the process of actually using the code.

    Separating the UI from the base module allows anyone to modify it later. If anybody has great ideas on the UI for this, I'd love to see some screenshots/mockups. We will be using the functionality exposed via the UI of bio as a base, as it has gotten positive feedback from an oft-ignored segment of the Drupal community: the non-technical end user.

    fago’s picture

    @UI discussion:
    hm, but it's quite common to have per content type settings in the subtabs - think of CCK.

    I think it's logical to have per content-type settings in this per content type UI. Of course we could make one page and add in the settigns of all content types - but I think that this would be too much for one page? Perhaps it would be ok when one uses fieldsets.

    I personally prefer to keep all settings of a content type together @admin/content/types/type-name/ and its subtabs.
    But perhaps we could make another page which allows defining content types as profiles and links to the further setting pages.

    Anyway, as always: If the general opinion is to have one page with the setting of all content types, then let's implement it that way in our base module - if there is one,

    @bonobo: Having the base module as a dependency poses no problems from our perspective.
    Great. Then let's make a common API module? I'd be (really!) happy with that.

    For me this questions are open:
    * Should content profile be the module and we strip out its UI, or should we make a new one (Profile API?)?
    * Who does it? I offer help for developing and maintaining it, but at least I'd be appreciate others to step in - so it's not my API but the API of the community. Perhaps we do it together, bonobo?

    bonobo’s picture

    We (FunnyMonkey) are having a development meeting tomorrow (aka, we're going for a bike ride, eating lunch, and talking about work). One of the things we'll discuss is the cleanest way forward, which will involve evaluating the current landscape, the functionality we need, the functionality our clients have identified as valuable, and the various viewpoints expressed in this thread.

    On the basis of that eval, we'll get down to work. As I've said before in this thread, our goal is to reduce (or eliminate) duplication, and come up with a clean, well-architected, easy to use, and easy to maintain solution. We're going to make sure we take time to evaluate this fully, and then we'll know more about the exact road we're going to take. We're at a point where ruling options out is premature -- we need a more thorough evaluation.

    As of this point, I've spent about 60-90 mins writing comments on this thread *today* -- and it's 10:00 AM where I'm at. I hope that people in this thread will look at the amount of time and detail I've spent laying out our thoughts on how to proceed as an indication that we are looking to do this in the way that best benefits the community. At a certain point, though, the conversation needs to draw to a close so that coding can begin, and from our perspective we're at (or very close to) that place.

    bonobo’s picture

    @fago, re: "Great. Then let's make a common API module? I'd be (really!) happy with that."

    Us too! That's the first thing we'll be looking at -- we'll be at a better place to talk about implementation specifics after our meeting tomorrow -- but we'd *love* to work together on this, and have it be a community effort -- the more people who have a hand in this, the better.

    webchick’s picture

    OMG. I can't believe the kind of horrors FunnyMonkey puts its developers through...

    You make them go outside AND get exercise?!? You MONSTER. ;)

    Thanks so much for taking this on, Bill and Wolfgang. :) Looking forward to see what you come up with!

    Michelle’s picture

    Common API module sounds wonderful to me as well. Our plans for the advprofile + mysite "thing" are still in the works so it's hard to say exactly what form it will take but storing profile data in nodes will figure into that. It may be that we end up doing an integrated UI to deal with the nodes so having the content profile UI in a separate module that be disabled would work perfectly for that.

    Sorry I'm no help with the actual coding at this time but we will be making use of this once panels is ported to D6 so I am very interested in the outcome.

    Michelle

    fago’s picture

    Great! :)

    Then let's wait for the outcome of your discussion.

    Allie Micka’s picture

    FWIW, When I ported Bio to 5.x, I was interested / open to having multiple content types. On the settings page, I figured you'd make the "Content type for user biographies" item into a multi-select or checkboxes. However, there was no storage for bio-to-user references at so I thought, while handy, it wasn't worth the complexity. Since that time the bio table appeared on the scene, which would make this easier.

    Beyond the settings page and the user profile tabs, Bio has very little in the way of UI, because everything else that needs doing happens in NodeLand. I could see helper modules that provide default views, permissions, or theme tweaks; but I haven't seen any documented necessity to extend node profiles in radical new ways that would necessitate an API.

    A straight port, with multiple profiles, would go a long way towards a base module in its own right. Given that I don't have any near-term time for this either, I'll gratefully accept the work that FunnyMonkey has to offer.

    Thanks everyone!

    bonobo’s picture

    Hello, all,

    @webchick, re "I can't believe the kind of horrors FunnyMonkey puts its developers through..." -- yeah. We're a pretty cutthroat kind of bunch :)

    @Michelle, re "Sorry I'm no help with the actual coding at this time but we will be making use of this once panels is ported to D6 so I am very interested in the outcome." -- no worries at all. The panels extension has a lot of potential, and making something that's lightweight enough to be reused in different contexts is something we'd like to hit as well.

    @fago, re "Great! :)" -- I'm right there with you. Looking forward to moving this along.

    @AllieMicka -- the functionality you describe is pretty close (identical?) to what we're looking for.

    OMG. Is there actually agreement on this thread? I don't know about the rest of you, but I ain't sayin' another word :)

    NikLP’s picture

    Well I have one more comment, insofar as I don't understand why we'd want to leave out support for multiple profile nodes per user (ie one per role, potentially)? Bonobo commented that this seems to be taking the base module(tm) too far, but to me it just seems like circumcision: so you've cut a chunk off, but WHY??

    Edit: also - timescale? I need this today :) I can pay a little money :p

    fago’s picture

    As far as I've understood he meant 1:M - having profiles consisting of several nodes. But the API should support multiple content types as profiles, where each has a 1:1 relation to the user.

    @bonobo: So was there some important outcome of the discussion?

    Then should we use "content profile" for the API or do you prefer another name?
    Then bio, node profile and maybe others can implement their solutions on top of it :)

    Should I just go ahead and strip content profile down, so that there is no UI anymore? Or do you prefer to start yourself?

    bonobo’s picture

    WRT the discussion we had yesterday, we actually solved world peace, and made some inroads in addressing cancer.

    We did not, however, make equally successful inroads on figuring out how to proceed with the questions raised in this thread.

    Just kidding :)

    We all agreed that a base module with no UI was the way to go. Marc or Jeff can give you better feedback about the next steps than I can -- I'll ping then and have one of them chime in here.

    @NikLP -- wrt timeframe -- we're looking to start this early next week. However, our primary motivator on this one is not money -- we're doing this because we know we will need it eventually, not because we have an immediate client need. While we would never turn down money (weze all gotz to keep a roof over our head) our s.o.p. with development is to take the time we need to do it right.

    NikLP’s picture

    I'm just trying to motivate... If I'm going to do this project in D6, I *have* to have this functionality, and basically this is the first thing I need to do. So now, I need it yesterday... :) This obviously puts me in a bit of a spot, and I SO don't want to do this in D5.

    webchick’s picture

    I think something that would be far more motivating is saying things like "I'm willing to take the lead on testing this functionality in D6 as you get things completed" rather than reiterating over and over that you need it yesterday. ;)

    NikLP’s picture

    Well, that was taken as read...! ;)

    "Yeah, what she said" ^ :)

    fago’s picture

    awesome!
    I'm looking forward on further input from Marc or Jeff.

    bsherwood’s picture

    +1 on figuring all this out.

    I definitely agree with fago that we need some sort of basic profile API.

    I don't see how we can't have a basic API to handle CRUD functions and other simple tasks then wrap the UI around it and finally build extendability into it with other modules.

    The idea of creating two separate but similar modules is baffling and it seems to go against drupal philosophy.

    How about:

    1. Profile API
    2. Profile UI
    3. Registration Intergration module
    4. Basic 1:1 relationship module
    5. Advanced 1:M relationship module

    .... A new slew of profile modules built on an API just like CCK/Views/OG/Panels/etc... have a slew of helper modules.

    These types of debates drive drupal admins bonkers, I still am not sure what profile solution to use when moving to 6.x (hopefully soon).

    I personally would like to see one developer (bio or content profile) just build a API like system and hijack the other modules users. Yes I know it sounds cruel and mean, but at least we wouldn't be debating it. Sometimes it's just better to do it and let the users follow. Kind of a "if you build it, they will come" philosophy.

    bonobo’s picture

    Boris Mann’s picture

    Here's my 2 cents as to a path forward, and not to re-hash a bunch of the stuff that's already been said.
    * port Bio to D6 on a 6--1.x branch -- content_profile is brand new, lets make it so that people don't have to "switch horses" to a different module
    * add feature requests to the issue queue making it more API-fied
    * sounds like multiple profiles types / role profiles is feature request #1 -- figure out API and integration for those that want this feature (one profile type would work "today" out of the box for Bio D6 -- those that want to "scratch that itch" only have to work on that one part, potentially in a 6--2.x release ...)
    * tests!
    * anything else that smells like extra features / more features should go into contrib modules (e.g. og_bio, openid_bio, etc.)
    * as you API-fy Bio D6, look at what it would take to take over / replace profile.module for D7

    Boris Mann’s picture

    P.S. Embrace and collapse rolespecific_node as a role_bio contrib module....

    bsherwood’s picture

    So were do we stand in all of this? Is Bio going to be the module of choice?

    From reading Fago's Content_Profile page it seems like he isn't going to be developing it anymore. So should we all hope to use Bio in the future?

    bonobo’s picture

    We're in progress on this.

    We'll post details to the thread as they arise.

    sprugman’s picture

    subscribing

    mariusooms’s picture

    What he said ^ ... that's all ...

    mikeryan’s picture

    subscribing

    bonobo’s picture

    Progressing on this -- should have something to share out, hopefully by week's end.

    fago’s picture

    cool - I'm looking forward to it!

    moshe weitzman’s picture

    I didn't see much mention of Views integration here. The Views2 integration such be much much simpler than the brilliant hack that is in D5. I think we just need to define a relationship between the user and his bio node and we are good to go. Thanks Earl.

    fago’s picture

    I think so too, a relationship should do it. So views integration is simple :)

    bonobo’s picture

    That's what we're thinking as well --

    Our inclination is to keep things as simple as possible, esp for the first pass. Then, if any more sophisticated integrations are needed, they can be addressed on a case by case basis.

    jgraham’s picture

    Hi All,

    I have just committed to content_profile some code that can be enabled separately which exposes fields at user registration time; http://drupal.org/cvs?commit=128980.

    I have discussed future development with fago, and we have identified several goals to develop and work towards. Of those views2 integration is near, if not, the top of the list.

    After reviewing the various concerns and goals in this thread and fago's work on content_profile it seemed that moving forward with content_profile as a basis for further development made the most sense. Thanks for all of the input everyone and thanks to fago for being amicable to our suggestions on this matter.

    I have tried to alleviate the "dependency soup" concerns by getting the user registration code submitted as part of the content_profile project so that users do not have to track down all sorts of different modules for basic functionality while still keeping a small memory footprint for those users who do not need the user registration functionality.

    Thanks everyone! :-)

    bonobo’s picture

    FYI -- jgraham is The Man!

    In case there was any confusion about that :)

    Future discussion should probably occur on the content_profile issue queue.

    Also, fago -- could you edit the project page for content profile to reflect the new status?

    Cheers,

    Bill

    bonobo’s picture

    Status: Needs work » Closed (fixed)

    And closing this out.

    fago’s picture

    awesome!

    It's just great that we were able to agree on a common base - I'm sure this will ease 6.x development a lot.
    @bonobo: I've just done an update - of course you are invited to update it too.

    bonobo’s picture

    @fago, re a common base -- agreed. I think we have a good way forward, and I'm looking forward to building on this strong foundation. I saw that you added the views integration piece -- Nice!

    RE: "I've just done an update - of course you are invited to update it too." -- thanks -- I didn't want to go in and edit without getting the green light from you first.

    I'm pretty happy about this -- thanks for your time and work, both on the original content_profile code and in the discussions re process/best way forward.

    sprugman’s picture

    is this going to be released as a tarball any time soon? thanks!

    Michelle’s picture

    sprugman’s picture

    Oh, I was asking about the part that adds the nodes to the reg form. But I guess I should get the dev version, not the beta. (Duh.)

    Thanks.

    jgraham’s picture

    fago and I are in the process of merging in things and resolving a few outstanding issues. Once we have things settled a bit we should push out another release.

    Keep in mind the dev version is in a state of flux at the moment.

    dww’s picture

    Status: Closed (fixed) » Active

    I was just pointed to this thread by Michelle in IRC (thanks). Sounds like a perfect outcome to a long (and ultimately fruitful) discussion, which is lovely. However...

    A) There's no mention of any of this on the bio project node. ;)
    B) We should tell upgrade_status about this.
    C) We should document this on the D6 porting plans page at g.d.o.

    We need to tell users the plan for the future, and explain there's a bio => content_profile upgrade path, so users know what to do and stop submitting duplicate issues about the D6 port.

    Thanks,
    -Derek

    Frando’s picture

    Priority: Normal » Critical

    Raising priority. This should really be documented on the bio project page. Otherwise, users are stuck with "Meh, still no bio for 6", or they find this monster thread, which really is a great read, but which also might be a *bit* overwhelming for someone just looking to update his site with bio to D6 ;)

    Michelle’s picture

    I added a link to this issue to the project page. I'm not a maintainer of this module so I'm not going to take it further than that. I think it's fairly safe to say that bio won't be ported to D6, though, unless something goes horribly wrong with content_profile.

    Michelle

    fago’s picture

    Status: Fixed » Active

    I guess a link to content profile would make sense too.

    bonobo’s picture

    Status: Active » Fixed

    I think we can just leave it at bio won't be ported to D6.

    And what fago said :)

    Setting to fixed.

    bonobo’s picture

    Status: Active » Fixed

    I added a link to Content Profile from the Bio project page -- if any of the Bio maintainers feel that this is overstepping, please feel free to roll back my edit.

    Michelle’s picture

    Status: Fixed » Active

    Not fixed. There's still B & C of dww's concerns in #90 to take care of.

    Michelle

    bonobo’s picture

    Priority: Critical » Normal
    Status: Active » Fixed

    Setting to fixed.

    C is done (thanks, Frando!) and I just opened a separate ticket for B, as it won't get the needed visibility in this thread: #315016: Let upgrade_status know about the Bio --> Content Profile migration

    dww’s picture

    Thanks folks.

    Note: it's upGRADE status I was talking about, not upDATE_status. upgrade status is sort of like update_status, except that instead of telling you if newer releases are available for your current version of core, it tells you if there are *any* releases available for the *next* version of core. I just replied to #315016: Let upgrade_status know about the Bio --> Content Profile migration to this effect, but I wanted to clarify in here in case anyone's still reading. Cheers. ;)

    NikLP’s picture

    Yeah, *still* reading... Sheesh! ;)

    Anonymous’s picture

    Status: Fixed » Closed (fixed)

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

    jerdavis’s picture

    FileSize
    0 bytes

    Despite the discussion here, I had a need for bio in d6.

    Attached is a patch which upgrades bio to d6, this is based off the latest 5.x branch code contributed by dww.

    jerdavis’s picture

    Status: Closed (fixed) » Needs review
    FileSize
    18.28 KB

    Let's try that again...

    Michelle’s picture

    @jerdavis - I haven't had a chance to try content profile, yet, and I'm concerned that you found it lacking. Could you tell us what the problem was?

    Michelle

    bonobo’s picture

    /me pounds head into wall.

    Seriously.

    I prefer the patch in #101.

    dww’s picture

    Status: Needs review » Closed (won't fix)

    No offense to jerdavis, but WTF did you do that for? :( I thought it was crystal clear from all the interested parties that we are abandoning this module for D6, after much work attempting to merge duplicated/forked modules trying to do the same thing into one solution we'll all support going forward. This patch is a step backwards. Keeping forks alive that are on their way to rest is not a productive way to contribute...

    NikLP’s picture

    BIO IS DEAD. THE "LONG LIVE BIO" VERSION LIVES HERE NOW > http://drupal.org/project/content_profile

    Michelle’s picture

    I would at least like to hear the reason(s) for it. I'm not supporting porting bio as it makes my life with APK much easier to only have one profile as nodes solution. But if he had enough problems with content profile to go thru the work of porting bio, I'd like to know why and see if they can be addressed within content profile.

    Michelle

    bonobo’s picture

    A search through the C-P issue queue looking for *any* issues where jerdavis has been involved turns up nothing.

    Seriously, if you have issues/needs with content_profile, post them in the issue queue, and contribute patches. We would *welcome* additional contributors who can code.

    Did you read this thread? Do you realize that any one of countless people in this thread could have forked development efforts at any point? Do you realize we chose not to in order to simplify the situation that existed in D5?

    Come and put these efforts into making content_profile better. We'd love to have another developer there.

    jerdavis’s picture

    I'm a bit busy this morning with meetings and some project work, but I'll post a response later explaining why I took this action.

    I knew it probably wasn't going to be popular, but I took the time to do the work (it only took a couple hours to complete the upgrade) and so I felt it should be shared in case anyone else needed it over content profile.

    Rosamunda’s picture

    I´m subscribing to this because I´ve tried (as a simple user, not as a developer) both bio and content profile.
    I´m actually using bio with APK in a 5.x site.

    Now I read the Bio module is deprecated in favor of content profile, and after using it, I just ask why?? Yes, you couldn´t create more then one profile with bio, ok. But that feature could be added right? Bio was small and cute. As a simple user, please I wour like someone to explain to me why this deprecation happened.

    Or was just for avoiding the bio vs. nodeprofile situation in D5?

    Michelle’s picture

    "Or was just for avoiding the bio vs. nodeprofile situation in D5?"

    Exactly. We don't need two modules that do the same thing. Content profile works fine in D6 and it doesn't have the dependencies that nodeprofile did in D5. I don't think it's as simple as bio was as far as the code goes but the UI isn't bad at all.

    Michelle

    Rosamunda’s picture

    Thanks for your answer, Michelle :)

    rhimes’s picture

    @jerdavis - thanks for the patch, I too had a Bio need for D6

    Having one prob - wondering if you've run into the same - Required text field/select list widget won't show list @ register/user but does @ user/x/bio - any clues?

    edit:
    4/11/09 - again, single row text fields show up fine @ reg/user but checkboxes & radios don't show up (either) like select list - need one or the other for reg page

    Thanks again

    NikLP’s picture

    BIO IS DEAD - FOR THE LAST DAMN TIME, USE CONTENT PROFILE.

    rhimes’s picture

    Thanks, but no thanks - prefer to use modules of my choice

    NikLP’s picture

    Yeah well don't worry then. After all, I'm an idiot, I haven't done my research, I don't know what I'm talking about, this module isn't deprecated, the community doesn't agree with me, and all the functionality offered by this module isn't encompassed within content_profile. Sorry. I'm a complete moron.

    jerdavis’s picture

    FileSize
    21.36 KB

    Patch from #102 updated for latest changes to HEAD.

    jerdavis’s picture

    @rhimes can you create a new issue for that?

    Jer

    rhimes’s picture

    Status: Closed (won't fix) » Needs work
    FileSize
    21.37 KB

    @Jer - 2 things:
    1 - patch typo @ ln#625, missing "+ */" - attached corrected patch

    2 - prob. in #113 is for Patch - should have prefaced w/ "after patch applied" - problem doesn't exist for HEAD or 5.x-1.2 or 1.3, so probably not appropriate to submit new issue. To restate then... after patch applied, neither select list or radio (or checkbox, assumed) type widgets for require/registration integrated fields are presented on reg. form @ user/register. The label & help text shows, but allowed values do not.

    Otherwize, patch works great. I for one wouldn't care except I need either a text/select or a text/radio field to show on user register. I'm no coder but I've been trying to resolve this myself. I believe prob lies somewhere between function bio_form_alter and function bio_user_register_validate in patched ver of bio.module - & most likely within function bio_user_register_form. Dunno!

    so setting to needs work

    bsherwood’s picture

    Status: Needs work » Closed (won't fix)

    Hasn't the community made it abundantly clear that there will be no Bio for Drupal 6?

    Michelle, bonobo, dww, fago, NikLP etc... have all stated that Content Profile is the successor to Bio and that all users should move to that module. Content Profile has all the features of Bio, so you are not losing any functionality.

    Why do you continue to submit patches to a deprecated module? Don't you realize that your patches will not get committed?

    Your time would be better spent making Content Profile a better module.

    bonobo’s picture

    To discuss the patch in #117, please create another issue.

    bonobo’s picture

    Status: Closed (won't fix) » Closed (fixed)