Tip:
Highlight text to annotate it
X
There is one Drupal specific point I think we should address ahead of time,
that is whether to store a personal data as nodes or as users. This issue comes
up whenever you want to store information about people on your site, and you
might want to let those people actually log into the site and change their own data.
Their information could be stored as part of the user profile or it could be
stored in a separate node completely unattached to their user login. This video
will talk about the advantages of setting up your site both ways, and we'll
even show a third hybrid way that I've sometimes found to be better than those other two.
There are four good reasons for talking about this issue. First of all, it's a
common question that often comes up whenever you are building a site featuring
data about real people and where those real people might actually become users of the
site. Secondly, we are specifically going to build
a site that has personal information, and we could decide to architect
it in several different ways. I want to be clear about the advantages and
disadvantages among them before you see how we actually decide to do it.
The third reason for talking about this now is once you decide to store your
data, either in nodes or users, it's very hard to change later.
The last reason to talk about this is that it's an area of Drupal that's
probably going to change with the release of Drupal 7, and that's going to
happen in late 2009 or early 2010. Understanding the issues of nodes versus user
is an important area that could help you to make the transition to Drupal
7 and keep your site alive for years to come. Now I should mention once again,
this video assumes that you want to store personal data and have to decide whether
to give the people in your site access as authenticated users.
If you are planning to do some other kind of site, for example, something
showing health care trends or a catalog site, you can skip it.
First, we are going to talk about storing the information in the user section
of Drupal. This assumes that you've turned on the Profile module, which is
installed with Drupal, but not actually enabled. To do that you would go
Administer > Site building > Modules, then scroll down until you find the
Profile module. We are going to turn it on now, and Save. There.
But let's get back to talking about the advantages of using the user system. If
you store personal information in the user part of Drupal, there are several
advantages. The first is that, it connects the person that you are talking
about with that person's online activity. So if, for example, they make comments on
certain nodes in your Drupal site or they visit pages, Drupal will actually keep
track of that and you can have some online data tied in with whatever other information
you've put in about them. The second reason is that users could then
control their own information when they log in and they take a look at their
profile they can edit it and change their information. It's a lot less work for
the administrator, if you trust them to do it.
The third advantage is that all of the data is in one place. You don't have to
keep track of both the user and the node. But going against these advantages
are some notable disadvantages. Largest among them is that the Profile module
doesn't let you have as many different data types as a node module, and there
is some other parts of Drupal that don't really interact with the user system
as well as it does with the node system. Drupal sees nodes as the place where you put
content and users as a place where you put information about authenticated users,
that is, not really extensive information, just enough so that they can
get around the system. That leads to the other disadvantage, which
is that some features aren't available. For example, let's say that you
store all the information in the user section, then decide that you want to
feature one of your users on the front page. Well, you can only do that with
a node; you can't do that with a user. There is no way to promote a user to
the front page. So let's talk about storing the information
in nodes. The first advantage is you have very flexible field options. The
CCK module or Content Construction Kit is designed specifically to add features to
nodes. It's not available for users. The second advantage is if you change anything
in a node, it doesn't change any of the information that they personally feel
that they own. For example, if you wanted to say that somebody had changed their
email address, then you could do that in a node, and yet someone could still
log on with the old email address because they are not connected.
Thirdly, and this is actually quite important, more contributed modules work
with nodes than work with users, so you got a lot of features that wouldn't be
available if you decide to store the information as users.
The disadvantages, well, you'll have to take care of all of those nodes,
whereas if you'd stored them as users, the users would take care of the
information themselves, you as the administrator either have to deputize people
to take care of the information or you have to do it yourself. So if someone
changes their address, you have to go and type it in yourself and so forth.
The other disadvantage, there is no connection to that user's online activity.
They add comments, they visit pages; it's not really tied to whatever node you
set up to store their information. There is a third solution, which is to use a
module called Content Profile. The content profile module is available at
drupal.org/project/content_profile. The way that it works is it sets up a content
type called Profile. You create a node in that content type and that becomes
attached to the user's user information, so when they log in and they
edit their user, what they are actually doing is editing that node. That
gives them some control, but you have all of the advantages of working with nodes.
There is a pseudo-link between the two sort of. That is to say, the node is not
actually a part of the user's profile, but it seems to be. And, as I mentioned
the users can actually modify them themselves without any additional help from you.
Finally, I'd like to talk about one big change that's coming in Drupal 7, which
we expect to be released in late 2009 or early 2010, and that's called Fields
in core. What that means is instead of having CCK, the Content Construction Kit
as a contributed module that let's you create new content types, it will be
built into Drupal itself. That's also going to carry with it some big changes
in the way that Drupal handles such information internally.
This hasn't been completely decided, but I believe Fields in core will only
affect nodes. That is, it won't be possible to add fields easily to users even
after Drupal 7 is released. That's one reason that you might want to do your
site with all of this information in nodes instead of users, but if you want to
get the full discussion, and it's a 90 minute audio discussion, go to the URL
that you see here. And I should mention that is a correct URL, where it says
looking-forward. It was a typo on the site.