Greetings guys,
I want to rise a question concerning approaches to implementing user profiles in Drupal once again. I came across with a necessity to valuably extend user profiles many times and at the moment I see that core profile.module can't do it at all. We switched to nodeprofile/nodefamily modules and found them much more flexible since they were bringing CCK to user system.
On the one hand, I know about approach 'everything as a node' and understand that it is not currently in Drupal core. On the other hand, I have clients who requested features which I can't implement using core profile. At the moment we removed core profile.module from our own "Drupal build" (set of modules our company uses for web site development) and switched to nodeprofile.module
Many months ago Wundo redeveloped profile.module 4.7 and created 'profile new generation'. We ported it for Dsrupal 5.0 and developed several plugins to extend user profile. The new core was extremely raw and plugins were not as powerful as CCK plugins are. As I understood later, profile new generation was stopped and abandoned.
I also found that core profile.module evolution is extremely slow - there were almost no valuable (principal, architectural) changes since 4.7 till 6.0 (dev).
I want to emphasize two huge disadvantages of core profile:
1. No ability to extend profile (create custom fields).
2. Database storage is bad and it is difficult to create custom SQL queries. Storage is similar to flexinode's approach.
CCK solves both of these needs.
The main question is: What are authors plans?
1. Will they try to redevelop profile.module to make it as powerful as CCK?
2. Will they switch to nodeprofile and take it into core?
3. Are they going to bring 'everything as a node' conception into Drupal core?
Unfortunately, I didn't find any answers to these questions?
Thank you.
Comments
subscribing
Nancy W.
NancyDru
These questions are hard to
These questions are hard to answer with any certainty by anyone, before code has been submitted and reviewed in core. My opinion is that
- not everything should become a node but some things should
- unlike files or images, which hijack some useful available node functionality to supplement their other functionality, profiles are much better suited for becoming nodes. They have content, fields, some properties useful for categorizing and not much more.
I also believe that if core switches to a new profile module, either nodeprofile or not, that will be something adapted to use node functionality and CCK according to your question (1) and stripped of multiple-purpose functionality. Usually nothing gets into core "as it is".
Just a best guess of a watcher.
Agreed,
Agreed,
I don't propose to take nodeprofile into core as it is :) It should be improved. I know at least 2 features which requires work:
1. Integration with registration page
2. Loading profile data into $user class. I talked to nodeprofile's developers and they told me that was a bad idea and they didn't like core profile.module did it. Nevertheless, I implemented hook_user('load') to read profile data and insert it into $user class - very useful for theming.
----------------
Regards,
Dmitry Kresin, ARDAS group (Drupal development, web applications and solutions)
Vote for nodeprofile solution... :)
I'm (still) not a developer and I've nothing to say, but I would prefer the nodeprofile solution. it seem's to be the most powerfull approach together with cck.
subscribing
...and of course I'm subscribing, that I'd like to know more about it... ;)
My opinion
Any solution that aims to make a user into a node (which I like for several reasons), must take over the whole process. Nodeprofile does not do this. It does not create a user record - that is yet another function that must be done. It does not merge its fields with the user display - it only adds a tab.
IMHO, Nodeprofile still falls short of a correct solution. It may be a step in the right direction, but it isn't there yet.
I will be checking out Bio soon, as it claims to be more complete.
Nancy W.
Drupal Cookbook (for New Drupallers)
Adding Hidden Design or How To notes in your database
NancyDru
I've to correct myself
With the term "nodeprofile solution" I meant "make a user into a node". I don't care about, how it's named. What I meant is that a user profile should be handled like a node. All I want are the possibilities of a node for profiles... :)
Wouldn't it be possible to have a default nodetype called "user" which has some data stored in another table (i.e. password)?
Certainly
Obviously, it's do-able. Several modules already do. But it's not just making a node, there is a lot of other processing that goes on with it, and that's not all there yet. And, as cog.rusty pointed out above, the core developers would have to decide what would be in that node, how/where to store the values, and what role CCK might play in extending it. It is not a simple change. But it is also a desirable change.
Nancy W.
Drupal Cookbook (for New Drupallers)
Adding Hidden Design or How To notes in your database
NancyDru
nodeprofile doesn't take
nodeprofile doesn't take over user creation - of course. It's a solution for profiles and not for user management. nodeprofile doesn't make user's nodes, it's making profiles nodes.
and indeed nodeprofile 1.1 shows the profiles on the user page. How there are shown might be improved, yes, suggestions?
so of course your suggestions or contributions to make it more complete are welcome!
Thanks, fago.
Yes, you are right. And certainly thee is a place for the way Nodeprofile works. It is a really good module. Unfortunately, I see user management in Drupal, as it exists now, as seeming like an afterthought - and add-on. I don't see the support for users the way there is support for nodes.
This has really come to a head for me when I started working on a site that will be volunteer run and will have several assistant admins managing users. For me to try to tell them that they have to got to as many as 3 different pages, each with its own update button, is just not going to work. The idea of this site is to automate a very manual process that is already creating a bunch of problems. Without a simple user management solution, I will just be trading one set of problems for another.
Nancy W.
Drupal Cookbook (for New Drupallers)
Adding Hidden Design or How To notes in your database
NancyDru
Agree, but simplicity is not
Agree, but simplicity is not that thing which makes Drupal better ... Those who want a simpler solutions should consider to use Joomla oe PHPNuke :)
Drupal was born to serve for professionals. As for me flexibility and functional abilities of a module is far more important than its simplicity.
----------------
Regards,
Dmitry Kresin, ARDAS group (ARDAS group)
Disagree
Drupal is better because it allows us to make it simpler for our users. In this case, the way things are, the "solution" is begging for errors to be made. Yes, if I took care of all user registration and updates, it wouldn't be so bad. But that's not reality. There will be several admins maintaining users, and I cannot count on them remembering to go to 3 different pages, each with its own Update button.
Nancy W.
Drupal Cookbook (for New Drupallers)
Adding Hidden Design or How To notes in your database
NancyDru
True simplicity requires complex planning
Sure Drupal's power can sometimes be attributed to it's complexity, but if a system requires 4 or 5 modules to achieve basic user management and still falls short of the functionality many end users have come to expect from web 2.0 then a restructuring is in order. It takes far more complex code to create a simple, yet flexible application. Some how cck and core user tables need to be unified and accessed in one clearly defined way. At any rate, my sense is that Drupal is just a few evolutionary steps away from it's true potential, and user management is one of the key elements. (kind of like reptilian scales evolving into feathers)
Sorry, but I didn't
Sorry, but I didn't understand what is "doesn't take over user creation"? Could you please explain.
I'm sure nodeprofile can implement necessary hooks to better integrate with Drupal core and bring profile fields to user management pages...
----------------
Regards,
Dmitry Kresin, ARDAS group (Drupal development, web applications and solutions)
Usernode.module does it. I
Usernode.module does it.
I would like to mention when I'm saying "nodeprofile.module" I mean a bundle of nodes nodeprofile/nodefamily/usernode.
In a simple configuration (when you have only one profile node) usernode is not needed - the single profile node is already a "user record". Otherwize, usernode will automatically create/delete a usernode which is a user record which combines several profile nodes.
----------------
Regards,
Dmitry Kresin, ARDAS group (ARDAS group)
Hmm...
I have only a single profile node. But when I "create content" it does not create the user record to go with it. Without that, the user won't be able to log in.
Nancy W.
Drupal Cookbook (for New Drupallers)
Adding Hidden Design or How To notes in your database
NancyDru
subscribing would def like
subscribing
would def like to read about more user, usernode, profile, etc clarification going forward
This one question/query
This one question/query seems to come up again and again. The reason is both solution have some benefits and some drawbacks. After looking at both implementation , though I like nodes as profile , it has some disadvantages. If you use CCK for creating node profiles than understand that CCK gets most of its performance benefit by caching. So in a sense if the profile info is going to be static it wont be an issue and infact will be a good solution. If the profile has some dynamic or frequently changing info, it will negatively impact the performance. In its current form CCK uses about 2 queries/field to read.
On other hand current core profile module doesn't store info efficiently. If storage can be improved it may turn out to be a better solution.
Agree that core profile
Agree that core profile storage is awful: it is difficult to write queries and impossible to optimize storage (index by field).
You can invalidate CCK cache on profile submission if it is necessary. I'm now about to develop a dating site where user profile will have up to 30 different fields. Core profile doesn't allow we to create even a half of them. Even if profile storage is improved there is still a question with extending .... moving forward with improving core profile means create a CCK 2 for profile with its own field API and interface, which I think is a huge superfluous work.
My vision is to take 'profile as nodes' approach into Drupal core.
P.S. One more advantage - it will be possible to avoid native avatar support which is quite limited and use imagefield+imagecache instead.
----------------
Regards,
Dmitry Kresin, ARDAS group - Web site development, Drupal services, Software development, IT outsourcing.
You can invalidate CCK cache
Yes I know it can be done and although I have not checked but I think once you update the node it will automatically clear its cache. The main downside as I see it is in performance if you have a highly volatile field. Also from a conceptual point , users are not content for my web site. This is very different from probably what you want to do. In case of a dating site , its users are its content so conceptually it might make more sense to use CCK for user profile for that.
I have modified profile module for my usage so that I can specify data storage for each field. This allows me to read use profile with cost of one additional query and no impact on cache. I will probably post about it once I have done some more tests on it, but such a module will be more useful in Drupal 6 which has a schema api.
subscribing... interesting
subscribing...
interesting discussion :)
Agreed, but I don't think
Agreed, but I don't think Drupal nodes should be treated as 'site content' only. Today NODE means an 'entity' (in terms of database design) and can be used as a base entity for all information you have even if it is an ordering information. Such approach can valuably extend Drupal idea of a node and Drupal can turn into Custom Web Site Platform instead of just a Content Management System.
----------------
Regards,
Dmitry Kresin, ARDAS group - Web site development, Drupal services, Software development, IT outsourcing.
if we look at that
if we look at that perspective than drupal should have only one table. node table. You can argue that even permission attribute is a node but in totally different domain. But that is not a good design and hence we have different data structure.
True
CC, you make a good point. However, this started as a discussion, more-or-less, of users-as-nodes. I haven't seen a site yet that has member sign ups that does not, in some way, treat users as content. This includes Drupal.org.
Nancy W.
Drupal Cookbook (for New Drupallers)
Adding Hidden Design or How To notes in your database
NancyDru
IMHO what is a content
IMHO what is a content depends on site to site and for most sites user info is not content but metadata about content. On Drupal.org user info is metadata not content. Thats how most site treats their users. In case of social networking site the concepts are quite different where user and related attribute are content.
And after a lot of struggle I am learning this and in case of user as nodes is not an optimal solution , again just IMO. I guess some background is in order, I am **trying** to convert forum based my site with about 50K topics and 100K + replies and 2K users.
In a scenario where user are handled separately in user table ( + user profile table ) , the reads are from a very small table. Hence while reading user info system is less stressed.
In a scenario where I try to use nodeprofile then reading user info equally stresses the system as reading node ie content.
this is all assuming that there is fair amount of activity from logged in users.
I see your point
Yes, in a situation like that, user-as-node could certainly stress the system more than a separate table. However, I think a small tweak to add a caching capability for user nodes (possibly a system performance setting) would probably do a lot to resolve that.
Nancy W.
Drupal Cookbook (for New Drupallers)
Adding Hidden Design or How To notes in your database
NancyDru
CCK already caches the whole
CCK already caches the whole node quite efficiently. So if you use CCK content as nodeprofile its already taken care of. But thats good where user profile doesn't changes frequently. If you have some information that is highly volatile in user profile it not only nullifies the cache it will make it worse because cck will keep clearing the cache and rebuilding it, thats double penalty. Also know that in default config cache is database too.
You could in theory move volatile fields out and handle them manually as your own module but then effort required is too high and in the end you will think why not use your own module has profilenode.
users and user profiles
There is fine distinction between users and user profiles. Even the core profile module is optional and in many sites it remains disabled because it is not needed.
Users is a fundamental entity, and the users table is not likely to disappear. Profiles have fields which may contain resumes, pictures and other information as needed, can have access control, relationships, and many things which are already available or under development for nodes.
For me this rings a bell.
subscribing
Important discussion.
Subscribing.
Subscribing.
content2zero.com
Profiles store user
Profiles store user information, Nodes store content information.
CCK module extends the the core node module with fields addition and other functionality.
The core Profile module could be redesigned (database tables, api, relationship, ...) to allow for additional functionality easily.
With a redesigned Profile module, we could create a module UCK (User Creation Kit) to extend core profile functionality.
----
Darly
Perhaps
And on some sites, it is the members themselves that are the focus. One example would be a dating site. So, in this case, the users are the content.
On every one of my sites where members are allowed, in one form or another, and to one extent or another, the members are at least a small part of the content. In most cases, I can get by with the profile module - assisted by custom code.
On some sites, this is not a workable solution; I have to use CCK and a users-as-nodes solution. This is when the inadequate user support is evident.
Some Drupal users will never see this problem; some will be annoyed by it; a few will be seriously challenged by the short coming.
Nancy W.
Drupal Cookbook (for New Drupallers)
Adding Hidden Design or How To notes in your database
NancyDru
Link to Custom Code to Extend profile.module
Nancy, any chance you could share some of the common custom code you use to extend profile.module?
Thanks,
Shai
http://everydayandeverynight.com/
content2zero.com
Hmm...
Other than a small patch to the Author Information block (which has been submitted to the powers-that-be), all my code is outside profile.module, mostly in the form of pages with snippets in them. I think most of them are shown on my web site.
This may change with my newest site which will be completely centered around the users - who will be the content.
Nancy W.
Drupal Cookbook (for New Drupallers)
Adding Hidden Design or How To notes in your database
NancyDru
Profiles and Taxonomy
I'm still a NewDrupaller and I don't understand the whole discussion.
My Problem is that the USER is the CONTENT and I want to have profile fields using taxonomy.
How can I do this?
I don't want to create a new content type like my_profile or something else only to have the possibility to have taxonomy in userprofiles. The advantages of taxonomy are also very important for userprofiles not only for other content types.
Thanks for help.
Sorry, are you using core
Sorry, are you using core profile.module or nodeprofile.module?
----------------
Regards,
Dmitry Kresin, ARDAS group - Web site development, Drupal services, Software development, IT outsourcing.
Yes we can, we will have two
Yes we can, we will have two huge and heavy modules CCK and UCK... And then we will create Taxonomy CK, Comment CK. There will be four content kits with the same code but each one is applied to its specific entity. This will contrary to good practices of an object oriented approach - user and node have something similar, so they should have a basic parent object. Adding attributes should be an ability of this parent object.
At the moment Node, User, Category, Comment are just 4 separate objects with no parent object. I consider this is one of the greatest architectural errors. It is always easy to separate entities but very difficult to unify them. Today we see that all of them require CCK to be extendable and they can't achieve it until Drupal architecture is changed or nodeprofile nodecomment, etc. modules are used.
You were right when you said "Nodes store content information". But why are you sure that USER isn't a 'content information'. The typical example is a dating site.
----------------
Regards,
Dmitry Kresin, ARDAS group - Web site development, Drupal services, Software development, IT outsourcing.
Roadmap to this Approach?
In a February '07 Lullabot Podcast Jeff Robbins asked Dries Buytaert about this very topic. I would summarize Dries' response as follows:
Do the current nodeprofile modules address the potential hit on performance that Dries discusses?
Can modules under the current architecture truly demonstrate ideas that would require a change of the overall architecture (creating a parent object that would include nodes, comments, categories, and users)?
Anybody have a clue if this is on the radar for Drupal 7?
Shai
http://everydayandeverynight.com/
content2zero.com
We can hope
I would like to think it will be on the radar for D7, but I have my doubts that it will be fully implemented in that version since it is not fully architected yet.
In some ways, I have to disagree with Dries on this. First, I think there is NO "easy solution" - at least not one I can envision at the moment. This is partly because no solution set has yet been "successfully deployed by many Drupal sites."
Second, I think it is quite premature to warn of a "huge hit on performance" when no full solutions are being designed or benchmarked yet. To answer your question, the current users-as-nodes solutions do carry a performance impact (as do any modules) because they are definitely add-ons. But that's an appropriate status right now.
Nancy W.
Drupal Cookbook (for New Drupallers)
Adding Hidden Design or How To notes in your database
NancyDru
Do the current nodeprofile
Honestly speaking, I don't see any performance issues. Each nodeprofile created and extended with CCK will be stored in a separate table - it is the most effective way, far more effective than the approach used in a core profile.module.
nodeprofile/nodefamily/rolesignup modules gives a perfect solution for the case when user profile fields valuably differ depending on a role. In this case we will have several nodeprofiles each consists of only needed set of fields for certain user role. This is the most possible effective approach.
In the solution I'm developing I have users, two roles and two profilenodes with different sets of fields for each role correspondingly. I'll have tons of users of role1 (i.e. 1000000) and a few users of role2 (i.e. 1000). I'll will have 1001000 records in a node table, 1000000 records in a content_type_role1 table and 1000 records in content_type_role2 table (with their specific fields). From the point of view of database storing I don't see anything more effective - the most normalized structure and the easiest way to write queries.
The only problem can be a 'node' table which stores all nodes in the system, but I'm not sure it is a problem since node table stores only several small attributes.
I probably miss something
----------------
Regards,
Dmitry Kresin, ARDAS group - Web site development, Drupal services, Software development, IT outsourcing.
Honestly speaking, I don't
I think its not fair to make such a statement, without understanding performance attribute. For each read it will read both node and content table along with field table. It would be much better if you did some comparison on how many queries are trigerred with core.profile vs nodeprofile.
Thats where I see the problem. I suggest take a look at how content (node) is constructed. I have posted in my earlier post that without cache number of queries is quite large. Thats not a problem if you are going to throw in multiple servers. The other case is when you are not expecting high traffic.
Please take a look at scalability section. To run a 1 million node nodeprofile on a medium/heavy traffic site will require multiple servers. Also it depends
1. how many modules are you going to run.
2. How many logged in user you are going to have.
3. How frequently the profile is modified.
You dont have to look further. Drupal.org runs on multiple servers with master/slave database configs and some patches which are not released as stable version yet. And drupal.org doesn't even have half amount of nodes you are expecting. On top of that drupal.org runs mainly on core module. And in current form cck+nodeprofile drupal.org cant make use of it because of performance penalty it will bring.
In its current form drupal relies heavily on caching for performance, thats ok but if you expect to run a community site with many people logged in the caching is less effective. So please take a careful look at performance of whole architecture keeping in mind the modules you are going to run before making a statement about performance being a non-issue.
In short I am saying that cck+nodeprofile on Drupal 5.2 with moderate traffic and 1 million nodes will end up another major thread in scalability section with title: "Why is my site so slow".
Do the current nodeprofile
nodeprofile relies on cck so any performance pros/cons of cck also impact nodeprofile. It has its own overhead too.
Performance?
Forgive me if the answer should be obvious. A number of posts in this thread speak to a performance hit.
How is Drupal different from other platforms that make extensive calls to a database of users like dating or yellow page types of sites?
(no title)
No difference in principle. The current core profile module allows a site developer to do a number of things by adding new profile fields, for some other applications the blog module can handle user content, while for other application one or more contributed modules may be needed (e.g. views or even nodeprofile + CCK). This is pretty standard in Drupal. Core is supposed to remain slim while covering most common use cases.
To talk about a performance hit for common use cases, you start with some hunch by looking at how many JOINS are needed in database queries and how many queries are involved. Then you also need benchmarks under some common use cases. If a "profiles as nodes" module becomes popular in common cases, it could help confirm or reject these reservations for core,
But performance talk in forums (including but not limited to my own replies) is often "too abstact", to put it mildly.
User Architecture
Node database architecture and api allows for extension by CCK or Developers. Nodes can also be extended with User Information, Taxonomy, Comments, Images, Votes, Files, or as per developed module.
I think we want the User Profile architecture to be redesigned to allow for similar functionality or as mentioned adding attributes to allow for modules to extend both User and Node system.
----
Darly
performance
For performance you have to look at this comment
(CCK w/ 130 field) : 537 queries is about 4-5 queries per field
but also shows that planning for performance is important. 130 fields is quite a large.
subscribing
subscribing
subscribing
subscribing
Subscribing
Mike
About this thread
Hmm... since I posted a reply with a more or less useless general opinion in this thread, I am subscribed and I see it coming up in my tracker every day with new "subscribes".
I was a bit puzzled by this, since I didn't find much "technically" valuable information here, but there must be a reason. It seems there is a lot of interest around this topic, which must mean something.
Users as nodes
Here's a comment that's something other than "subscribing". ;)
This was mentioned earlier in the discussion, but I'd like to draw more attention to it. It's the idea or reworking what a user is in Drupal. Ideally, I'd like to see users existing only as nodes. A user would be a standard CCK type that comes with core. The fields would consist of those that are part of the users table now, but because it's a CCK content type, it would be extensible. By that I mean other fields could be added, and it could do all of the neat tricks that profile.module can do.
I'm not too worried about caching. A method could be select based on whatever type of site is required. (Maybe choose a radio button for user-based sites, and another for non-user-based sites?) What I'm basically thinking here is that we can figure out what to do about caching once we turn users into content. (Yes, I think a user is a piece of content.) It's more important to establish a standard way to manage content, and I think CCK is it.
There are some requirements that would have to be met, as far as i can tell:
The above is what's been in my head lately. Any feedback or thoughts on this would be appreciated.
it coming up in my tracker
Is there a way in Drupal to subcribe to a thread without posting in it ? I see this complaint all over drupal but unless drupal allows for subscribing to a thread without posting what option is there ?
it may be ideal situation for you but it doesn't make sense for many sites. In fact I would say that majority of site do not need user as node.
Have you looked at the node_load ? Its a join of node , user and node revision table. If user also becomes a node, this will probably be even more resource intensive query.
What needs to be done is not make user a cck node type, rather decouple fields and cck so that fields can be used by both CCK and user.profile. e.g. an IP address type field can be used in both CCK or in user.profile . This will reduce duplication of effort, something thats restricting work of cck to move to user.profile
From the point of view of
From the point of view of OOP there should be a USER class which will perform all authentication/registration/etc. logic. So, there is no need to remove it at all. On the other hand, there should be another class PROFILE which is used to extend USER with additional fields. At the moment nodeprofile.module does so.
----------------
Regards,
Dmitry Kresin, ARDAS group - Web site development, Drupal services, Software development, IT outsourcing.
Agree in reference to user
Agree in reference to user table. Different approach on profile table.
The profile table and profileapi should allow for developer extensions (modules) similar to node and nodeapi
----
Darly
Try hook_user
Nancy W.
Drupal Cookbook (for New Drupallers)
Adding Hidden Design or How To notes in your database
NancyDru
We want to extend profile NOT user
hook_user Act on user account actions.
This hook allows modules to react when operations are performed on user accounts.Act on user account actions.
We are looking to extend profile to allow for fields addition. comments, etc.
----
Darly
Hook_user isn't a good thing
Hook_user isn't a good thing since it stores all newly provided data in a serialized view in a single column. You will not be able to perform search by such fields.
Userapi or profileapi is a good idea.
----------------
Regards,
Dmitry Kresin, ARDAS group - Web site development, Drupal services, Software development, IT outsourcing.
The fields would consist of
Agreed but how these fields will be created? I'm developing a module now which needs to create a content type and initialize it with a few fields. Creating a content type is not a problem since we have a hook_node_info(), but initializing fields is a problem. Ideally, I don't want to create my own tables, write queries, etc. I just need to use CCK API to create certain fields for my node type. This API is not ready yet.
Have a look into content_crud.inc fiile, function content_field_create() for instance ..... I'm now suffering of the lack of these API functions.
----------------
Regards,
Dmitry Kresin, ARDAS group - Web site development, Drupal services, Software development, IT outsourcing.
Yeh users-as-nodes would be
Yeh users-as-nodes would be a pretty simple side-effect of any well constructed object referenced system
everything should be a node ;(
(ps.. subscribing.. )
Subscribing
Subscribing, Just to follow along
Subscribing
Subscribing as well.
-------------------------------------------------
AdAstra.ca - Optimze the Web. Optimze the World.
This is a great thread. I think it's...
what I've been searching for since I posted http://drupal.org/node/115940 and http://drupal.org/node/126685 a few months ago.
After reading this post and comments I have a clearer understanding of what I really want: I am creating a fitness website where users can take their own fitness assessments multiply times throughout the year. The fitness assessment will be multiform-ed with (optionally) viewable text, audio and video (downloadable).
In a nutshell:
1) The assessment form is specific ONLY to the user.
2) Multi-part forms.
3) The user can save, view, print, edit and/or delete any of his/her own assessment form.
4) Eventually a progress chart will be displayed for multiply assessments.
I don't mind the least in putting it all together. Just that I have no clue how to begin. Which module would be best to start with? nodeprofile?
Any help will be greatly appreciated.
---------------------------------------------------------
deQuindío Fitness test site
deQuindío Fitness
Thomas Cayne
subscribing
subscribing
subscribing also...
subscribing also...
subscribing
subscribing
sub
scrib i n g
civic crm
How does the civic stuff come into play here ... does it provide an alternate profile setup?
Civicrm Profiles
Civicrm can be configured to have its own profiles that appear within the Drupal profile/registration form.
I am trying to create a profession directory using my civicrm profiles. I have also installed civinode CCK which exposes civicrm profiles in Drupal. http://drupal.org/project/civinode
I need to connect these civicrm profiles to a Drupal Category (taxonomy) . Can this be done using the node profile module.
Subscribing
Subscribing
just i am in ....
.... subscribing !!!!
-- Sree --
IRC Nick: sreeveturi
subscribing
subscribing :)
overriding username when using node profile
Hi there,
I am creating profiles using node profile.
i have fields set up for first name and last name as 'content_type_first_name' and 'content_type_last_name' which are related to my profile node, (which is a child of the parent usernode).
I have found forums discussing how to override username throughout your site with the real name of the user, when using the profile module. Does someone know how to override the username when using nodeprofile instead of the profile moule?
help much appreciated,
sylvie
You're far more likely to be
You're far more likely to be successful getting your question answered by placing a support request in the nodeprofile request queue:
http://drupal.org/project/issues/nodeprofile?categories=support&states=all
You should overload username
You should overload username theme function. If you are using PHPTemplate engine your function will be called
function phptemplate_username($object) where $object is a user class. You will need to load your profile node here and take necessary fields or you can load this node on hook_user if you want them to be loaded for all user_load() calls.
----------------
Regards,
Dmitry Kresin, ARDAS group - Web site development, Drupal services, Software development, IT outsourcing.
sorry -don't understand
hey ARDAS - thankyou for your reply
but i'm afraid i'm a real newbie and can't understand what you are saying - maybe you could explain in layman terms? i follwed the tutorial at http://shellmultimedia.com/node/274 in order to get my profiles.
thankyou!
Easy to use != not powerful
I am subscribing.
I want to voice support for whatever resolution maximizes Drupal's usability and ease of use.
A commenter above said that Drupal shouldn't be easy because it is for "professionals".
Nothing could be further from the truth. Are modern computers with their GUIs less useful or "professional" than obtuse, byzantine mainframes?
We can ensure ease of use and power if ease of use is a key design criteria and not an afterthought.
Update
Here's a little update, but I'll include some background just in case you all didn't sift through the development list like I did.
Dries wanted folks to get CCK into core for Drupal 6, but the work didn't get completed in time. The new plan is to get CCK into core for Drupal 7. Once this is done, there can be a discussion about profiles as nodes. There is support for this among the core developers. And by "this" I mean only user profiles, not users themselves.
So users will stay more or less the same. I'd speculate that we'll have profiles as CCK nodes somewhere around Drupal 8.
Update & questions
How should the user profile (redesign) data be stored and managed?
Should the updated profile module use node table (contents) or not?
Should the updated profile module rely on its table (profile) to manage user profile data?
As stated, Speculation...
----
Darly
Leave the core like it is
Hi ARDAS,
I agree with you that core profile module is not very flexible. But as mentioned in this threat, it´s slim and covers the most features a Webside needs. We had the same problem as you developing a website for a client what we did we wrote a own module based on the bio.module and the usernode.module. This combined with the nodefamily makes the most powerfull user.profiles you can imagine. I think as most of the user.profile needs are very "individual" there is no module from the scretch that can solve all our problems once.
See some exampels at www.freelens.ws/dirksway (test/test).
Dirk
(no title)
I agree that core should stay slim (well... I already said that), but I will add a few words about my understanding of how things work.
What I see as the main issue here: The nodeprofile module already exists. However, getting something into core:
(a) Gives site developers an assurance that it will remain supported or some migration method will be provided.
(b) This assurance also makes it more likely that module developers will build more specialized applications on that solution, not always starting from scratch.
For the core profile module, there are already a few small contributed modules depending on it, for example adsense, birthdays, 18n - profile, site_user_list.
At the moment module developers probably feel safer to take core as a starting point and add there their extended functionality to cover their needs. Very few will be bold enough to build new applications based on the nodeprofile module -- there is no "insurance" for its future, except perhaps if many developers jump on its wagon and it achieves a critical mass.
But I can imagine that a (still slim) core profile module more "open to content" would give module developers the green light to invest time in taking Drupal in new directions and to venture further into specialized community solutions.
And "open to content" these days usually means "using nodes".
I will try a new module
hi cog.rusty
I think I will try a slim module to extend the core user_profile. What I imagine is a module, that auto creates for every user. It should provide a basic node type (title, body) and a tab in addition to the core profile tab, but not displaying his own content in the core profile by default. The tab should be renamable through the admin settings of the module. In the admin settings you also should be able to take over the core profile, like in bio module.
Today I read again most of the toutorials about user as nodes and the basic needs of user (website designer like me). I came to the point that applications like nodeprofile are to advanced for most of the users. Even I do not understand the sence of it.
For example with a module like described above you can make easily a galerie per user. Just with CCK and view reference. Or any thing else you want. If you can rename the tab in the admin settings one user can call it "my gallery" display a view with images per user in it, theme the tpl and ready or you can call it my bio and just display a simple CCK textfield etc.
Somebody would test a module like this?
Dirk
New Module for user as nodes
Hi,
as I promissed yesterday in my post I worte a "new" module for user as nodes. Thanks to Jeff Robbinson and his bio.module. I lend some code from him!!!!!!
OK I made a work around, that needs to be reviewed by some good Drupal coder, I´m just a webdesigner.
What does the module.
1. It provides a node type for each user where any user just can have one! This node type is created and publish the moment anybody goes to the user account.
2. It provides by default two tab´s in the core user profile. One for viewing the content type and one for editing.
In admin>>settings>>user_tab you can make the following settings: 1. Rename the Tab to anything you like, 2. Take over the core user profile 3. View the tab at the core user profile.
In admin>>content>>types you will find the basic node type called "User Profile". It just has an Title and Body field but with CCK, Views and theming you can do a lot with it. With the node type you can make user listings based on the "user profile" etc.
Don´t forget to configure the rights.
TODO: write a uninstall to delet the nodes after uninstaling the module or a user! Maybe find a better way for the auto creation process of the node.
You all I hope that someone will help me to bring it to an end and make a god module out of it.
Dirk
UPS how can I publish the module here no atachments possible.
Could you please summarize
Could you please summarize what are advantages of this module in comparison with nodeprofile.module and usernode.module?
----------------
Regards,
Dmitry Kresin, ARDAS group - Web site development, Drupal services, Software development, IT outsourcing.
Advantges of the maybe module
Basicly all of them from a usability point do not behave like the core user.module. You go to create content to create your "profile". I belive that this is a weak point of all of them. If I´m a user I want to stay in one "frame to do all my things" like in xing or google. This is what our clients expect from us when they want a new "CMS-website".
Lets go and see what the modules do exactly: Usernode auto generates a node for each user, to use it in views ect. You can use CCK to put some fields in it but it will never rederect you to your account after editing your content. You may not rename it or give it a different title it will breake. You can via your template overide the default user profile and than you have one user one node profile! How to put additional pages in a user page with usernode and you have no tabs like in core.
Nodeprofile looks like a more advanced solution, but it will not autocreate, a node for each user. Its needs one more module to restrict the node population to one: nodefamily. It wont give you additional tabs in your profile. It just displays new content types at the user profile with two subtabs. If you want to create or edit your content you will not be rederected to your profile after this. i allready had a conversation with fago some month ago about this.
Both of these modules use a lot of code, so its not easy for any developer to make some custom features for them.
Finally the bio module. One node for each user, but not auto created. First the user have to go to create content and then he has only the right to edit it. He may not go to create content any more. But he has to find a different link else where to edit his Profile. You have a function link in it to display a link of the user on any node type that he created (First you chose the node). This for me is a dubbel of the submitted by link. Than you may chose wich content type to display at the user profile instad of the bio. But why I nerver got the point. If you chose to display, view and edit the bio node at the user profile the tab is a "MENU CALLBACK" and let you edit the node via the user profile. The content of the node is displayed at the core profile "view tab".
God is that you have a tab in the user profile, god is that you can take over the core profile. God is that it has only 300 lines of code, easy to custom.
So after all this research I did and looking around in the forums, developing two big websites for my german clients I allways found that it was all to complicated and I did not liked the usability of all of them. Not as a user not as a admin. So I developed some modules for my clients with help of a very god coder Jutta Horstmann, that have a usability more like xing or google. But when we developed the modules there where very client specific and not meet the expectations of a drupal user.
So there for I decided to make my own try. My module can auto create a node for every user, it has two tabs in the user profile one for viewing and one for editing, like the core profile. I think this is easier for a site user (one profile page, one behavior). It does not display the content of this new node at the core profile (view tab), its displayed under the new user tab. You can rename the tab via the admin settings. For me very important, because I do not have theme the template.php for this. So for me this tab can be "biography" for you it can be "my sports" but in the background everything stays the same. You may take over the core profile if you want. After edditing your content you will be rederected to your profile page. Any user can give the node an individual title. So you have the tab "my sports" and an user title "bike", but if you go to edit it will show you "my account" as title to let it clear where you are.
Its a first step. I will put the module on a beta site for testing it. I allready changed the auto creation part of it. And I´m thinking to do not use the profile take over function any more.
Dirk
Deleting
This was a copy of my old comment
User tab
Hi to find the module just go here http://drupal.org/node/184868
Dirk
Bio module seems to be shaping up
The bio module now has a patch in the queue for enforcing registration requirement and is under active development. This combined with the fact that it's 1 module versus several has made the bio module my own choice of what to go with after having looked at a scores of pages on Drupal.org/elsewhere.
Just thought I'd share my findings. :-)
~~
HigherVisibility
subscribing
subscribing
subscribing
Interesting thread.
subscribing
subscribing
Profile module fields option
I think a feasible solution would be for Profile to work as follows:
- Remove option to create additional field within Profile module
- Extend Profile api to allow for contributed modules development
----
Darly
Subscribing
subscribing
From a different angle,
From a different angle, theres been some work on the members module getting it to interact with the profile module http://drupal.org/node/200826
+1 for profiles as nodes in
+1 for profiles as nodes in core - subscribing
subscribing
just subscribing...
subscribing
subscribing
Really interesting
Really interesting thread.
The problem is, that I'm not sure which module I should use to add some more field to my users, let's say, website, country... just a few text fields initially.
I think it will be really useful to have a brief summary, detailing which of the modules is better for which case (let's say: profile: for adding some fields. usernode: to be able to use other modules with users... don't know).
ditto
ditto
I too am confused now as to
I too am confused now as to how to extend user profiles.
And I'd like to add some 'user integration' with other modules. My site is event specific (using event, signup modules) and would like to add profile fields to the signup form and have the submission of that form update user profiles (or even for that matter, if the signup user is not a user on the site, simply submitting the form would create the user account and update the profile with that submitted data.
I am finding that people find it hard to signup for an event if they have to first signup for a user account, authenticate, login and THEN go back and signup for an event. You easily lose them along the way.
I think this is the direction that this thread has evolved but I may be confused....I think it's all a way of slowly collecting user data as you engage the user in different ways along the way.
My goal is to make the experience for the user less cumbersome while still slowly collecting data along the way so you can target more activity toward them (advertisements).
So I'm confused as to what modules to use? I looked for discussions on this as I've used the core profile for a while and have never found it very useful other than letting users manually enter profile data about them and then it just let's the user data sit there dormant...
+1 for profile as node
Seems like a good idea to me, but i also think that keep user stuff e.g. authentication and primary contact details (email) separate is the right way to go.
Does anyone know any good links / reviews of comparison solutions?
I currently understand the major players are the Bio module, usernode module and the nodeprofile module (+ supporting modules), i'm thinking this is ripe for a detailed blog post. I would love to see someone take a pretend brief of a dating site (as its already been talked about) and work up the different solutions and compare them in terms of hard numbers (SQL queries, page load times, memory usage etc) as well as user experience and how easy it was to customize etc...
(oh yeah also subscribing :P )
Drayen
Content profile
Just noticed http://drupal.org/project/content_profile for D6
Fago care to comment ?
--
acmconsulting.eu
subscribe
JBI
We have movement on
We have movement on this...
"I'm really happy to announce that Content Profile is going to be the common base module for "profiles-as-nodes" solutions in drupal 6.x!"
- https://more.zites.net/content-profile/the-profiles-as-nodes-base-module...
also see
http://drupal.org/project/content_profile
Good news....
a_c_m
Site certificate
Your Site certificate is invalid. Anyone clicking on it should do so at their own risk.
NancyDru (formerly Nancy W. until I got married to Drupal)
NancyDru
It was linked to from Drupal
It was linked to from Drupal planet, so i assume its safe. Its not my site.
add
subsribing
subscribing
subscribing
subscribing...
it all basically comes down to the fact that the profile system in core drupal needs to be severely upgraded. i am subscribing as well..
www.evolvedideas.net
Providing evolved online solutions to any variety of ideas.
subscribe
subscribe
Profile synchronization idea
I posted an idea for profile synchronization with nodes here:
http://drupal.org/node/309913
It's attempting to solve the problem of some modules that use profiles, and others (the vast majority) that work with nodes. For example, the Webforms can use information out of a user profile, so giving up profiles all together is detrimental in this instance. However, of course having node-based profile information has obvious benefits (use of the Views module, for example).
So complete functionality of this new module would maintain synchronization between content in a user's profile and a user's profile node. Make a change to one, and it becomes reflected in the other. Now any module can be used on the site, whether it makes use of user profiles, or handles nodes only. Granted, this solution means a duplication of data in the database...but with a trade-off of across-the-board compatibility. Per discussions, the Content Profile project does not plan to work with Drupal 5.x, and I'm not happy with the node_profile solution (requires many modules to implement, and does not solve issue with modules that use the core profile module).
Another benefit of this module is for one-time translation/transfer of existing user profile data from profiles into nodes. The module is installed, and the used by the admin to create a node for each user + populate profile data into those nodes. Then the module is uninstalled, and the admin can use whatever system is in place to handle new users.
Thoughts?
(use of the Views module,
FYI this major drawback to the core profile module has been eliminated with d6 and views2, making the necessity of using a node profile module somewhat less.
===
"Give a man a fish and you feed him for a day.
Teach a man to fish and you feed him for a lifetime." -- Lao Tzu
"God helps those who help themselves." -- Benjamin Franklin
"Search is your best friend." -- Worldfallz
Good to know
That's good to know. The other aspect of nodes that I'd like [to use with profile nodes] is taxonomy.
True enough and there's
True enough and there's still plenty of use cases for a node profile module, but at least you don't have to resort to the added complexity in cases where you just need views of user data.
===
"Give a man a fish and you feed him for a day.
Teach a man to fish and you feed him for a lifetime." -- Lao Tzu
"God helps those who help themselves." -- Benjamin Franklin
"Search is your best friend." -- Worldfallz
I'm 'glad' that this profile
I'm 'glad' that this profile issue will be taken care of in d6...BUT I've spent a tonne of time converting core-profile data to the Bio module...now when I upgrade those sites to d6....I dread what the process will be to get back to using the core Drupal (d6) profile system...
you won't have to if you
you won't have to if you don't want to. The content_profile module is supposed to be the successor to both the nodeprofile and bio modules and I believe it will provide an upgrade path.
===
"Give a man a fish and you feed him for a day.
Teach a man to fish and you feed him for a lifetime." -- Lao Tzu
"God helps those who help themselves." -- Benjamin Franklin
"Search is your best friend." -- Worldfallz
Subscribe
Subscribe