Posted by fago on January 18, 2008 at 10:15am
Recently I contacted the bio maintainers - I wondered if they are interested in joining efforts with drupal 6.x.
We 'd like to get input from the community, so I post my ideas here:
I've already a nodeprofile port in preparation - the nodefamily
dependency will be dropped. The subform element stays as I like this as
a clean abstraction for integration node forms elsewhere and so allows
one to easily integration into the user registration form or the user
edit categories.
I can think of three different ways to join forces:
1. completely merge the modules
This would be ok for me, as long as we go with the subform element
module. Don't know, if this would be ok for you?
+ a more widespread, probably better maintained and stable module
+ extensions can rely on one module + API
- users can't use choose their favourite solution any more
- installation requires one additonial module to drop in (subform
element)
or
2. build upon a small "core module"
We could provide a small "profile as nodes" core module, which allows
basically to select node types, which are profiles. No further
dependencies!
Perhaps we could start with bio 1.0 for that.
Then we could build extension modules that build upon that, but use the
same base. E.g. different user registration integration, views
integration, the user edit categories integration, nodefamily and so on.
+ Modules can build upon this!
or 3.
keep separate modules, but invent a common way, how node types are
marked as profile, e.g. a common variable. So profile as nodes
extensions can build on top of that and work with both too.
+ More simple installation, e.g. just drop in bio or nodeprofile and it
works with all its features.
- There would be no API on which the extensions can rely. So they would
have to invent basic but useful functions again and again..
or 4.
don't join forces
Comments
+1 for core module
I like the idea of "core module" since further development won't depend on other modules. Now there is no guarentee that modules, nodeprofile requires, change their code and won't screw nodeprofile.
My thoughts
I like #2. I would like to see a small module that does nothing more than make a 1-1 relationship between a user and a node from a given node type. If it's simple enough, it could possibly get into core in 7. This module would be responsible for (optionally) creating/deleting the node when users are created/deleted. Similar to usernode, but it shouldn't care about the node type being used. Whatever node type is set in settings at the time the user is created is used and then it stores the relation in a table that holds just a UID and an NID.
This could be built upon by submodules that take care of:
1) Choosing fields from the designated node type to show on the reg screen (bio does this)
2) Setting up a node relation to allow multi node profiles. The original node would be the master/first node and others would be related to that. Possibly existing node relation contribs could be used for this.
3) Taking over the user view tab (bio does this)
4) Adding a tab for editing the profile to the user page (bio does this)
I don't think the module needs to get any fancier than this. If people want really fancy user profiles, they can either use my module of build it out of panels themselves. The real key for this module is simply managing the user to node relationship.
Michelle
See my Drupal articles and tutorials or come check out the Coulee Region
Not in core...
Dries has made it clear that users are not nodes, and neither are comments.
The thing I'm curious about is if post-Views 2 we'll even need this "hack" of making a user a node.
Not users; profiles
It's a fine line, but this isn't quite making users into nodes. It's making profiles into nodes. So rather than the core profile module there would be this module that allows you to associate a node with a user to store extra data that you don't want in the user table such as favorite color or the size of their shoes. The users themselves would be stored like always and this module would be optional as profile is now. Even chx has said "maybe" to profiles as nodes, so I don't think it's impossible.
Why wouldn't it be needed post views 2? Sure you have the cool new users as views but you still need some place to store the profile data. The thing views 2 gets you is views of users when you don't use any sort of profile module and just want a list of users.
Michelle
See my Drupal articles and tutorials or come check out the Coulee Region
agreed
I agree with you that profiles as nodes is NOT users as nodes.
A user profile stands on its own, it is not a user. A user need not have a profile, but may have even multiple different profiles.
Oops! You guys are right, of course...
Sorry about that. :)
Views Profiles
Views 2 provides data hooks so that you can create dependencies on your own tables. It comes with Nodes, User, Taxonomy, and Comments out of the box, and I see no reason why Profiles couldn't be hooked in as well. Just an observation.
Aaron Winborn
Advomatic, Web Design for Progressive Advocacy, Grassroots Movements, and Really Cool Causes
Aaron Winborn
Drupal Multimedia (my book, available now!)
AaronWinborn.com
Advomatic
2. build upon a small "core module"
I don't know anywhere near what you guys know, but it seems to me that "2. build upon a small "core module" " makes the most sense.
It seems to offer the greatest simplicity for the average user since a small core module would be available for me to then choose contrib mods that work with it. And it seems that it would make things simpler for developers/maintainers to build their profile-related contrib mods since they could base their code upon the small "core module".
Would it be difficult convincing the core maintainers about #2? I'm sure there are a few hurdles for code to make it into core, and it seems that if we choose this route that Drupal 7 would be the earliest we could anticipate this functionality.
Walt Esquivel, MBA; MA; President, Wellness Corps; Captain, USMC (Veteran)
$50 Hosting Discount Helps Projects Needing Financing
Walt Esquivel, MBA; MA; President, Wellness Corps; Captain, USMC (Veteran)
$50 Hosting Discount Helps Projects Needing Financing
D7
Yeah, D7 woiuld be the earliest to even be considered in core as D6 is nearly wrapped up and way past code freeze. My thinking is that if we have a small, light, tightly focused module for profiles as nodes in contrib now and get it a good testing workout before the D7 code freeze that maybe it might have a chance. We do need to be clear, as said in the post above, that this is for making profiles into nodes, not users. Users would still be handled as they always have been and this profile node would be an optional module.
Michelle
See my Drupal articles and tutorials or come check out the Coulee Region
Option 2 is also my preference...
Option 4 would be just sad.
Option 3 is a hack.
Option 1 is out if our goal is to get profiles as nodes into core (so neither of us needs to maintain either of our modules... hooray! ;)).
So that leaves #2, which seems to be the consensus here, at least so far. It's also my personal preference.
On a philosophical note, I lean towards creating single modules that do one thing and do it well, rather than building functionality through the combination of vast collections of "component" modules which each focus on more like one piece of one thing. While I recognize that the latter approach can sometimes offer much more flexibility, and in certain applications (e.g. CCK and Views) is vastly superior to an all-in-one approach, I sympathize a lot with Drupal site administrators who just want a simple solution they can drop-in and be done with it. Just an architectural design difference of opinion.
So.
The next matter is defining the scope for this small, focused "core" module. I'll run through the feature list of Bio, since I'm not familiar with usernode/nodeprofile/etc.
There's also still a lot of clean-up that needs to happen. For example, there's a current critical bug about it not synching the deletion of users with the deletion of their profile records, but I'm getting that wrapped up shortly. There's another one I should make critical to disallow deletion of Bio nodes apart from the user being deleted, as well (optionally, I guess). The lack of coding standards compliance also drives me completely nuts whenever I look at it, so I anticipate rolling a patch for that very soon. ;)
So we need to decide:
Any takers?
These all sound pretty
These all sound pretty essential for a core profile as node module to me. I guess views and panels integration may not be meant for core (unless views is in core).
One thing that nodeprofile group does that bio doesn't seem to, is allow for multiple content types to act as a profile. So it allows different kinds of profiles (personal, business) etc, as well as different profiles completely per user role or whatnot. I don't think that should be in the core module, but I do think it should be kept in mind to not make a contributed module difficult to extend that functionality.
way 2 :)
I agree that way 2 is the way to go and it's my personal preference too :)
I think the main task of the "core" module is the selection of node types, that should be node profiles as well as verifying the 1:1 relationship between each profile and a user.
However, I think it's important that one can define multiple profile types. I don't know if bio supports that? As you said, one can make a bio profile for only employees, but then one probably needs another bio profile for other users.
Then, building on top of this, I think it should only add little integration code, that builds on top of that. What nodeprofile is providing here is a customized display on the user page, where one can choose between (none | link only | teaser | full node view). Anyway, I don't know if people really like the own (view|edit) tabs it introduces for teaser | full node view? But I think there should be at least the link option in the "core".
So I agree that functionality like point 3. should be added - however I don't like the "take over" functionality as it looks like a hack to me. I think a "profile as node" solution should more work like the core profile module: display additional data on the user page, but don't replace it.
5,6: Yes, I think we should add this to the "core" module. I'd add any further contrib module integrations as conditional included include file to it - so it doesn't hurt anyone but just is there, when one needs it.
@deletion of user: Nodeprofile comes with its own node_delete() function to do this as one can't use the original node_delete() in this case. Disallowing deletion shouldn't be a problem in d6 as there are separated edit/delete permissions now.
So next, let's discuss some more details:
* Maintainership: Who helps maintaining the "core" module? I'd like to do, but I'd love to see others helping. webchick? :)
* Naming: Call the "core" module bio or nodeprofile or something new?
* Projects: Do we create one project for the "core" module and another for each extension module?
* CodeBase: Do we base it on bio or nodeprofile? Probably we should get the best out of both modules and decide this on top of the features we want to build into it.
I tend to nodeprofile as name as "biography" is more a specific use case than a general name. On the other side I try to avoid the term "node" in the UI of my more recent modules, I use "content" instead. Perhaps we just go with a new name & project, e.g. "Content Profile"?
So what about this possible way:
1) Call the core module "Content profile basic".
2) Then there could be a module like "content profile integration", which depends on subform element and provides the old nodeprofile user registration and user edit categories integration.
3) And further possible extension modules..
?
Then I'm not sure, whether we should go with a project, containing multiple modules (the core module and some extension modules) or if we should create a separate project for each extension? Probably separate projects make things simpler if there are different maintainers, but users would have to download more modules, but hey, it's optional!
What's the preference here?
upgrade path?
OK so the big, big question for me is "what about an upgrade path"? Personally, I'm quite happy to nuke all existing core profile.module data on my site when I eventually move to bio/advprofile - and I don't think our users will mind because they'll get spiffy new profiles to fill out. However, this needs to be discussed quite early on I think.
The simplest method is of course to move core's profile module into contrib (if anyone will maintain it), and the newly combined bio/nodeprofile into core. Since we're talking about optional core modules this seems pretty sane to me, and would mirror what happened in D6 with Open ID and the drupal/site_network module.
It would then be up to either education by site admins, or a contrib module with probably a very gnarly import script to deal with migrating users from profile.module to the new solution.
One other issue is that currently profile.module inserts fields into the user object so they can be accessed at the theme layer:
user->profile_foo, I'm not familiar enough with bio/node-profile to know if this has been dealt with, but it'll be an issue for upgrading a fair number of custom themes so I figured I'd bring it up.Upgrade
I was just talking to someone on IRC about this... I have a goofy memory where I remember conversations but not who I had them with... It might have been Brenda, but I can't swear to it. Anyway, whoever it was was talking about making a contrib module for making nodes out of profile fields. I think that would be really handy.
Not sure what to do about themes dependent on the profile fields. I'm having trouble thinking of a use case for this... Where, outside of the profile node, would you put a profile field into your theme?
Michelle
See my Drupal articles and tutorials or come check out the Coulee Region
Yeah, that would be me. The
Yeah, that would be me. The working name is "profile_to_cck" and it's for 5.x, but I don't see why it couldn't also work for future versions and if the core profile stuff is switched about. Anyway, I'm hoping to get an initial release out this week, it's proved some challenges I wasn't expecting. I think that sounds like the most sane option, at the moment.
Well we wouldn't do it the
Well we wouldn't do it the same way now, but since 4.7 we've had profile fields for 'location' and 'custom title' (and no sigs) used in our forum comments - mimicking a php add-on from before we switched. afaik people also use it for 'full name' to be displayed on nodes instead of authoring info and other stuff like that.
There's other ways to do this sort of things now, but there wasn't so much in 4.7 and previously, which is the era profile.module hails from after all. I believe it was also one of profile.module's 'killer features' - in that there's no extra/custom querying on the database to access those fields.
Now, if the current core profile module goes to contrib, that's all well and good for people who really, really need this, but I don't know if this functionality is something that others might require to support an alternative going into core - hence why I brought it up. Personally I don't care.
Features
I hope you don't mind... I changed your UL to an OL so I could use the numbers. :)
1 - Essential
2 - If the idea is to eliminate nodeprofile in favor of this new module, we need to also have a way to have multiple nodes assigned to a user profile. But this could be in a sub module.
3 - This is handled by panels quite nicely so it could be removed from bio and still easily be handled.
4 - Important.
5 - Essential. Even though we get "user views" in views 2, we'll still want to be able to do views of profiles.
6 - Essential. Even if people aren't using advprofile, being able to load up the user's node in a panel based on their UID is important.
I think Bio is very close the ideal in contrib. I don't know if it's core worthy. This is coming from a long time nodeprofile user and I mean no offense to fago, but bio is nice and simple, which is important. I've heard so many complaints from people about using nodeprofile in my tutorial because of how complex it is. I chose it because bio lacked features at the time but bio has come along nicely. I still think nodeprofile has a place for people who want multi node profiles as that is its strength. If we could have bio with a submodule addon for multi node profiles, I think that would be a killer module and the best merging of the two.
Michelle
See my Drupal articles and tutorials or come check out the Coulee Region
Regarding #1
I was wondering if it makes sense for this module to just provide the "profile" type and leave it at that. Like how Blog module provides a Blog type. And the ability to use a different (or multiple) node types as a "profile" type would come out of the contributed "node profile plus plus" module?
With CCK in D5+, fields can be added to any node type. So the requirement to choose the node type seems a bit less urgent.
Or am I talking out my my behind again? ;)
Type
Well, it may just be me being weird, but I hate using module provided types. I make my own and delete the one that comes with the module. Plus, for advanced profile, if you want it to create the node type for you, you need to be able to associate any type. It wouldn't be a fatal thing but anyone using advprofile would have to use the "node profile plus plus" module, even if they only want 1 node per person.
Michelle
See my Drupal articles and tutorials or come check out the Coulee Region
I lean towards it not even
I lean towards it not even creating a default profile type to begin with, but that might not be good usability wise. I do think that having more than one profile type or whatnot should be left in contrib.
Out of behind, it sounds like...
Thanks. :D
I think providing a default
I think providing a default profile content type makes sense, as it's easier to start for beginners. But as I already said I'd allow multiple content types as profile. We could go with a simple checkbox "Use this content type as a content profile" which is per default activated for the default profile content type.
So people easily find "their" new profile when activating the module, but everyone can go and create another or multiple content profiles.
simple!
I agree that the "core" module should be simple!
For more, people can go with one of the extension modules.
But I think the core module should allow multiple profiles per default. I think this won't make the module more complicated, but is imo really important as this a main advantage of node profiles: You can create different profiles for different roles!
Hmmm...
I totally want to allow for that as an option in a contrib, but imo the "core" module needs to be as simple as possible (and emulate Drupal core as much as possible), to make it an easy "drop-in" solution should we push for it for core inclusion in Drupal 7, and that means supporting only the 1:1 ratio "out of the box."
We should spend some time discussing how nodeprofile's doing this and make sure that we have a hook or whatever is needed to allow for this kind of expansion.
I agree
I've been wading through the nodeprofile / nodefamily code trying to do the panels integration and it's all very complicated. It's a great module but much to complex to have a chance of getting into core. I think starting with a simple 1 to 1 base module and adding extras in contrib is a better way to go.
Michelle
See my Drupal articles and tutorials or come check out the Coulee Region
is it?
nodefamily is out of scope of this discussion.
Nodeprofile comes with a lot of featues, which would be stripped down for the base module (user register integration, user edit integration, ..).
Anyway, regarding getting into core:
I don't think a module with a limited API is likely to get in. But perhaps a module with an API that doesn't restrict things but allows expansion.
hmm
With "core" module, I meant only "core" of the "profile as node" solution, not drupal core. But of course, we can try to get this into d7 too.
Anyway, I don't think it's right to just emulate the core. The core profile module is limited - that's why the profile as nodes solutions exist. The idea is to make it better.
Furthermore whether we code stuff for one content type or possible multiple content types doesn't matter much, however if you limit the code to one content type, I see no simple way to expand this with extension modules.
If one codes a tool for content types, why should one limit to only one!?
So I don't think it's a good idea to go with this limitation.
Not always...
As far as I can tell, there are two main uses for these modules:
a) I want exactly the functionality in Drupal core offered by user/profile modules, but with the profiles as nodes, because:
b) I want infinite control over my user registrations/user profiles, because:
IMO the "base" module (let's quit using "core" since that's confusing :D) should fulfill a), while still providing hooks or whatever so that modules can extend it and make b) possible.
Maybe covered in your two uses
but my biggie is:
benjamin, Agaric Design Collective
benjamin, agaric
That's covered
Whatever module that comes out of this would use one (or more pending that debate) node type for profiles just like bio/nodeprofile does now. So you would be able to use CCK with it.
Michelle
See my Drupal articles and tutorials or come check out the Coulee Region
...
Just to throw something else in the mix, you can do all of "b" with a single node in bio. I think the biggest advantage nodeprofile has is the ability to say role X uses content type A while roles Y and Z use content type B. You can't get that with one node without a whole lot of messing with field permissions.
I guess the question is, how complex (code-wise) is it to allow multiple node types to be marked as "profiles"? Forget nodefamily and all the subnodes and that complexity. Just pitting the 1 person 1 node of 1 node type against 1 person 1 node each of all marked types. How much difference does that make in code? If the answer is "not much" then I agree with fago that it makes sense to allow admins to mark as many node types as they like to be "profiles" in the base module. If it makes it much more complex, though, then let's stick with the simple for the base module and make sure it's easy to extend.
Michelle
See my Drupal articles and tutorials or come check out the Coulee Region
simple
It's no big deal :)
Furthermore thinking of the extension modules, I think we would have to code it that way anyway if we want the extension modules to be able to do that, but without replicating code that relies on the base (such as the views, panels,.. integration code).
Yeah...
It's basically:
My worry though is that this can get mighty complicated very fast.
- If profiles are automatically created on registration, is one node of each type auto-created?
- Do we mark one as a "main" profile type, and others as "sub" profile types and only create the main one?
- If CCK fields are pulled onto the registration form from multiple profile types, how is that represented in the UI? Put them into separate fieldsets? Separate tabs? Other?
I guess if we treat multiple content types like we do multiple profile categories ala profile.module, it maps pretty well.
Panels
Fussy baby so no time for a full response but I wanted to say don't worry about panels. I've got bio, nodeprofile, and core profile all working with panels so I can handle integrating whatever hybrid module we come up with here. :)
Michelle
See my Drupal articles and tutorials or come check out the Coulee Region
Hmm, so even if you
Hmm, so even if you restricted 1-1 user/profile but 1-many profile/content type - you've then got no way to switch users between different node types (with different fields) as they change roles, or to enforce content types for users with more than one role assigned. At that point, it seems sensible to either enforce strict 1-1, or have a full system for this in core which can handled multiple pages (much like the core profile module does now, well, not quite like that).
Like bio and nodeprofile,
Like bio and nodeprofile, there is no intention to enforce the existance of profile nodes. People are not forced to fill out their profiles per default - however it might make sense to build extension modules that enforce filling out profiles during registration. But this is still another case as this still doesn't try to enforce a 1-1 relationship (like e.g. the usernode module does).
sounds good.
For per profile settings nodeprofile uses a per content-type tab like CCK does.
If multiple profiles might produce complexity for extensions, like CCK fields user registration, they can still go and support only one profile node. - but that's not possible the other way round.
If it is of interest for you, this is like nodeprofile currently handles things:
agreed
I agree, with your use cases (apart from that that buddylist doesn't require profiles as nodes :)
Anyway, I still think the base should allow multiple profile content types, as imo that's necessary to be a full replacement. Now, with a content type as profile you have access control for it, so people will use that. As soon as the profile is restricted to a role, the desire comes up to have another profile for another role, which is currently missing a profile.
Furthermore I think it's easy to implement so the code stays simple. Then we can easily base the extension modules on it. (I don't really know how this should work otherwise)
I may be missing something,
edit: looks like this was cleared up in earlier comments, but just to be clear on the two different issues of 1-1 mapping:
1-1 user to node/profile relationship
1-1 node profile - content type relationship
I think it makes sense for core to only support one node per user. However, it doesn't seem like too much extra complexity to support more than one node type for use as profiles. This would mean you could set "authenticated users" to use your 'basic-profile' node-type, and 'employees' to use your 'employee profile' node type - just by content type permissions. The 1-1 relationship would require them to only choose one though, and there'd have to be some kind of solution to enforce content types per role.
Then a hook allows for one user to many profile nodes relationships in contrib (for different pages and stuff).
Good idea
That sounds like a good compromise. It allows for the node type per role without getting too complex.
Michelle
See my Drupal articles and tutorials or come check out the Coulee Region
Actually I just realised it
Actually I just realised it could add it's own unintended level of complexity since you can't determine user roles at registration time. So scratch that idea :(
Smells scope creepy to me...
You already nixed the idea below, but I don't think the base module ought to make any assumptions on how people would want to deal with multiple "profile" node types, because there are infinite ways to do so, and this is exactly why I didn't want to deal with it. ;)
If we make any assumptions, they should be along the lines of what Drupal's profile module already does, which would be making an instance of each node type a tab in the user profile.
That sounds sensible to me,
That sounds sensible to me, I'm mainly trying to think of stuff that's easy in the core module (no matter how bad the actual architecture) but currently not so easy in contrib - at the moment I can't think of any more though.
Im sorry to interupt...I know Im out of line here.
Hey guys, I am sorry for posting something off topic...I just can't seem to find the right place to post. I saw you were talking about profiles and users. I am very new to Drupal and I was wondering if someone could steer me in the right direction. The past week or so I have been cramming in tutorials and I have been learning a lot. I have been trying to figure out how to create a community-based site using drupal. I really like www.Godtube.com so I thought I might try to use a similar concept.
The site would be a site for gamers. It would consist of player profiles and groups/clan profiles. I am not wanting anything crazy, just somthing simple like the "Ministries" layout at Godtube. After registering and receiving a player profile, player profiles would go right to the "free agent" page. From there, players would have the option to create a clan profile or join an already existing clan profile. I am wanting to have each new user profile attach itself as a thumbnail pic to a page...and when they join a group, they would move to that group's page. I know this has to be possible with drupal, but I just can't figure out how to set it up. I have been racking my brain and can't figure it out so I thought I would try to post.
Is this possible? I would really appreciate someone's help and advice. In order not to stop the flow of this discussion, if it seems better, feel free to reply to me at ambassador@ddayall.com
Please start a new thread
You're in the right group, "Profiles as nodes", and I'm sure someone will help you, but it's not good practice to hijack threads (which you've done twice now).
Good luck and thanks for your cooperation.
Walt Esquivel, MBA; MA; President, Wellness Corps; Captain, USMC (Veteran)
$50 Hosting Discount Helps Projects Needing Financing
Walt Esquivel, MBA; MA; President, Wellness Corps; Captain, USMC (Veteran)
$50 Hosting Discount Helps Projects Needing Financing
I saw the other thread was
I saw the other thread was OLD so I posted here. I tried my own group but it was deleted. How can I post and get the help I need without having my post deleted or making someone upset? Please help, I am trying my hardest.
I understand you need assistance and that you're trying...
...but when you post to a thread, your subject really should be somewhat related to the original post. And if you can't find a related topic, you really should start a new thread. I know that when I read "new" comments for a particular thread, I do expect them to be related to the original post in some way, even if remotely related. :) We're probably all guilty of having hijacked a thread at some point, but I for one try really hard to avoid it because I don't want to be rude to my fellow posters.
I'm sorry if at times you don't obtain the best, most timely response, and it's happened to me as well, but you just need to try and be patient. We're all volunteers here and no one is under any commitment to answer other people's posts or requests for help, so sometimes you won't get an answer, and that's happened to me as well. I then just try to do the best with whatever info I have, or I try some alternative method. If I post something here to the appropriate group or to drupal.org and I don't receive a response within a couple of weeks or so, I have, on a few occasions, personally contacted a module's maintainer via their contact form to ask him/her for help, with a link back to my post to show good faith that I've asked for help previously.
Bottom line is that posting completely unrelated info to a thread will, more often than not, upset folks because it's seen as being somewhat rude and inconsiderate. So please let's make this post the last off-topic one and go ahead and start a new thread. OK? Thanks and good luck!
Walt Esquivel, MBA; MA; President, Wellness Corps; Captain, USMC (Veteran)
$50 Hosting Discount Helps Projects Needing Financing
Walt Esquivel, MBA; MA; President, Wellness Corps; Captain, USMC (Veteran)
$50 Hosting Discount Helps Projects Needing Financing
Where to post
Sorry to add another OT post, but wanted to add some specific help...
Starting a new thread is done with the "create story". Don't create a group for it because, yes, it will be deleted. Creating groups should only be done when you want to gather together a group of people for something that isn't covered by existing groups.
To be honest, though, your question would be better on Drupal.org's forums. You'll get a much wider audience there. This place is more for collaboration on projects and discussion and not so much for support.
Michelle
See my Drupal articles and tutorials or come check out the Coulee Region
beta 1 is out..
check out content profile beta 1... -> http://drupal.org/node/223287
Wish I could
I'm bogged down right now so all I can do is cheer you on. Go fago! :)
Michelle
See my Drupal articles and tutorials or come check out the Coulee Region
beta 1 is out..
Excellent timing for ver 6.x ... Great work!
Darly
Finally resolved!
With help from the Funny Monkey team, we have officially deprecated bio.module and focused efforts on the new content_profile.module for Drupal 6. Nice work all!.
Thanks to fago/jgraham/prior work
We're VERY glad to have a solid release on this -- the details were worked out here: http://drupal.org/node/201902
Currently, the dev version has the most recent code -- we have been testing this, and all seems to be working well --
fago did great work with the existing content_profile code, and Jeff Graham did the heavy lifting with the bio-style integrations -- fago, Jeff, and Marc (another Humorous Primate) are now working together to maintain the code.
So, come on down and test, test, test!
Cheers,
Bill
FunnyMonkey
Tools for Teachers
FunnyMonkey
Content Profile vs. Advanced Profile?
How does this compare/contrast to Advanced Profile?
Erik Britt-Webb
drupal@ebrittwebb.com
Advanced profile in Drupal 5
Advanced profile in Drupal 5 used either nodeprofile or bio, it's not, and never will be, a profile as nodes solution by itself.
What is the update path from D5 to D6 bio or nodeprofile ?
Neither bio nore nodeprofile will be ported and D6 it will be http://drupal.org/project/content_profile
What should we choose bio or nodeprofile ?
We have to finish off a website in D5 for the end of the August so we need to stick to D5 even so D6 seems so near to be production ready :)
Thanks for your advice.
From the content_profile project page
"As far the features are supported content profile supports upgrading from the 5.x bio and node profile modules."
So, the basic functionality will be supported no matter what option you choose.
Cheers,
Bill
FunnyMonkey
Tools for Teachers
FunnyMonkey
I know that, what worries me was precisly:As far the *features*
It doesn't says how it would be possible to migrate from D5 or D6 it just tell you something about features.
The database structure of As far content_profile is more like bio or like nodeprofile ?
Bio's scoop is narrower so possibly more difficult to migrate
But nodeprofile has a loot of dependancy
http://drupal.org/project/nodeprofile
http://drupal.org/project/nodefamily
http://drupal.org/project/views_fusion
patch for the CCK nodereference field, which adds support for views_fusion.
How would it be possible to migrate all that stuff ?
I would like to use the module that would require less migration's work.
Thank for your expertise :)
.
Both bio and nodeprofile use standard Drupal node types as does content profile. The modules just provide the connection between the users and their nodes. You can flip between bio and nodeprofile now using the same node types. I haven't tried going to content profile, yet, but it's likely the same.
Michelle
See my Drupal articles and tutorials or come check out the Coulee Region
migration tools from D5
Michelle, thank you for your answer.
I may have been unclear, I would like to know if there will be some process of migration from bio or nodeprofile to D6 content profile.
If not what would be easiest to migrate ?
Thank you for your time and effort.
Migrate what?
I understand the question and I already answered about migrating the actual data. What else do you want to migrate?
Michelle
See my Drupal articles and tutorials or come check out the Coulee Region
In response to Fago's
In response to Fago's comment
It seems to me that having the node take over the user page should be an option. For many sites the standard Drupal user information is just clutter. We need to have the ability to completely customize the user page.
Web design, Drupal theming, and logo design:
http://www.translationdesigns.com
Drupal theming, Module development and logo design:
http://www.PixelClever.com
I probably should've weighed
I probably should've weighed in here earlier with this, but since I only recently got the blog post up...
@vinayakaya, while I'd agree that the underlying goal of "having the node take over the user page" is valid, I think that it's a perfect example of the kind of thinking that has ultimately resulted in failure to come up with a comprehensive solution for user-centric data that can really work for everyone. Having a node take over a user page muddles the line between data storage and presentation. I've written up a <a href="http://blog.samboyer.org/content/user-panels-proposal>blog post - largely a summary of ideas that Michelle and I have been brewing for a long time now - that advocates for a new way of thinking about the data, and presents an approach (surprise surprise, using Panels) that can handle it.
In the proposed approach, what's displayed on the user/% page is something easily handled via a single, unified admin UI - and it couldn't care less if that data comes from content_profile.module, profile.module, raw user.module data, or even some external data source.
No offense, but I'm not in
No offense, but I'm not in favor of a solution that's dependent upon Panels. I wish the link to your blog worked so that I could see the details. I don't think we should be forced to use the Panels module simply to display a user profile node instead of the user page.
.
No one is forcing you to use panels. You can always take over the page the old fashioned way like bio did in D5. Panels is just much easier and cleaner.
Michelle
See my Drupal articles and tutorials or come check out the Coulee Region
None taken. Sorry about the
None taken. Sorry about the link not working, I've been trying to get that server working for benchmarks...
But now it looks like the damn link just didn't work, period. Well, here's the link again: http://blog.samboyer.org/content/user-panels-proposal
Also, I should be clear: I haven't based this thinking on Panels because I'm pimping my work, or think that DND interfaces are the "WAY OF THE FUTURE!" or anything like that. Panels is necessary for achieving this kind of thing at an architectural level, because drupal simply does not have another system that can structure and pull content in an organized, standardized, and efficient way. I was chatting with webchick about profile.module on IRC the other day, and when we started talking about possible improvements (that did not include Panels), I ran smack into the problem that drupal (natively) simply doesn't handle that kind of thing.
I agree 100%
I agree 100% with vinayakaya
Michelle's and sdboyer's approach is spot-on
If you want to use panels, use panels.
If you want to use the theming layer, use the theming layer.
If you want to make it like Bio in D5, make it like Bio in D5.
There has been a lot of discussion about this -- for an overview, see http://drupal.org/node/201902
For feature requests in D6, use content_profile's issue queue: http://drupal.org/project/issues/content_profile
Cheers,
Bill
FunnyMonkey
Tools for Teachers
FunnyMonkey