Posted by sime on March 22, 2007 at 12:46am
Hiya
I've done a little tying together of the docs I've found on nodeprofile, nodefamily and usernode.
http://drupal.org/node/129957
Personally I only use usernode, but people can leave me comments here (or in the handbook) with specific additions and changes. (ie. if you are not a maintainer you can change it but it goes into moderation so I'm happy to make the change effective immediately.)
Comments
Looks good
I'll add the actual tutorial there instead of that link once I've gotten it ready. I'm still revising it quite a bit so it's better off on my site for the moment.
Michelle
Hi Michelle.
Hi Michelle.
Yes, I assumed this and it is all good from where I stand.
I was thinking your tutorial would be a good child page of the main package page, since you are combining two of the modules together in your tutorial. Anyway you know the handbook of course, so whatever you think is best.
Makes sense
I'm actually using three modules... nodeprofile, nodefamily, usernode. So, yeah, makes sense to put it off the main page. I'm concerned, though, that I'm eventually going to be going beyond those modules with the tutorial, so I may need to break it into parts or possibly put it elsewhere and link to it. We'll see when I have it done. I've got a long way to go. :)
Michelle
Excellent
Hopefully this will be the start of demystifying the whole usernode/node profile thing. Certainly Michelle's tutorial is looking very promising – it's already answered some of my questions and it's not finished.
One thing I don't quite get though: why do we need usernode and nodeprofile? From what I can tell, if both are used together then usernode is pretty redundant as it is never displayed if all it does is inline the nodeprofile node.
On the other hand, usernode is the one that automatically creates a node for each user, so perhaps nodeprofile is the redundant one here? Since the usernode content type can be enhanced with CCK, what is the purpose of using nodeprofile as well? Doesn't that make things more complicated? Or does nodeprofile give us some benefits that are not part of usernode?
My understanding
From what I understand, usernode is important both because it's automatically created and because it can be used in views. I haven't gotten to the views part, yet, so I'm just taking that on faith.
I didn't realize you could enhance the usernode with CCK. That might be a better way to go when creating a single node profile as I currently am. Where nodeprofile has a definite advantage, though, is if you are making a multi node profile as you can associate multiple nodes with the usernode.
This is beyond what I've done so far, so feel free to jump in and correct me if I'm wrong.
Michelle
More thoughts
I've been thinking about this question more and more (dang pregnancy insomnia...sigh). Really, my tutorial is aimed at making usernode and nodeprofile function as though they were the same node. That's a lot of hoops to jump through when it would be so much simpler if they just were the same node. For people with multi node profiles, the current system makes sense but for people like me who just need one node per person, maybe my tutorial is the wrong way to go about it?
I'm going to look into what you said about enhancing usernode with CCK and see if there's any limitations doing it that way rather than creating a new CCK node. If it turns out that there are limitations, I wonder how hard it would be for the module author to simply add in an option to use a different node for usernode instead of the built in type?
Thanks for getting me thinking...
Michelle
Just a small thought. I have
Just a small thought. I have some code which adds a tab to the user profile that links them straight to their own usernode. If that sounds interesting I'll dig it up.
Hmm... Not sure that would help me
Since I have the user profile embedded inside the usernode, putting a tab there would just take you in a circle... :)
Thanks, though,
Michelle
What I have done
is utilize the core profile module and the usernode module. I set up my various profile fields to be completed upon registration. I then themed the user-profile page to show all the user account and profile info with icons that link to the user/edit page.
I then themed the usernode page to populate user profile data. The goal here is to make the usernode the external display page for a user.
Not sure if this helps but I agree with all that has been said. It's a little confusing what the difference between usernode and nodeprofile. The other issue I found when using nodeprofile is that users have to go to 2 spots to update their info. First user/edit for username & password and then nodefamily/CONTENT_TYPE to update profile fields. Ideally these should be in the same spot.
Thoughts?
I don't see a problem with
I don't see a problem with the fact, that there are two places to edit.
The one edits account settings, the other profile information - two different things.
However with the latest pageroute module there is an experimental page type 'user_edit', which lets you include the account edit page or even core profile pages into pageroute and so into nodeprofiles.
Heh, nice!
Heh, nice!
Then again...
I think I may have misunderstood you the same time around. Did you mean it adds a tab to the page you get to via the default "my account"? If so, then, yes, I'm very interested. I've been giving some thought to simplifying things for the user and that would help a lot.
BTW, why didn't you tell me who you were on IRC? LOL! All that time I was talking to you and didn't even realize until today when I went looking for you (as in sime) on IRC and ran into a you (as in emspace) saying that's you!
Ok, back to bed with me... Just had to come out and post this hoping you'll see it before I get up since our time zones are so different.
Michelle
Sorry, if I spent every
Sorry, if I spent every second telling people who I am, it would just be annoying. And I like the mystery. ;-)
Remind me when I see you in IRC and I'll find that code.
The first limitation I've
The first limitation I've found with using the built-in Usernode content type is that it doesn't show a body!
hm, obviously this is point
hm, obviously this is point that's confusing a lot of people. So please STOP further confusing people by using usernodes as nodeprofile.
The nodeprofile package provides nodeprofiles without usernodes, usernodes are optional and not intended as profile!
So yes usernodes are useful in conjunction with nodeprofile, but not necessary!
Again, here the part of the nodeprofile README about usernode. Read that and decide yourself if you need usernodes!
It allows you to * Use views to build user listings or even searches. Usernode provides an easy customizeable default view. * Makes building of nodeprofiles easier. You may use it to present the user's nodeprofile to the public. * Use features, which other modules provide for nodes, with users. Think of comments, taxonomy... If the usernode module is installed, the nodeprofile module sets a nodefamily relation between the content type of usernodes and all nodeprofile content types, so that it is possible to easily get all node profiles and display them at the usernode. How do usernodes interact with nodeprofiles? ---------------------------------------------- The default display of the usernode shows links to all child nodes of any existing nodefamily relation. This will list nodes with a content type marked as nodeprofile. So you can use the usernode for viewing all profile pages of a user. By using the nodefamily relations you are able to theme the display of the usernode to display the whole content of a nodeprofile or to use the information from multiple child nodes to theme your usernode attractive. Have a look at the nodefamily README for further instructions on how to do this.However, yes with CCK 5.x you are able to attach fields to a usernode. I left this opportunity open, as it might be useful in several cases. But I suggest to don't build a nodeprofile out of it. Usernodes are created automatically for each user, that doesn't suit well for profiles, e.g. you can't determine any more if a user has filled out his profile, you will have a lot of empty profiles for those who don't filled it out, you get in troubles if you have required fields in there, as admins can't edit the usernode any more without they have to input the required fields for this user!!
So just don't do that if you want to build a profile! Usernode != nodeprofile!
I disagree
For my website, having usernode = nodeprofile is exactly what I need. Since it is not that way out of the box, I took steps to make it work that way. I don't understand why it upsets you so, but I'm certainly not going to stop doing what I need to do for my site because it isn't how you intended your module to be used. If it's really that much of a problem for you, I'd be happy to put a disclaimer at the top of the tutorial that this method is not recommended by the author.
Michelle
yep, please add this
yep, please add this disclaimer. I'm glad that this way suits for you, but it confuses people just more if there are several tutorials saying different things.. Perhaps just add the disadvantages I noted above to your tutorial, so that users know that before they do it!
Sure...
I'll add the disclaimer, but your disadvantages don't apply to my tutorial.
Michelle
ah, sorry. I missed that you
ah, sorry. I missed that you are referring to your tutorial. You are mostly using it that way it is intended. Your are not "misusing" usernode. So far so great!
It would be nice if you could point out in your tutorial that there are several ways for creating a proper edit tab, e.g. adding another menu item that points to nodefamily/CONTENT_TYPE or using pageroute. And then just present your favorite way.
Thanks for contributing docs!
Oh, my apologies
I should be careful posting first thing in the morning. :) I totally misread your post and thought you were telling me to stop doing my tutorial because you didn't agree with the method I was using. I didn't understand what you were getting so upset about, especially since you yourself had provided the code for some of it. LOL
Ok, so I'll take out the disclaimer since it's inaccurate and try to work in the other methods of replacing the edit tab. I did mention that there are other ways to do it, but didn't go into detail since I hadn't tried the other ways.
Sorry for the mix-up,
Michelle
With usernode = nodeprofile
With usernode = nodeprofile another thing is meant. Including the nodeprofile node display in the usernode display is how I use it too.
Part of the problem is your
Part of the problem is your choice of names! ;)
'nodeprofile' and 'usernode' are made up of words that mean the same sort of thing.
So a sentence like 'The nodeprofile package provides nodeprofiles without usernodes, usernodes are optional and not intended as profile!' just sound like the same words going in circles.
no. a usernode is just a
no. a usernode is just a node, representing the user object.
profiles and users are clearly not the same thing.
So if that is all that it
So if that is all that it is, "just a node, representing the user object", then what is it for? To be related to a profile page? Why not be the profile page?
It seems that a lot of people (including yourself, IIRC) use it in this way, by wholly embedding a profile node into the usernode. If that is the case then what are the disadvantages of the usernode being the profile?
If you mean that a profile
If you mean that a profile is a page on the site and a user is a human being, then yes.
But so far, I've been thinking of a user as that particular profile page. Maybe I'm wrong.
What do you mean by this: 'Usernodes are created automatically for each user, that doesn't suit well for profiles'?
Why would you want to create a usernode for each user, and have it NOT be a profile?
And what about this: 'The nodeprofile package provides nodeprofiles without usernodes, usernodes are optional and not intended as profile!'
What does nodeprofile.module do without usernodes? That's one part I still don't understand.
Nodeprofile lets you use
Nodeprofile lets you use nodes as profiles.. It cares, that only 1 node is created and provides different ways you could use as UI for users (nodefamily/CONTENT_TYPE url handler, or pageroutes). So it's fully working without usernodes.
usernodes e.g. allows you to list users in views. that's not possible without having exactly 1 node for 1 user. You can also use all the other node tools with users, e.g. taxonomy or comments. That's the main task of usernode.
So as its a node, you also have a page for each user (the usernode view), where you can display details about the user. So it suits very well to display profile information or links to all profiles there. But it is no profile.
I understand the abstraction
I understand the abstraction you are describing here but how does this affect real-world usage?
To say that usernode is no profile is not a terribly helpful statement without an explanation of why this should not be.
Again, I appreciate that the usernode/nodeprofile/nodefamily relationships allow for complex scenarios, with multiple profile nodes and profile nodes of different types (I think). But a lot of people are only interested in a much simpler scenario, where each user has one and only one profile page that is displayed when a visitor follows a user link.
In this simple case, is there any disadvantage to only using usernode and enhancing the usernode content type with CCK to endow it with profile information? I can't see any and the way of achieving this with usernode, nodefamily and nodeprofile is a lot more complicated and requires hacking of themes, etc. to achieve the same result.
Maybe this is simply a use that you hadn't thought of when you wrote the module, but it seems like the perfect fit for a simple scenario, unless you know of any gotchas to this approach?
if it's complicated, depends
if it's complicated, depends on the way you use it.
I've posted the disadvantage in #comment-9494, decide yourself if you want to use it that way..
I'll make a simple tutorial how one could use nodeprofile to make a one-content-type profile, without usernode.
should I be able to edit the
should I be able to edit the overview page?
I just get access denied for http://drupal.org/node/129957/edit
Yeah, I thought you should.
Yeah, I thought you should. (grr)
I'll try and find out why you can't and see if it can be rectified.
Wait, I've just made you the author. See if you can now.
yes, now I'm able to edit
yes, now I'm able to edit it. thanks
cool, I'll make all pages
cool, I'll make all pages yours so that you have more control
cool, thanks
cool, thanks
Hi! Great to see someone
Hi!
Great to see someone making a start on some documentation.
One thing I'd suggest is keeping it to a two-level hierachy, rather than the themed grouping you've started. Users new to these modules aren't going to know what the names mean, so subdivisions like 'Node Profile and Node Family' aren't useful to them.
Michelle's tutorial would then be one in a growing list of recipe-type pages.
I've been meaning to join the documentation team, as I do docs for other software projects. I'll lend a hand with this when I figure it out :)
I think the overview page
I think the overview page should limit itself to describing what each of the three modules do (in two sentences each). If the language is too high-level add a comment and we'll fix it.
Sure. You don't want the
Sure. You don't want the body of the overview page to get too long.
Nor do you want users to have to go digging in a hierarchy. You want:
** More in-depth theory explaining all the modules
** Recipe 1
** Recipe 2
** Recipe 3
** an so on
This depth of nesting is what the Drupal documentation style guide recommends.
new tutorial!
I just wrote a tutorial! -> http://drupal.org/node/130489
So if you are confused by all the modules, read it!
Hope it helps.