Display nodeprofiles as profile categories

usernodes are nothing specific to profiles, so I think you want to talk about nodeprofiles -> I change the title of this issue

How would the integration look like you think of?
- Integrate it as profile tab would be possible by using redirects. (without using redirects it would be too much work..)
- Integration with hook_user('view') would of course be possible. Perhaps it would make sense to optionally list a link to a pageroute there. However, that's a thing, that you can't do right for everyone, so I decided to let this open.
Further I prefer using the display of the usernode for viewing the users profile. Users are common with theming nodes, so they can easily adapt the display. So in this scenario the /user page would be quite empty. Perhaps some people have good ideas, what shall be displayed their? I could think of a summary of the settings, that are available at user/edit. However, that's not really in the scope of this project.

I would do something similar it this way:

• Use the theme functions in the template.php file shipped with usernode to make every userlink a link to the usernode.
• Mark your content type as nodeprofile and leave the usernode content-type the default one.
• Load the node_view of your content type in the usernode theme. (code snippet can be found in the nodefamily readme)
• Use the path "nodefamily/CONTENT_TYPE" to create an "Edit my profile" menu item, where CONTENT_TYPE has to be replaced with your nodeprofile content type.
• Optionally activate the "My usernode" menu item, and rename it to something like "My Profile"

Would this fit your needs too?

Fago, you seem to suggesting an alternative to the user profile rather than an extension of it. That's awkward when working with modules that require data to be stored in user profiles. The attached patch allows nodeprofile data and user profile data to be displayed together on the user page. It only works if usernode is not enabled.

thanks.
I agree that this should work without usernode that way.

However you are just printing every nodeprofile with all descendants. First of all I'd print only nodeprofiles. If the descendants shall be included, that should be changed in the theme of the nodeprofile. (Nevertheless I'd like to make this default sometime..)
Furthermore, for multiple profiles I'm not sure whether this shouldn't be list a of links to profiles.
Then people would also request a possibility to edit their profiles - easy to do for the list: just append an [edit] link. But for full node presentation we would something like the view/edit tabs of drupal..

So I think the best way for doing this would be by creating a new type 'nodeprofile', which will be rendered by drupal_render(). Configurable to show a (link) list of nodeprofiles, or to show a list of full nodes or even teasers. Best it should use another configurable element type for producing the single output (full node/ teaser node / links), so that can be easily themed.
Building it that way allows people to easily customize it in their themes, without knowing php. They can just set the flags appropriate and they get what they want..

I think the best default behavior would be to show the full node for a single nodeprofile, and a teaser list until e.g. 3 and the linked list otherwise.

The patch has been modified to allow each node profile to be edited on a sub-tab of the user edit page. Node profile descendants are no longer shown on the user page.

I forsee node profiles being used to make profile fields available to views, a feature which does not seem to be working with regular user profiles. Body/teaser type profiles would simply duplicate the bio module, which allows nodes to be viewed as tabs on the user page.

great work, thanks!

I would suggest to add a new setting, which allows one to turn this functionality on/off instead off using

       if () {
         break;

However we could use !module_exists('usernode') as default value for the setting :)
I'd not mind overlapping functionality with bio. As both are providing profiles as nodes it's of course overlapping.

sry, of course I meant

       if (!module_exists('usernode')) {
         break;
}

I started work on this because profile fields were not being made available in views. I now find its a caching problem. So the only purpose of node profiles is to make CCK field types available. I suspect that the core profile module will support that in the future.

I did some work on your patch, attached is the improved version.
Anyway it still needs a lot of love. The form_id of your forms isn't set properly, so CCK (and others) fail applying its settings. Furthermore one is redirected to the node..

Anyway I think that could be done easily by using the subform form element I wrote:
http://more.zites.net/subforms

However, first I've to create a separate module for that or depend on pageroute...

Here's a patch to make displaying node profiles on the user page a configurable option. It should be simple to add more display options, but since it doesn't look like I'll be needing this module for a while, I'll leave that for later.

Interesting. I'm not being redirected to the node. I added a new content type to use as the profile. Pressing submit loads the updated user page as expected. Maybe it's because I don't have CCK enabled.

hm, now the redirect is working for me too. that was probably my fault.
Anyway attached is an updated patch, based on yours.

Works quite fine, but it still has one big problem:
The form_id has changed and so module relying on hook_form_alter don't recognize the node form. The only fix I see for this is using the subform element I've mentioned above...
Which would mean, another dependency.. :/ Perhaps I should separate it as another module..

The editview module has a simple function to tell modules that it is working on a node form. I've included it in this version of the patch.

Now that hook_form_alter is working I noticed a couple more form sections that needed to be disabled for a clean look.

I think everything is fixed now.

just to show my support for this.. since i THINK this is EXACTLY what i was looking for.. this is a post i made about 20 minutes ago... this is what we are shooting for here isn't??... if so .. hell yaaaa!!! i will try it all out tonight for sure...

============================== earlier post

[stuff clipped out]

my real question:

what i really need usernodes/nodeprofile to do is add to user/x page. I would like to go to user/x and under EDIT see ALL my user edit forms. In other words the "account settings" as well as the cck profilenodes (and i guess the forms that the profile.module adds - although i am not using any). In other words have this family of modules act like the profile.module.

Once i have this i can now easily add other tabs to the user/x page that are view tabs (simply make a view and give it url as user/$arg/my_view1. PLUS i get the other tabs that other modules have added to user page (such as "my subscriptions", etc)

i have read a dozen or more posts and tutorials on using usernodes/nodeprofiles but not sure i have seen the method that integrates editing ALL user info alongside (tabs) usernode related views info... which i think is required for a complete "My Profile" page.

thanks for the starting point.

Peter Lindstrom
LiquidCMS - Content Management Solution Experts

ooops, well sadly this patch is for 5.. and i am still in 4.7 land... took a look and a lot of changes specific to things in the 5.0 ver of nodeprofile module which looks a lot different than the 4.7 version.

Any chance of backporting this.. assuming i guess that this is actually what i am looking for.

Hi Darren Oh

I´m a drupal newbie and I´m trying to apply that patch to the nodeprofile.modul but i can not get it to work. I do not understand how it works. The patch differs a lot from my module.

Can somebody post me please the hole code of the changed module!!!!

One more question: Does it works with the usernode.module installed?

Thanks

Dirk

1. I'll implement this, but it will take its time, but only for 5.x. Of course clean backports are welcome.
2. Don't change issue titles.
3. Of course it will work independent of usernode and keep working if it is installed

@darren:
sry, it seems that I forgot to attach my latest patch. However I don't like this form_alter hack as it will fail for form_alter implementations that edit $form without looking at the form_id.
I've already separated the subform element in its own project - so I'll make use of it to do it.

I don't understand why a hook_form_alter() implementation that ignores the form ID would not work with my patch. I thought only implementations that depend on recognizing the form ID were a problem. Adding a small few lines to the module seems a lot simpler than creating a dependency on another module.

because hook_form_alter() is invoked twice. I don't like it, so it won't be included.

In the meanwhile I've done some further work on nodeprofile. I've just committed a new version, which implements this feature. If you are interested in testing this, wait until the next -dev snapshot of 5.x is generated. But before you install it, install the latest -dev snapshot from the subform element module: http://drupal.org/project/subform_element

There are now new per content type nodeprofile settings located in a new tab located at "admin/content/types/CONTENT_TYPE/nodeprofile". There you can enable this for each nodeprofile.

I just wondered why you had said, "The only fix I see for this is using the subform element I've mentioned above." Anyway, Peter Lindstrom sponsored a port my patch to the DRUPAL-4-7 branch, for which the subform element module has not been released. It's here if anyone else is interested.

great! Have you verified that this patch is working correctly?

It looks to me, that it contains the 5.x node deletion code, which we (jpetso and me) haven't committed to 4.7.x, because it didn't work that way for 4.7.x. Have you tested this?

Furthermore it still contains the hook_form_alter() "hack", which isn't needed for 4.7.x. Could you update the patch to work without?
thanks..

yes, i was a little confused about Darren's patch as far as the delete hook... i had originally applied a patch that i think was to remove profile nodes when a user was deleted - but this interfered with Darren's new patch for the "profile categories". I guess if you are suggesting it doesn't work; i can put back in the original delete code. Thanks for pointing this out.

Also, a couple comments i gave Darren on concept of this patch:

- i use rolesignup and nodeprofile to create different signup forms

- with Darren's patch (which i think REALLY is the right way to go here by having profile nodes working like the profile module) i now get ALL the profile nodes listed under the EDIT tab of my user page.

- the GOOD thing about this is that i get the profile nodes that i have not added to the registerprofile - so it makes for a better UI as opposed to forcing a user to ADD a node later when they want to edit settings on this node)

- BUT the BAD thing about this is that i get ALL the nodes and some of these were not meant for users in that role.

- i thought i could mod Darren's code to only add the tabs set to certain roles as specified in the access control for registerprofile but this only helps if those nodes are set to be on the registration page for that role.. and some aren't.

So, i think there needs to be some sort of role control as to who can "have" certain profile nodes.

and now i just need to get rid of the VIEW tab and ideally have "role_name"/x rather than user/x and i am all set..

thanks fago (et al) for your great work here..

Peter Lindstrom
LiquidCMS - Content Management Solution Experts

and i guess then the _nodeprofile_node_delete function in the patch is not required for 4.7?

and i will still need to pull all the title fields :( .. but simple enough

ok, simple mod to latest patch to only get the secondary tabs that belong to user's role.. since of course cck access control is already available to us.

in the nodeprofile_user hook mod case 'categories' to this:

 case 'categories':
      if (variable_get('nodeprofiles_on_user_page', !module_exist('usernode'))) {
        $types = nodeprofile_get_types('types');
        foreach ($types as $type => $name) {
              if (user_access('create '. $type . ' content')) {
                $data[] = array(
                'name' => $type,
                'title' => $name,
                'weight' => 3,
                );
              }
        }
        return $data;
      }
      break;

can't do an edit with patch for 4.7.

I guess I should have actually tried to do an edit :(

whenever I try to edit a profile node I get this error: Detected malicious attempt to alter protected user fields.

which I think comes from the user module..

so far i have done the following tests:

- unpatched nodeprofile module and simply edit the profile node in usual manner - works fine
- installed patch and edit via the secondary tab at user/x/edit - error listed above
- installed patch but edit profile node directly - works fine

I will continue to look.

well i have found the issue... just not the solution.

the user_edit_validate function in the user module fails on this:

(!user_access('administer users') && array_intersect(array_keys($form_values), array('uid', 'init', 'session')))

which seemed odd since a typical member of course wont have "admin user" access and i would be surprised if the form we just submitted didn't have uid in it.. and looking deeper.. sure enough it does.. but it shouldn't

when i look at the same spot when editing the account settings.. all of the form values such as uid, and init that are checked here are in a $form['_account'] object and not direct keys in the $form array.

since there is a user validate hook invoked just before this i guess the nodeprofile could alter the form by moving these to an _account object.. but not sure of repercussions of doing this or which things to move.. (although to pass this we just need to move uid and init.

ok, fixed.

i think the issue is in the "form" part of the nodeprofile_user function of the patch:

$form = node_form_array($node);
_nodeprofile_alter_node_form($node, $form);

since the $node object has a uid property; when node_form_array runs it adds this to the form..

i changed the code to be

$form = node_form_array($node);
unset ($form['uid']);      
_nodeprofile_alter_node_form($node, $form);

and all seems to work fine now.

hm, yes I already suggested to remove this form_alter() variant. There are cleaner ways for 4.7. to provide fully working node_forms, e.g. have a look at the pageroute 4.7 code.

To be clear - I won't commit any unclean backport to the 4.7 branch. I'm concentrating on 5.x now and new features for 4.7.x have to be clean and well tested! This is not the case with this patch (yet).
Then there shouldn't be different interfaces in 4.7.x and 5.x for the same things. This patch makes a general setting - in 5.x there are per nodeprofile settings in an extra content type tab. So a backport needs to be targeted to bring 4.7.x and 5.x closer together, but it shouldn't introduce more differences. So I would happy commit a clean backport of the work I've done to nodeprofile 5.x, but nothing else.

The uid problem had nothing to do with the form_alter. No backport of the 5.x version is possible until there is a 4.7.x release of the subform element module.

you won't need it. in 4.7.x you can reuse node_forms cleanly without it, e.g. this nodefamily 4.7 function does it:

<?php
function nodefamily_lonely_node_page($type, $uid = NULL) {
  global $user;
  
  $node = node_load(array('type' => $type, 'uid' => $uid ? $uid : $user->uid));
  
  if (!$node) {
    //show add form
    return node_add($type);
  }
  else {
    if ($_POST['op'] == t('Delete')) {
      // Note: we redirect from node/uid/edit to node/uid/delete to make the tabs disappear.
      if ($_REQUEST['destination']) {
        $destination = drupal_get_destination();
        unset($_REQUEST['destination']);
      }
      drupal_goto('node/'. $node->nid .'/delete', $destination);
    }
    if (node_access('update', $node)) {
      //show edit form
      return node_form($node);
    }
  }
  drupal_not_found();
}
?>

This is working well!
Furthermore, the non existence of the subform element module in 4.7 doesn't keep you from backporting the UI and settings storage.

fago, I don't know what you're talking about. Form alter hooks are not working in 4.7 without some function to make it work. For example, menu and comment settings will not appear unless hook_form_alter is working.

What you may be saying is that CCK doesn't depend on hook_form_alter. I haven't checked because I don't use it.

I just tried to point out, that one just needs to call node_form() in 4.7 to get a fully working node_form. So there is no need for _nodeprofile_alter_node_form().

thanks for the tip..

I applied this patch to my 5.x nodeprofile module: http://drupal.org/files/issues/nodeprofile_2.patch (#15 submitted by Darren Oh on March 30, 2007 - 17:16)

But, nothing happened. Is there something else I need to do?

OK, I resolved this issue by uninstalling, then re-installing module.

Note that the "Node profile settings" checkbox does not maintain the check after "save configuration" button is pressed.

Also, when a user attempts to edit his nodeprofile user profile from within "my account", he gets this error: "Detected malicious attempt to alter protected user fields". The user has the "edit own uprofile content" permission ("uprofile" is the name of my user profile content type). What else should I be looking at?

Thanks!

sounds like the uid issue i mentioned in #31 above

Yep, that was it. Only change required was probably due to the fact I'm on 5.x and you're on 4.7:

$form = node_form($node);
instead of
$form = node_form_array($node);

Other than that, worked like a charm. Hope they add it to the patch and updated version of nodeprofile.

Thanks so much!

the latest nodeprofile 5.x dev snapshot has this feature already. Again if you want it, install the subform element module, then update nodeprofile to the dev snapshot.

So to avoid further confusion, I'm closing this issue now. For backporting this feature to 4.7.x please open another one.

Let's use issue 134819 for further discussion of the port.