I think that it is important to populate profile nodes fields into user class to give an ability for other modules to use this information. It is even more important than user view hook. Usually, clients are not satisfied with default output and would like designers to draw "beautiful" user page. In this case we just need $user to have everything in it. At the moment nodeprofile module doesn't do it, so $user is empty.
Usernode does, but it populates only NODE_ID field. So, you need to call corresponding node_load yourself.
Since, I have a simple situation (only one profile node) I did a simple patch in hook_user() in my module:
case 'load':
$fields = array();
foreach (nodeprofile_get_types('types') as $type) {
if ($node = node_load(array('type' => $type->type, 'uid' => $account->uid))) {
$account->{$type->type} = array();
foreach ($node as $key => $field) {
if (strpos($key, 'field_') !== FALSE) {
$account->{$type->type}[$key] = $field;
}
}
}
}
return $account;
The idea is to gather all node fields starting with 'field_' prefix and populate them into $user.
My feature request is to solve this problem in more accurate manner.
Thanks.
Comments
Comment #1
yched commentedLoading _all_ profile nodes for _each_ user_load seems hardly acceptable, performance wise...
Comment #2
ardas commentedWithout this feature Nodeprofile module can't be used as simply as profile. You will always need to write some code to use it efectively. The main feature of profile.module is that you need only configure it and then you can use $user->profile_ fields to access data.
I don't see any problem loading profile nodes in user_load. You will anyway need to do it when you are visiting user page or making a list of users.
The solution may be implement a static cache inside user_load function just like it was done for node_load.
Comment #3
ardas commentedAnother idea is to avoid using node_load in my patch and change it to executing SELECT statement to load data quicker. This is just like profile module queries profile_data and profile_fields tables.
By the way, profile module data architecture as bad as it was in Flexinode:
1. You can't create index by a certain field
2. You need to write huge queries to access data.
So, I'm completely against profile.module and would like to support user-as-node idea. But to make it flexible we need to make it simple in use.
Comment #4
fagoI agree with yched, that's a bad idea. I also don't like that the core drupal profile behaves that way.
So nodeprofile won't behave that way. If you need the data, load the nodes and you have it.
Comment #5
ardas commentedThis means that only developers will be able to use your module effectively. I'm sure core profile module's authors will not agree with you because Drupal should be effectively used by everybody.
Just a quick idea - why not to load this data optionaly. It will be loaded by default but can be turned off on a settings page if an advanced user or developer decides to load it in a different way. Your thoughts.