Edit tab under main user profile page

hm, this was possible with nodeprofile in 5.x - the feature was called "user categories integration" or so.

However, this part hasn't been ported yet. It would have to go into an new content profile extension module.

I've more important things to work on before - however I'd appreciate every help.

I would be nice if this feature got 100% integrated in the default profile edit button, so that it not just shows up as a new primary tab in the user page, but as a tab/tabs in the secondary tabs underlying the default profile edit button.
Just like the category feature of the core profile module.

I don't know if its the same mentioned by #3, but it would be a useful feature and give the user view a more consistent look.

I also like this idea. it does make more sense. I've been trying for two days to figure out how to hide the View button since I'm displaying the entire node on the user profile and I think it would be great if there were no tabs, just a "more" link if the node is displayed as a teaser since that seems consistent with navigating around drupal sites.

that said, excellent work on this module. I've been able to do a lot for my site member profiles that I haven't been able to do before! I wish I was a programmer so I could help out.

From an end user usability perspective, I think this suggestion makes sense. The primary issue now is that the end user is presented with an Edit tab for the user account edit form and a second Edit tab for each content profile node presented on the user profile page. Confusing to say the least. "Ah," you say, "but this can be turned of in the content type's Content Profile tab." Yes, but that presents the end user with two options: view a profile page with two edit links or view a page with an edit link that doesn't let you edit your profile, as many would expect it should.

An alternate solution might be to have the content profile edit link as a sub-tab under the main edit link on the user profile page, similar to the way profile.module works and as is noted earlier in this thread. Instead of having a sub-tab for each category item as with profile, there could be a sub-tab for each content profile content type. For example, let's say we've got two content types enabled as content profiles: personal and professional. The account profile page tab order would be something like this:

• View
• Edit
• Account Settings
• Personal profile
• Professional profile
• [whatever] profile

This would be much more intuitive to the end user, as it consolidates both account and profile editing functions. In the case of a single content profile node type, some logic would have to by applied to provide a single profile edit sub-tab called "Profile", otherwise we run the risk of ending up with a profile edit sub-tab called "Profile profile".

This may seem like a fairly low-rez UI issue, but I think it's important for usability. If others agree but time is not available to code it, let me know and I'll see what I can do. I'm not a php developer, but I have access to the resources needed to get this done.

Actually, by creating a simple custom module, you can add the secondary tabs you need for the Edit tab (name them as your profile content type if you want).

Then install the Form Block module (http://drupal.org/project/formblock) and set the profile content type to enable this form for a block. Go to that block and set it to only show at the specified url which equals your user/%/edit/tab_name. You can further enhance this by adding the module that allows to specify an automatic nodetitle (http://drupal.org/project/auto_nodetitle) in case you don't want users to have control over title field.

Off course it would be easier if this feature was part of the module itself, but it is definitely possible at the moment if needed.

Regards,

Marius

PS. If you want to get rid of the View and Edit tab on the content profile page itself. Just create a custom page-profile-content.tpl.php (the template name will vary depending on your content type name) and remove the $tabs section. Don't forget to empty your cache under the admin performance settings in order for the new custom page to be registered.

I wonder if it would be a good idea to cover this feature by doing integration with panels?

If you did panels2 integration, it would be possible to do chunks of profile data in tabs quite easily, which would be good.

However, the current state is confusing. We should have a tab for view (including any profile nodes), and then an "account details" tab (Edit) and "Edit my profile" tabs for each of the profile types.

The view link for the profile node should be removed if the node is integrated with the profile view, because if a user clicks on view, they are taken to a page which replicates the data, which is pointless, and they also have no way back to the previous page, as they are taken away from the tabbed interface into a generic node view scenario.

-1 from me on adding a requirement of panels.

-1 from me on panels as well. This was supposed to be a simple module. Otherwise we're back to needing to port bio.

Michelle

There was plenty mention of "helper modules" for this setup. I think it's unfeasible to think that there won't be some requirement to integrate panels and profiles. I suggest that the intention was to make this functionality available in a helper module, although I haven't really given it that much thought...

NikLP - Panels and profiles will certainly be integrated. I just don't think it belongs as a requirement for content profile. This module needs to be as simple as possible to be used by other modules otherwise there will be a need for a simple one which brings us right back into the nodeprofile vs bio situation we have in D5.

Michelle

Nobody used the word "requirement" :) Helper modules are a separate issue...

@NikLP - If you need Panels to edit the profile then it would seem to be a requirement, regardless of what submodule it is put in.

My concern is that this module will try to do to much and so not be a viable option for simple profile storage. The new Panels profile module is going to need something simple. If content profile becomes a do everything module, we will need to look at other options and the most likely of those would be porting bio to D6.

Michelle

-1 for Panels...I for one wouldn't want to install a pretty big module just to support some feature I could use.

The issue mentioned initially doesn't seem so far fetched and could easily be implemented by the module itself without bloating it to much. Couldn't the module just include a path field for each profile content type which adds a menu tab for the account edit page? Then an additional radio check box to optionally hide the view/edit tabs on the page itself? Or am I understanding the issue incorrectly (or its implementation)?

Kind regards,

Marius

+ 1. I´m definately interested in a feature thjat could integrate panels to profiles.

>-1 from me on adding a requirement of panels.

There was never even the thought of requiring panels.

>If you need Panels to edit the profile then it would seem to be a requirement, regardless of what submodule it is put in.

Currently it's possible to edit the profile and there is panels, isn't it?
However I agree that it makes sense to provide that without panels.

>My concern is that this module will try to do to much and so not be a viable option for simple profile storage. The new Panels profile module is going to need something simple. If content profile becomes a do everything module, we will need to look at other options and the most likely of those would be porting bio to D6.

Hm I think I don't get this. Why does adding new stuff make the module simpler? Why you don't want to rely on panels, if your solution makes us of it anyway? Imho you contradict yourself.

> If content profile becomes a do everything module, we will need to look at other options and the most likely of those would be porting bio to D6.
What about helping to keep it simple instead of threatening with porting bio? I really dislike this kind of argumentation.

I agree that the current UI isn't optimal - it never was. I'd like to improve that while keeping things simple, but the question is how?

>However, the current state is confusing. We should have a tab for view (including any profile nodes), and then an "account details" tab (Edit) and "Edit my profile" tabs for each of the profile types.

That sounds ok to me. So the "Edit my profile" tabs would be an alternate way to edit the profile.

@view: Hm, the View link only stays when the display mode is set to node teaser. Perhaps the default should be changed to full node.

There was never even the thought of requiring panels.

That comment was in response to NikLP's suggestion: "If you did panels2 integration, it would be possible to do chunks of profile data in tabs quite easily, which would be good."

Hm I think I don't get this. Why does adding new stuff make the module simpler?

Huh? No clue what that's in reference to.

Why you don't want to rely on panels, if your solution makes us of it anyway? Imho you contradict yourself.

Because if content profile were to rely on panels for editing the profile and you tried to use it with panels user, there would likely be conflicts or at best a confusing UI. That's not a contradiction at all.

What about helping to keep it simple instead of threatening with porting bio?

It wasn't a threat. All I'm saying is that if you were to implement NikLP's idea of requiring panels for content profile and relying on it for editing the node, there's a good chance the module would become too complex for what I need and I'd need to come up with a simpler one. Porting bio is the logical choice if that were to happen.

Michelle

>All I'm saying is that if you were to implement NikLP's idea of requiring panels for content profile and relying on it for editing the node, there's a good chance the module would become too complex for what I need and I'd need to come up with a simpler one.

Actually, the first one here who mentioned requiring panels was Morbus Iff. So no one ever suggested or wanted to so!

We want to keep content profile simple yes, that's why I wondered if we can leave this feature out of the module, but let users do it by using the panels integration. Actually it's still possible to edit and use the module without - like it's usable now.

The question is just
1. Is this feature important enough to get it into the base module, making it a bit bigger and so more complicated?
2. If not, does it suffice to make it possible just by using panels and content profile panels integration?
3. Or if not, is it better to implement it as another small extension module?

Actually for me all of these options are ok. So I'd like to here opinions of others on that.

@view tab:
I've just improved the display style default to be "full content" instead of "teaser". This lets the tab be hidden as soon users disable the edit link.
Once the display style is set to 'teaser', the view tab appears again. (So the full content can be viewed.)

@tabs in general:
I know the tabs aren't very pretty - I'm no designer ;) So if someone wants to help out here and provides a better solution, I'd be really happy about that. But that's another issue.

fago: unfortunately, no, it was you ;)

My response was to your #9, which states: "I wonder if it would be a good idea to cover this feature by doing integration with panels?" I read "covering", in this context, as "to get this feature, we'll use panels".

"to get this feature, we'll use panels" is not the same as "content profile is going to require panels"

Anyway it doesn't matter who mentioned that first, what does matter is, that: "There are no plans to require panels for content profile".

@fago - I'm not terribly picky about how you get to edit the profile node at this point. My only concern is that the module stay as simple as possible and not pull in a bunch of dependencies. I'm not able to put my code where my mouth is at this point, unfortunately, as advanced forum is really sucking up my time. But I'm looking forward a few (I hope just a few) months to the panels user module and we will need content profile for data storage and that's it. Editing and displaying of the profile information will be handled by panels user. So if content profile has turned into a huge monster module that requires tons of code to undo we won't be able to use it. If that's not the case, great, no worries. :)

Michelle

fago: heh. As someone coming from bio.module, who needs/desires/wants the tab on the user profile, if the feature was implemented only in panels than, yes, /to me/, it means that content_profile will /require/ panels module, because I will /always/ need that feature. I suspect this is the same rationale Michelle is applying: if a particular feature that people want requires Panels, than to us, it's akin to saying that content_profile requires panels, regardless if the rest of the module does a bunch of neato stuff /without Panels/.

This is tedious. I mentioned this idea because I thought it would be dandy if c_p provided a simple mechanism to allow things like the whole profile node or fieldgroups to be *available to panels* in a similar way that cck provides fieldgroups/cck elements etc. Plenty of modules integrate with panels. This would be a seperate module. There is no bloat. No-one seems to have actually read this thread.

In #9 fago used the phrase "integration with panels". In #10 I used a similar phrase. In that post I am suggesting that an *alternative* display/edit mechanism *could* be constructed by using panels, if a small module were to be made available. In #11, #12 Morbus and Michelle (resp.) said "-1 to panels dependency".

No-one ever said "make c_p dependent on panels". Not once, ever.

The remainder of my post was an attempt to clarify why the current arrangement of traditional user pages + the current stuff provided by c_p looks a complete mess. No-one's fault, it just needs addressing.

The *potential* for a panels/c_p integration module to *potentially* manage this interface in a funky panels way is entirely separate from the necessity to have a workable interface in c_p *without panels*.

Are we clear on the panels thing now? :)

"Are we clear on the panels thing now?"

Yes, and I still disagree. Making fields/fieldgroups available to panels for editing does not belong in this module or in a submodule. It belongs in either CCK or panels. I'm fairly sure someone is working on this already but I don't have a link handy.

Michelle

OK, so I had a thought. Have a look at this nicely written article about modifying forms in Drupal:
http://www.lullabot.com/articles/modifying-forms-5-and-6. This article specifically references how to override the 'edit' form in Drupal 6, which it suggests can not be done via a template. I have tested it and can now made edits/deletes/changes to the main edit form.

My question is this: can this technique be used to 'move' or 'import' the profile_node_form from the content profile module into the user_profile_form? Or, how about just removing the entire user_profile_form, redirecting users to the content profile profile_node_form, and including the appropriate fields on that form from the overall account page? At the end of the day I have to have one 'edit' button that includes everything for the account and profile so there has to be some way to do this. I can figure out how to make it pretty with panels or something else after all of the appropriate fields are on the same page.

Thoughts?

@Michelle - again, I did not ever suggest it belonged in this module. "submodule" - is that relevant? Does it really matter if this functionality comes packaged with c_p or exists as a separate project??

I would have thought that any "belonging" would be quite the reverse. C_p "wants" panels, but panels doesn't care if c_p even exists, so why should panels (or any other module) cater to that existence or requirement? IMO, that is exactly why c_p should *have the possibility* to integrate. I was assuming this would be perhaps developed by the people that actually *knew* c_p (panels people won't know it, why should they?) would do the dev and make it probably separately available.

As usual I suppose there's something I just don't get, but I can't see what it is. I don't even see what the freaking problem is. Why can't we just develop some code between us that allows stuff from c_p in panels? What's the big deal?

The problem is that making specialized code in content_profile to allow CCK fields to be edited in panels makes no sense. The ability to edit cck fields in panels belongs in either cck or panels.

Anyway, this is getting tiresome and, unless I'm misunderstanding, fago isn't planning on doing the stuff you're suggesting that I'm objecting to, anyway. So I'm done with this issue.

Michelle

All,

This was easier than I thought. I just took the registration module and hacked it up to work on the profile edit page. The enclosed module now allows you to edit your custom profile fields on the 'edit' secondary tab. I haven't yet made it allow for editing of your 'normal' profile stuff like e-mail address and timezone. That's next.

Enabling this right now will make it impossible for you to access your 'normal' profile edit features like your username or e-mail address. You can disable the module to get them back.

Correction - my admin account can edit all of the account fields but my users can't. Must be a permission issue on my side somewhere.

What i would really like is to have all the profile stuff on one page. Is this going to be possible ever?
So you go to /user/1/edit and there it is. Username, password, cck fields, everything. What are my chances?

I'm coming into this discussion late in the game, but I want to throw my support behind adding tabs for editing content proflles. Userprofiles for 5.x works this way. There's a simple option to enable them (versus links on the view page.)

I believe this feature should be included in the base module because it's not an "enhancement", but is rather something that most people have come to expect from Drupal.

#22 "...the tabs aren't very pretty - I'm no designer ;) So if someone wants to help out here and provides a better solution, I'd be really happy about that."

I have sites using c_p and the tabs are confusing. In #7, 2nd paragraph pasada has absolutely nailed it! This is exactly how I would like to see profile editing tabs in c_p behave, ala core's profile.module -- not an alternative feature but a usability improvement.

If anything a submodule or admin option for current tabs layout should satisfy anyone effected.

Does this sound reasonable?

I suspect admin options are going to be a fine way out of this - what we need to do is mock up some use cases though (I mean, draw some pictures of how it "should" look for various scenarios) and make choices about possible admin options from there.

Takers?

Nodeprofile has edit links integrated in like core profile does. Way back when I wrote my first tutorial which became APK, I didn't like this and included code to make the user profile edit a first level tab on the user page. I've since decided that fago's way is nicer, after all, but I know a lot of people prefer the tab on top method. In APK it's optional. I think offering these two choices will hit a lot of the use cases. Anything fancier, involving a panels dependency and whatnot, can be handled in other modules.

Michelle

#36 NikLP: some pictures as requested. Simple, which is the goal. This would satisfy the OP's request and keeps things constant while retaining existing functionality.

fago, sub module or base patch?

It's missing permissions checking but here's a base dev patch for sub tabs to get the mind juices flowing.

Nice patch Chris! Just had a go using it. Minor typo, you need to have $account->uid rather than $user->uid in the form part of contact_profile_user, otherwise you always get your profile page rather than the user you're looking at.

I handle permissions based on permission to 'create profile content', nothing clever to do with 'edit all profile content' or 'edit own profile content'

code>

function content_profile_user($op, &$edit, &$account, $category = NULL) {
  // Administrators only
  if (!user_access('create profile content'))
    return;
...

  case 'categories':
      foreach(content_profile_get_types() as $type) {
        $data[] = array(
            'name' => $type->type, 
            'title' => $type->name, 
            'access callback' => 'user_access',
            'access arguments' => array('create profile content'),
            'weight' => 1);
      }
      return $data;    
      break;
    }
}

Potential issue with using "create profile content" is that in order to create profiles during registration, there is no role applied to the user (as it doesn't exist yet) and so permission for anonymous to create that type has to be applied - this may affect the patch?

Good point. My site only allows the administrator to create/edit accounts so it's fine for what I need, but as you pointed out won't work in general.

@#38 - is this a mockup or are you actually doing this? i'm looking for *exactly* this thing and wonder if this has been presented as a patch or commit to the content_profile module itself...

zilla, I have this working on a production site. The patch will be available for review soon. Inclusion into c_p is up to the author.

@chris - awesome news - it seems to be a difficult to use feature otherwise for users who are still seeing multiple edit options! that's a user experience nightmare !

#40 to allow for additional content types, the access argument might go like this:

...
'access arguments' => array('create '. $type->type .' content', 'edit own '. $type->type .' content'),

and maybe an "edit any" arg also.

Edit: nope that won't work :{P

#41 NikLP, would it be true that a content type/s (profile) included in the registration process require anonymous permissions anyhow in which case there would be no ill effect?

New patch.
Things that changed from the first attempt:

• fix #40 $account->uid so we're dealing with the right user thanks limiting_factor :P
• added settings check for edit_link_sub so now the admin option actually works
• added permissions check by a) node_access() if the current user may create the node type and b) is the current user allowed to edit the node if not we don't want to see the menu entry
• added weight to menus using c_p's weight settings, note the weight is default 0 which puts the menu entry for the content type before "Account". Assuming this is undesirable so weight+1 is the default. Is this bad? Comments please.
• added menu_rebuild() to hook _admin_settings_submit
• changed the shorthand if/else for redirect back for readability

I'm not 100% on the access / permissions maybe someone has a better idea.

Hi Chris - nice work!

A few observations:

* Under the main 'Edit' tab, there are two subtabs: 'Account' and 'Profile' (by design, and this is fantastic)

* When I click the 'Profile' subtab however, the 'Account' subtab disappears, and if I click the main 'View' tab again (to get back to my profile), I'd see the profile node itself, not my user profile - which can be confusing.

* I do see that the 'Profile' subtab link appends a ?destination back to my user profile (a good idea) - but this only works if I submit the profile form - not if I try to navigate back using the tabs.

Edit:
* Just noticed that the module weight is still set to -1 after applying the patch. But even after changing the weight in the system table to 1, the embedded profile is still above the core profile info (e.g, "History Member for xxx").

Has anyone thought about using hook_menu_alter to do any of this stuff? I would have thought that would make things altogether easier...

#48 hi Scott,
1) yep and point of this exercise :)
2) because you are taken to the content profile node with drupal_goto() instead of staying within user categories, this one will be an issue -- one I fixed with theme_menu_item_link() but it's ugly: see code below
3) navigation is still clumsy and needs work to perfect it -- the aim here is to keep the code minimal, and without dependencies. This will be tricky.

4) (your edit) profile weight would be a separate support issue ie: not within the scope of this patch

Thanks for your input, some good points here and things to improve on.

Below is what i'm using to fix the 'View' link on c_p nodes to return to user/x
#49 NikLP's hook_menu_alter() suggestion sounds like a better, more permanent approach -- ideas??

function yourtheme_menu_item_link($link) {
  if (empty($link['localized_options'])) {
    $link['localized_options'] = array();
  }

  if ($link['type'] & MENU_IS_LOCAL_TASK) {

    // this bit rewites the 'View' path to user's profile page
    if ($link['path'] == 'node/%/view') {
      $node = node_load(str_replace('node/', '', $link['href']));
      if (is_content_profile($node->type)) { 
        $link['href'] = 'user/'. $node->uid;
      }
    }

  }

  return l($link['title'], $link['href'], $link['localized_options']);
}

Please review this patch, fixes all the above. Only bug I've discovered is some strange behavior if using core 'Body' field and caching, node access may need improving.

Hi Chris, I've applied patch in #51 but it doesn't appear o be working for me.

Is this meant to replace patch in #47? I assumed so...

but the tabs don't appear different at all now from the un-patched version of CP... even after running update.php & clearing cache at /admin/settings/performance

:?

@Chris #51: First of all thanks for the patch! This is definitely very close to what we need. The UI is definitely the right direction.

I will probably flip the edit defaults so that the sub-tabs are used by default (supplied by Chris's patch) and the nested edit tabs (current functionality) are not displayed by default. As this makes much more sense.

I'm reviewing the calls to unset() in content_profile_user().

unset($form[$category]['#type']);

Appears to break checkbox rendering. Was there a reason you added this?

unset($form[$category]['uid']);

I'm guessing this has to do with the path we are doing this at. I'm concerned this may have some unforeseen issues, but I do see that it gets things working.

One other remaining issue is where the user lands after editing content. Right now its a little disorienting since you remain at the same page rather than going to view.

Still reviewing. I have it merged in locally, but haven't committed anything yet as I want to test more and see if I can uncover the reasons for the error when $form[$category]['uid'] is set.

Edit: The uid error is due to being routed through user_profile_form_validate() and failing validation.

The reason for unset($form[$category]['#type']); is to remove <form></form> from edit node as is embeded into User profile edit's multi-part form which you probably already figured.

unset($form[$category]['uid']); user.module complains of malicious injection or something along this lines.

This approach needs more eyes, it works but is a hackish to main thing is that it saves us 100's of lines of code or dependency of subform_element.module which was fago's concern.

Shame about the checkboxes, maybe this would work:

if ($form[$category]['#type'] == 'form') {
  unset($form[$category]['#type']);
}

I'll have a muck around with it when i get some spare time.

I don't understand your explanation for unset($form[$category['#type']]) is there an issue with a nested form? When viewing via the browser there is only one set of form tags. No actual nesting occurs. Can you point me to documentation or something so I can educate myself?

The suggested snippet doesn't solve the issue. From my understanding they are functionally equivalent.

Yes the nested form breaks in IE, works fine in FF2/3 and Safari.

The reason is that the user profile edit submit is outside of the node edit form, a perplexing issue.

There's no documentation as far afaik as it's not a feature -- should be though. It would be nice to get our heads around it for a core feature request. I'm sorry I can't give you any more clues.

Edit: hmm yes snippet is same-same.

Re my comment in #52
This was because I applied the patch against 6.x-1.x-dev from Nov 4th (which had some changes), and I think this patch was intended for the Sept 29 build.
From my testing so far, this seems to work well -- while I realize there may be issues to deal with still, this is really great already!
Should this patch be re-rolled against the current dev version?

Hi Jeff & Chris,

Re #57 ^^
To clarify - apparently I was completely wrong about the cause of my problems with the patch in #51.
The patch worked fine with the current dev version - what happened was some variables changed so the content profile settings needed to be re-set. Not related the patch at all :D

Re jgraham's comment in #53
I'm having a similar problem with the select widget - I see the select box, but there's nothing inside to select :(
I'm guessing this relates to the broken checkboxes?

I'm eager to hear if you've found any solutions to this (however provisional), as I'd like to test along the way.

Thanks :)
Scott

Re #56: Can you verify which version of IE and OS combination? I tried IE 6 with XP and it worked okay. I was able to edit all sub-forms account and three different profile types successfully.

Let me clarify my previous statement (#55) I meant a nested form via forms API, and not nested forms in (X)HTML as those are not standards compliant. Looking at the HTML output the form tags are not nested and there is only one form on the edit sub-tab forms. Also looking at the source the submit button is included inside the form element. Can you verify?

Attached is a patch against latest. I'm still not ready to commit, but I think this is getting close.

I'm still not convinced the user/node access is quite right. Still reviewing

Re: #48/#50 Account sub-tab disappearing: Can someone verify this with the latest patch? I'm not seeing this.

I've reworked the user access portions and committed to CVS. See details here

I went ahead and committed so that we can get more people looking at this and will hopefully get us to a stable release sooner.

Chris big sorry for not putting a thanks to you in the CVS commit message. :-(

Hopefully it suffices to say thanks here. Your patch was a great start.

Jeff, I'm glad the patch made it into c_p base, thanks for putting in the time to review and commit my patch. The effected browser was IE7 on Vista. There's no problems with a nested form, API wise, albeit semantically incorrect.

I'm getting tabs for all content profiles, even if I've set permissions to not have them appear for a given user role (ie, "edit own xxx.content" is not set in permissions for the current user's role). So, I end up with some tabs that do nothing). I think it needs to check that permission setting to avoid this.

@#63: Are you using the latest dev version the permissions in the patch were incorrect, but I think I have addressed that in my commit earlier today. It looks like the nightly is already built.

We've played around with this in our current community build project. This is what we came up with.

The permissions were used wrong and required the user to have the privs "Administer nodes" enabled to use these.
If not then upon accessing the edit page you would only see the content profile form. Not the account details form. You were actually redirected to the node edit.

To have those privs activated is not an option. We don’t want users to administer nodes.

With those privs on we could see the whole form (user details and node profile content). When we tried saving the form we realized that the UID was missing. While error searching we realized that form_state didn’t include the correct variables. We found them in the form variable and changed content_profile_edit_user_edit_submit to set the user id and node name. Now it’s saving the correct data but when taken back to the form it creates a new node upon every save.

Will try subtabs4.patch today.

I just want to give kudos to everyone that's working on this very important and essential patch. Your efforts are very much appreciated!

All.
We've modified rjbrown99's module to work around the different restrictions and bugs we came to encounter during these days of profile development.

Our goal was to have all fields displayed on one page and not use tabs, which we think would be a disadvantage from a user perspective.

We downloaded the latest content_profile.module from CVS to get rid of user permissions being set wrong and get their latest fixes.

What we've done is:
Changed to load existing node of the user.
Changed to make it save the correct data. Up until now it was creating a new node profile upon every save.

Enjoy.

Hi jgraham,
I tested the latest dev version, and mostly seems to work well! Here are a few things:

* The select list now shows up :) - see issue #58 ^^

* But there's another module I'm using, Dependent Fields (d6 port), which works fine on a CP node, but not under the subtab:
- Now the dependent field shows regardless of it's dependent selection (as if js was not active).
- It's fine when editing the node itself, but doesn't work when viewing as a subtab in the profile via CP.
- I can't test it's functionality (saving data) besides the fact that it doesn't show / hide as it should -- because of the blank screen part of my comment at the issue above.

See this issue for more details #330048: hiding fields on registration using CPReg & Dependent Fields modules?

Any input / advice would be appreciated - since this is an often requested feature, and would be great to work with CP :)

Using the latest ($Id: content_profile.module,v 1.1.2.20 2008/11/05 20:41:50)

I get the following results:

- Content Profiles come in under the edit tabs, but don't honor the "edit own xxx.content" permission. So..all content profiles show as tabs for all roles. For the content that has no edit permissions for the current user's role, the tab gives way to nothing but a "save" and "delete" option, as would be expected, but I really think it should not supply a tab for profile with no editable content.

- Also, the SAVE button, under the edit tab for the profile content that -does- have edit permisions, is not working at all for me (does nothing when clicked). So, upon making edits, nothing can be saved.

Scottrigby - Since I'm not able to save the Editable content, I'm not able to thoroughly test the effects with Dependent Fields...but...for me, when Editing, the dependency is NOT being honored--it doesn't change visibility when it's parent is selected or not selected--the dependent field is always there. That's not happening with you? (and does "save" work for you?)

Not wanting to throw a spanner in the works or anything, but having read http://zivtech.com/blog/taking-control-your-my-account-page it occurs to me that we could completely override the My Account page(s) and build a new interface if we wanted (hook_menu_alter is brilliant)?

What method are we currently using, and what *could* we do?

@daneyuleb Re: #69

- The save button does work for me, using the current dev version. :)

- The dependent field however is still not working when editing the profile node under the tab :(

You win some you loose some.. or maybe it will still get sorted out? I personally am not even sure where to start on that one though (?)

I love to see this functionality too. I love to know it. would be great to have all user settings under one tab.

http://drupal.org/project/account_profile

It's questionable whether or not this is fixed. Under my edit tab now, I have this: http://dl.dropbox.com/u/72790/content-profile-tabs.png

Isn't this what the initial request was for...?

Hi Kenorb,
Thanks for the module, I'll try to use it as I need my content profile fields to appear beneath the account edit tab. All fields to be edited on the same page.

Thanks again!

i have unchecked the box for "Show a link to the content profile creation page, if there is no profile." as well as removed permissions for a user to create certain content profile types based on different roles, but I'm still seeing a link to these profile types in all user profile tabs.

using the latest dev release.

EDIT: I think i'm misunderstanding what that setting is supposed to do. however, these links should not be showing.