Integrate profile with user/edit

Your patch implements this as per content profile setting - but it's a more a global setting. Either content profile takes over the profile page or not.

Anyway, I'm not sure about this feature. It removes possible output of other modules on the profile page, which might create confusion. However if the general opinion is that this is a nice thing to have, then let's include it.

I think I'd like to have this option as well. Right now it seems like clicking on "My account" will confuse end-users as it is. I like the idea of being able to create more than one profile, though.

I think the "History" text and the user's avatar should be above the list of profiles on the "My account" page too. Right now the avatar just sits on top of the first profile type that is listed.

+1 for "takeover profile".

Without it, this is more like the "Content Embedded in Profile module", rather than the "Content Profile module".

I love how bio module did exactly what I want without doing the multitude of theme and module hacks (ie: theme_user_profile, all those offered by Michelle Cox). I would love to not have to start doing these again with Drupal 6.

what happened here? anyway i'm building a site that could really benefit from 'takeover profile' option. it's like drupal wasnt really designed for having multiple user groups with varying account settings. i am buidling a website for blind/dyslectics/deaf and need rather different profile pages for each group. having to include this in the existing drupal profile page in a user-friendly way is very time consuming;

I think this would be a great option. I just checked out Bio and it basically it is exactly what I've been looking for: whittling down all this confusion into one profile page is a (customizable) node. I think this is crucial for a social networking site.

Fago, you wrote that Bio "removes possible output of other modules on the profile page", but can't you configure Bio as a panel and have other nodes/views etc feeding into it? As long as Content Profile retains all node-like functionality I can't see the disadvantage over the profile page. It would also solve this issue: http://drupal.org/node/276545

+1!

@"it removes possible output of other modules on the profile page"

Modules may display stuff on the user page, e.g. buddylist shows an "Add to buddylist" link there. When you takeover the profile, the module output doesn't appear anywhere.

This is a commonly requested feature, and, for modules that output content onto the profile page, bio's functionality in D5 provided a decent middle ground, as it allowed either a full takeover of the profile (which is the feature request here) or to have the profile node displayed on the profile page along with the default profile module fields.

In either case, this is also something that could be addressed with a custom tpl.php file that shipped with the module --

http://drupal.org/node/276545 is related to this -- almost a duplicate --

I support porting Bio's "Takeover profile" functionality to Content Profile. This would definitely simplify life for people who want the user profile page to simply display the complete contents of a single content profile node. It would also provide a theming-free solution for people who want a node-based profile but don't want (or know how) to theme the user profile page.

The strength of Bio is that it provides a clean and simple solution by design, the price of which is that it doesn't offer flexibility. I agree with fago's point about this interfering with other module's output in the user profile. Here's a possible solution to deliver the best of both worlds without injecting significant complexity:

1. Provide a global option to specify a single content type as the content profile, as was the case with Bio. If this is set then users may only have one profile and the Content Profile tab is only visible on the selected content type. If it is not set, the module assumes that multiple content profiles are possible and all content types show the enable as content profile option.
2. Have a takeover profile global setting that works as it did in Bio. The visibility of this option would be dependent on a content type having been selected in the global option above. This provides the quick and easy solution for people who don't want to theme the user profile page.
3. Get rid of the edit link over the content profile node display in the user profile and replace with this.
4. Get rid of the "View" link over the content profile node display in the user profile. If it's a full node display, just show the whole node. If it's a teaser, let viewers follow the "Read more" link to view the whole node.
5. While we're at it, let's get rid of the gray bordering and just put a heading of Profile: [node-title]. I've never understood why that stuff needed to be there by default anyway.

This would accommodate those who just want the node to take over the profile. It also provides a similar solution for those who want to provide a single profile node but don't want to get in the way of the output of other modules. Furthermore, multiple content types could be displayed (as either teasers or full pages) without the interface cruft. This would make it much more viable to style the user profile with css alone instead of having to get into tpl.php files.

This is not a perfect solution and may not be feasible within the current direction of the module's development, but until this is hammered out Content Profile will remain a "Content Embedded in Profile module". This is a great module and I am very happy to see both nodeprofile and bio evolving so well. I would also be willing to dedicate resources to help move this project forward. Use my contact page if you'd like to discuss.

Really like the idea.

Another big, big vote for a takeover profile option. Is anything happening with this?

As a new Drupal user, I have to say that out of the box this module made for a pretty frustrating experience---with edit and view and borders cruft uglifying the user profile and leaving the user to figure out how to fix it.

To me, the central idea of this module is to get types of content into a profile that otherwise would be impossible--not wedge in a set of new links that confuse the user.

Just to clarify, the "takeover profile" functionality requested here would lead to a single user account edit page containing both the normal Drupal account stuff (email address etc.) and the content_profile fields, correct?

If so, +1 on the request...

Thanks.

Would really love to see an implementation of this feature.
+1 from me :)

thanks

mediasastra.com

Before this can be implemented, the terms really need to be clarified, as I get the sense that people in this thread mean different things when they are discussing this functionality. Additionally, we have a couple different use cases.

1. One content type collecting profile info.
2. Multiple content types collecting profile info
3. And, within both of these use cases, different people have different needs/desires regarding tabs shown on the page, and the ability for other modules to add output to the profile page.

In short, I'd strongly advocate for mockups to help focus this conversation.

I also think that a good short term solution could involve shipping a tpl.php file that implemented this. Another possible solution could involve the ability to specify a view that overrides the default profile page. But in any case a specialized tpl.php file would be an easy starting point, and mockups of what this functionality would actually look like onscreen would help focus the conversation.

I think this is a great suggestions, so I'm giving it a try...

I'm using 6.x-1.x-dev. I installed the patch mentioned above. I checked off "Takeover the whole profile" associated with that specific content profile template. I logged in as a user with permissions to access this content type's node. I go to /user page and nothing has changed. I was expecting to see that user's content profile there in full view. Am I missing something here? Thank you.

i did this with views

$view = new view;
$view->name = 'user_page';
$view->description = '';
$view->tag = '';
$view->view_php = '';
$view->base_table = 'node';
$view->is_cacheable = FALSE;
$view->api_version = 2;
$view->disabled = FALSE; /* Edit this to true to make a default view disabled initially */
$handler = $view->new_display('default', 'Defaults', 'default');
$handler->override_option('arguments', array(
  'uid' => array(
    'default_action' => 'not found',
    'style_plugin' => 'default_summary',
    'style_options' => array(),
    'wildcard' => 'all',
    'wildcard_substitution' => 'Все',
    'title' => '',
    'default_argument_type' => 'fixed',
    'default_argument' => '',
    'validate_type' => 'none',
    'validate_fail' => 'not found',
    'break_phrase' => 0,
    'not' => 0,
    'id' => 'uid',
    'table' => 'users',
    'field' => 'uid',
    'relationship' => 'none',
    'default_options_div_prefix' => '',
    'default_argument_user' => 0,
    'default_argument_fixed' => '',
    'default_argument_php' => '',
    'validate_argument_node_type' => array(
      'blog' => 0,
      'poll' => 0,
      'ad' => 0,
      'forum' => 0,
      'audio' => 0,
      'bio' => 0,
      'bio_photo' => 0,
      'book' => 0,
      'cck_banner' => 0,
      'comment_minus' => 0,
      'comment_plus' => 0,
      'fotolist_image' => 0,
      'fotolist_index' => 0,
      'header_img' => 0,
      'imported_news' => 0,
      'krutilka' => 0,
      'page' => 0,
      'slideshow' => 0,
      'smack' => 0,
      'story' => 0,
      'video' => 0,
    ),
    'validate_argument_node_access' => 0,
    'validate_argument_nid_type' => 'nid',
    'validate_argument_vocabulary' => array(
      '1' => 0,
      '17' => 0,
      '14' => 0,
      '9' => 0,
      '16' => 0,
      '11' => 0,
      '3' => 0,
      '4' => 0,
      '6' => 0,
      '5' => 0,
      '10' => 0,
      '2' => 0,
      '12' => 0,
    ),
    'validate_argument_type' => 'tid',
    'validate_argument_node_flag_name' => '*relationship*',
    'validate_argument_node_flag_test' => 'flaggable',
    'validate_argument_node_flag_id_type' => 'id',
    'validate_argument_user_flag_name' => '*relationship*',
    'validate_argument_user_flag_test' => 'flaggable',
    'validate_argument_user_flag_id_type' => 'id',
    'validate_argument_php' => '',
  ),
));
$handler->override_option('filters', array(
  'type' => array(
    'operator' => 'in',
    'value' => array(
      'bio' => 'bio',
    ),
    'group' => '0',
    'exposed' => FALSE,
    'expose' => array(
      'operator' => FALSE,
      'label' => '',
    ),
    'id' => 'type',
    'table' => 'node',
    'field' => 'type',
    'relationship' => 'none',
  ),
));
$handler->override_option('access', array(
  'type' => 'none',
));
$handler->override_option('items_per_page', 1);
$handler->override_option('row_plugin', 'node');
$handler->override_option('row_options', array(
  'teaser' => 1,
  'links' => 1,
  'comments' => 1,
));
$handler = $view->new_display('page', 'Страница', 'page_1');
$handler->override_option('path', 'user/%');
$handler->override_option('menu', array(
  'type' => 'none',
  'title' => '',
  'weight' => 0,
  'name' => 'navigation',
));
$handler->override_option('tab_options', array(
  'type' => 'none',
  'title' => '',
  'weight' => 0,
));

subscribe

I was rocking and rolling as I thought your approach was the one.

Unfortunately, when the views page URL overrides, the "My Account" menu item disappears altogether.

It did override the main profile in favor of my content profile, and that was darn cool. Just have to deal with the My Account menu item.

A workaround regarding the "My account" menu item disappear thing when using a View page with the path and argument "user/%" ...

I created a new menu item (My Account) that links to /user. Using the Menu per Role module, I restricted the menu to authenticated users.

I'd like this feature as well. Subscribing

subscribe

There is only one problem with the views solution is that the page title will not appear.

subscribing

in argument title place this - %1

so what happened with this ? still no go as i can see. In my opinion i don't think a view approach is the right way to go. This issue was created almost 1 year ago (March 19, 2008). We should work on a patch for this...

Just a suggestion,
but would a hook script to add a My Profile link to (any) navigation menu do?

The My account (user/%) can still be used.
An option for content profile would not entail a complete take-over, but create an extra menu link e.g. profile/%.
Only one of the content profiles can be chosen. Other types should be considered not being the main profile page.

Hmm, this seems like already done, using something as autopath.
Koen

Subscribing. Couldn't this be done simply with a .tpl.php for the user page?

Heya, I've been giving this a bit of thought. I've done up a mock-up so we don't get all muddled in words here.

I personally find how the current profile types are embedded as a bit clunky. I also find profile titles to be irrelevant. The mock-up changes mirror how the edit tab is organized, when the edit tabs of the profile content types are set to appear as secondary tabs (under the primary edit tab).

The "new" mockup shows how the screen would look given two profile content types and the original account (History, etc.) page that other modules may hook into.

Moving to a profile content type that "takes over" the profile functionality is more straight-forward in this organization, I think. The secondary tabs simply disappear. If you own the profile, view brings you to that content type and edit brings you to that content's node-edit form.

I think a global config page would help too. Above being just an interface for global content profile settings, it could provide a table-form interface for batch-modifying settings for all profile content types. I'll mash together a mock-up of that soon.

Unrelated Add-on: I also wanted to put profile fields into a fieldset at registration. I think the grouping would help users when registering to distinguish which fields would go on their profile.

JamesAn: I like your "takeover profile" mockup. Do you know what would be necessary in order to make this functionality happen?

Very long issue for such a desired functionality...

I too think that views is too much for this.
A .tpl would be great.
JamesAn's mock-up looks great to me.

So - what needs to be done? Is there a workaround for now? ;)

It's just a concept right now.

I think the changes will be more fundamental than template files. The way tabs are organized is set by hook_menu. The following is the approach I'll be attempting in the next couple of days:

1. The tabs of all content profile content types need to be changed to secondary tabs under the primary "View" tab
2. The default profile.module profile page needs to be moved under the "View" tab as the "Account" secondary tab
3. Any primary tabs (other than "View" and "Edit) need to be moved under the "View" tab as a secondary tab

The third goal isn't as pressing as most people here are interested in having content profile "takeover" user profiles.

I'll release the changes as a patch for HEAD, a patch for 6.x-1.0-beta3, and a tar of 6.x-1.0-beta3 with the patch already applied. More to come in a couple of days.

Perhaps we could also add this as an extension module? Or would you integrate it in the base module - when yes with which setting? I'm a bit worried about cluttering the default cp settings to much.

Although a module-based setting would be ideal, a .tpl.php was adequate for my purposes. To create the effect in the attached screenshot I did the following:

1) Copied user-profile.tpl.php to my theme directory & changed it to the following:

<div class="profile">
  <?php print $profile['content_profile']; // Content Profile - only select one node type as content profile ?>
  <?php print $profile['Contact Info']; // Contact Info from CiviCRM - use if you have that?>
</div>

2) Added the following code to themename_preprocess_node in my template.php file:

if (arg(0) == 'user') {
      $vars['tabs'] = str_replace('Edit', 'Account Settings', $vars['tabs']);
      $vars['tabs'] = str_replace('Volunteer Profile', 'Edit Profile', $vars['tabs']); // Replace "Volunteer Profile" with the name of your Content Profile node type
  }

3) Under Volunteer Profile > Content Profile (admin/content/node-type/uprofile/profile, in my case), set the following:
a) User Page Display Style: Show the full content
b) Profile edit tab: Show a tab at the user's page
c) Weight: -1 (so that it would show up near the front of the tab set)

If anyone else finds this helpful, let me know. Ideally, I would like to see another option under User Page Display Style called "Take over profile" which would unset the other fields of $profile besides the content_profile field. Also, I would like it if the tab could be renamed in the interface, so I wouldn't have to do it in a theme override. But, as I said, this meets my needs for now.

seems like a good workaround-will try it out. thanks for posting.

You're welcome! Let me know how it works for you.

subscribing

subscribing

Ok. I've taken a stab at creating a patch for this change. I've managed to integrate a takeover option into the current config options and admin workflow; that was my priority. As a result, some of the code base has undergone larger changes. Since I'm new to the code base, I'm not familiar with some of the coding conventions that were used. Where I was unsure, I followed core coding and naming conventions.

If the below blurb looks daunting (and it does, even to me), check out the demo site with this patch applied to it:
http://cp.jamesan.ca
Admin login: test
Admin pass: test
User login: test2
User pass: test2

The admin has a subset of privileges, enough to clear profile nodes and play around with the content profile settings.

--------------------

Onward with the daunting blurb!

Admin changes:

• Added a "Take over profiles with this content profile (and hide all other content profile types)" option.
• Removed the "Show a tab at the user's page" option so content profile edit forms can only appear as secondary tabs inside the user's edit tab.
• If a content profile is selected to "take over profiles" all other content profile types (if there are any) are automatically hidden, user profile pages become a node view of their content profile node, and user edit tab will contain two edit sub-tabs: one for their account info (email, password, locale, etc.) and one for their content profile edit form.
• If a content profile is made to display (i.e. selected to not be "Don't display this content profile on the user account page") and another content profile type is in "take over" mode, the take over profile type is automatically hidden. The admin can - of course - then change the display option of the previously "take over"-mode profile type.

Code changes:

• Remapped non-admin paths
  • If in "take over" mode:
    • 'user/%user_uid_optional' maps to the content profile node view;
    • 'user/%user_category/edit' maps to the user's account edit form (password, email, etc.);
    • 'user/%user_category/edit/account' maps to the user's account edit form as a sub-tab of edit; and
    • 'user/%user_category/edit/profile' maps to the user's content profile edit form.
  • If not in "take over" mode:
    • 'user/%user/profile/'.$type (which mapped to user's content profile edit form) is removed, where $type is each content profile type;
    • 'user/%user/view' maps to the user's account page, as it is normally;
    • 'user/%user/view/account' maps to the user's account page as a sub-tab of view;
    • 'user/%user/view/'.$type maps to the user's content profile node view as a sub-tab of view, where $type is the content profile type; and
    • 'user/%user_category/edit/'.$type maps to the user's content profile edit form as a sub-tab of edit, where $type is the content profile type.
• Changed access to content_profile pages; content_profile_page_access() is changed to determine access for all content profile operations:
  • $op = 'edit' is the original access check requiring any of: update privilege to node if it exists, owner of node, or administer node privilege;
  • $op = 'view' requires any of: view privilege to node if it exists, or edit access as defined above;
  • $op = 'takeover-edit' requires both: edit access as defined above and user_edit_access(); and
  • $op = 'takeover-view' requires both: view access as defined above and user_view_access().
• Added content_profile_page_view() to render the content profile node view, or present the node edit/creation form if the user can edit the profile.
• Added content_profile_get_takeover_type() as a helper to return the "take over" mode profile type, or NULL if none exists.
• Added a number of comments to the code, mostly with the new stuff, and reformatted some original comments according to Drupal/Doxygen conventions.

Screenshots:

• 236467-39-settings.png: Changes to the settings page.
• 236467-39-edit-profile.png: Content profile edit form (for all display options).
• 236467-39-view-as-tabs.png: View content profile as tabs (original display option).
• 236467-39-view-as-takeover.png: View content profile as takeover profile (new display option).
• 236467-39-DNE-as-tabs.png: View own content profile as tabs, when it doesn't exist.
• 236467-39-DNE-as-takeover.png: View own content profile as takeover profile, when it doesn't exist.

Outstanding issue:
If content profile does not exist and user isn't the owner of the profile and user can't administer nodes, user gets an "Access Denied" error page as they can't access the edit form that's called when the profile hasn't been created yet. Instead, user should get a "Profile does not exist yet" alert page so they don't get confused since it isn't an error on their end.

Sounds good. I'll try to review soon.

@JamesAn - I logged into the test website as both a user and admin, and this looks really good!

Forgot to mention that the patch is made against version 6.x-1.0-beta4.

Does anyone know if other modules add things to the 'view' or 'edit' tabs of the user page? In takeover mode, the patch completely takes over those two tabs and removes all other paths (i.e. sub-tabs) under them.

Changes to be made:
- When in takeover mode, allow admins to rename the 'view' and 'edit' tabs, and the sub-tabs within 'edit'.
- There's a benign typo in the patch code that has no effect as PHP function names are case-insensitive:
The create_functioN in

+    $item_keys = array_filter(array_keys($items), create_functioN('$item', 'return strpos($item, "user/%user_category/edit/") === 0 || strpos($item, "user/%user/view/") === 0;'));

I agree looks great on the demo site

JamesAn:

Profile module adds tabs under edit, but I guess that doesn't matter in this case :)

Also, CiviCRM adds a Contact Info tab under edit so you can edit people's CiviCRM contact information.

I am almost sure there are others, but I've forgotten them right now.

@Evan: I was hoping you would know, as your screenshot on #34 showed a whole bunch of tabs in action.

I'll fiddle around with the path details so that takeover profiles only removes view and edit sub-tabs that belong to the profile module.

JamesAn: I'll get back to you on it soon, hopefully, but I don't have much time at the moment.

Ok, I decided I can at least give you the information on the tabs from the screenshot:

- Edit Profile = the Content Profile path
- Account Settings = /edit
- Files = Ubercart
- Orders = Ubercart
- Track = Tracker or Tracker2
- Track Invitations = Invite
- Contact = Contact
- Dev Load = Devel
- Dev Render = Devel

We don't use all those tabs on the live site; the image was actually from the test. None of the tabs live under /edit except for Account Settings, which is just the main /edit page.

As for tabs under /edit, the only ones I saw were Contact Info & Organization Contact Info (on our live site). The other ones were coming from Profile module.

subscribe.

Thanks for the info on the profile tabs, Evan.

Reviewing what paths the user module creates, the patch actually shouldn't need to remove anything. It simply overwrites the default view menu item when a content profile type is in takeover mode, and tacks on an additional content profile edit form under the edit tab.

Here's a revised patch. The demo site I mentioned on #39 reflects this change already.

Thanks for snippets (#34). :) I think themename_preprocess_node should be themename_preprocess_page (the latter worked for me, former didn't).

@Oliver Coleman: You are welcome! And you're right also - it should be themename_preprocess_page.

I've found a better way to do it now, using hook_menu_alter. I'll try posting that soon.

@JamesAn, thanks for this patch, does pretty much exactly what I'm looking for.

Is the outstanding issue in #39 still outstanding?

Cheers

Oliver Coleman, et al.: Instead of the code from step #2 in my comment #34, I am now using the following menu_alter function in a custom module. Steps #1 & 2 are still necessary, using this method, although you shouldn't have to change the tab weight as I did previously in step #3.

Note that uprofile is the name of my Content Profile-enabled content type. You should change that part to reflect the name of your content type.

/** 
 * Implementation of hook_menu_alter().
 * Remember to clear the menu cache after adding/editing this function.
*/
function MYMODULE_menu_alter(&$items) {

    // Changing tab names and weights
	$items['user/%user_uid_optional']['weight'] = -10;
	
	$items['user/%user_category/edit']['title'] = 'Account settings';
	$items['user/%user_category/edit']['weight'] = -9;
	
	$items['user/%user/profile/uprofile']['title'] = 'Edit profile';
	$items['user/%user/profile/uprofile']['weight'] = -8;
	
	$items['user/%user/delete']['title'] = 'Delete account';
	$items['user/%user/delete']['weight'] = 10;
}

And here's a screenshot of my revised method to take over the profile page (#34 + #53).

Note that the "Favorites" tab is from the Flag module & the "Delete Account" tab is from a customized version of the User Delete module.

Sweet! Subscribe. Very good job james. Thanks

Thanks a lot for this guys, but I just have one (quite fundamental) question.

No matter what I do, I can't seem to get my comment form displaying on my user/xxx page. If I go to the separate content profile node page, I see the comment form, but there seems little point in taking over the profile if I can't get the comment form appearing there.

I've searched for hours but can't find a solution to this problem. Am I missing something really basic?

The reason i wanted to takeover the profile is because here it was suggested that this was the solution http://drupal.org/node/245251

Any help kindly appreciated.

># Removed the "Show a tab at the user's page" option so content profile edit forms can only appear as secondary tabs inside the user's edit tab.

Why do you do so? This is a regression - users using that would be lost. That's not acceptable.

Anyway this quite a fundamental change as it completely replaces the user page thus all output of modules integrating there would be gone. So best I'd like to see that as another extension module (shipping with cp) that users have to turn on explicitly. Of course, if some refactoring of the base-module can help you - go for it!

Anyway this quite a fundamental change as it completely replaces the user page thus all output of modules integrating there would be gone. So best I'd like to see that as another extension module (shipping with cp) that users have to turn on explicitly.

I would like to see it seperate, too. Content Profile seems to be getting more and more complex to the point that I've been considering writing a small module to associate users and nodes to include in APK rather than relying on CP for it. When it was first decided to merge bio and nodeprofile into CP for D6, it looked like CP was going to be fairly simple, much like bio was. But it's since gotten much more complicated. It's your module and I'm not going to tell you what to do with it, but APK's users don't need a lot of this stuff and it's getting to the point where CP is overkill for their needs. Keeping a simple base module with the more complex stuff in submodules would help with that a lot since they would only enable what they need.

Michelle

Michelle, even bio had that feature ;) Nevertheless I agree and I still want to keep it simple.

>But it's since gotten much more complicated.

I don't see what has gotten more complicated? I can't remember doing bigger changes except for the registration integration which ships in a seperate module.

So I hope CP is still fine for you needs too. Anyway I don't plan to add any further features into it. Extension modules are the way to go!

oh something changed, I am the only one left maintaining the module :(

My reply wasn't meant as "everything not in bio is too much" though I can see how it could be read that way. I'm just getting concerned at how much is in the module and seeing another thing added that 1/3 of your users don't need prompted me to speak up. Again, I'm not trying to tell you how to do your module; just expressing my concern. I'll let it drop at that. I don't want to be totally derailing the issue.

Michelle

I see. I really appreciate your input, thanks!

Does anyone know when this patch will be rolled into the module? It sounds like the patch is mostly done and this is exactly what I (and some others) need.

Just to throw a new thing into the mix at this late stage: ;)

I'm surprised no one's mentioned it, but why not have an option to incorporate the profile node fields into the general user account settings form? I have a situation that I think is probably similar to a lot of people's. I'm creating a CRM type system that stores all the usual info about customers as well as settings like "do you want to be a volunteer" and "do you want to receive news updates". All this info is stored in a content_profile node. The only things that aren't stored in a node are email address, time zone, etc. From a usability perspective it seems a bit odd to collect some personal info (email, time zone) on one form and all the other info on another form.

content_profile already has an option to incorporate some or all of its fields into the user reg form, so it seems a natural extension to include them in the general user settings page.

I came across this issue mostly because my client wants to import some user details (only name and email address), send them an email with a one-time login link, and get them to fill in the rest of their details upon using this link. The one-time login link leads to the general account settings page to set a new password (and a couple of other fields), and then the customer would be required to click on the edit profile tab to enter the rest of their info. Would make a lot more sense if they could just enter in all their info on one page. Another possibility is to make the user settings page redirect to the edit profile page with another module, but this seems like a bit of a kludge and requires yet more modules.

Unfortunately I don't have time to implement this (unless the client decides it has to work this way and want to pay extra for it!) but I'm guessing it should only be a half hour job if you're familiar with the module (which I'm not).

Is this latest patch meant to be used with multiple content profile types?

I'm using two types determined by role permissions, and if I select "Take over profiles with this content profile (and hide all other content profile types)" for one type it automatically selects "Don't display this content profile on the user account page" for the other. Then on the account edit page things get very confusing, it seems like the content profile types are getting mixed up.

I agree that content_profile should not try to take over the profile. There are far better ways to override the user profile, both in technical and functional terms; for example CTools' Page Manager + Panels.

What it should include, however, is the redirect from a content profile node (node/%node) to the user account (user/%user) - which is a different issue though.

@fago: That said, I'd be happy to become a co-maintainer.

This issue sounds like a won't fix to me.

APK has that redirect. It's currently limited to the uprofile node type that ships with Panels but I was thinking of expanding that to any content profile enabled node type. That said, it would make more sense to have that functionality in CP itself. If it gets added to CP, I'd just take it out of APK.

Michelle

I am not sure any one noticed . Now with this module 2 URLS (duplicate ?) for same user ...
if some one registered with user name John
two profile URLs are created

www.website.com/john
www.website.com/john-0

In d5 , we were using Bio module and used to redirect john-0 to john. Its not happening after upgrade. Google started indexing both type in our site. I am affraid content duplicate issues.

subscribing

Ops, sry I somehow missed some follow-ups here :(

I agree with #66, the redirect makes perfectly sense for me, but I'm not sure it does for everyone. So perhaps a setting to disable it would make sense?

Please allow me to try to re-open this, with another goal & title.

The problem here is that, while there may be other solutions, as things stand the default solution is cludgy, confusing and suboptimal.

As http://drupal.org/node/586464 notes, there are too many levels of tabs and options; non-expert users simply see this, and have no idea what's going on, because it doesn't make sense.

Non-expert implementers, on the other hand, are not going to know the various techniques above.

I'm not saying that the solution should be part of CP or that an associate/plug-in module should not be available. However we as a community have a tendency to sweep issues like this under the rug, instead of working to make sure they are addressed and that there's a "Drupal Way" solution.

Even a "handbook" guide, with standard 'cookbook' code solutions, integrated into CP via README.txt or Adv. Help, would be preferable to leaving people largely in the dark and not having a preferred "Drupal Way" solution.

Thanks for listening,

~1KT

@1kenthomas: See my code in #53. It should still work on the D6 version of Content Profile. Care to try it, and if it works for you, turn it into a handbook page?

If you think it's not an optimal solution to have people write their own code, then writing a small module that would let people choose a Content Profile type to generate a tab, and the title of the tab would also work. It would have a hook_menu() implementation that used variable_get() to fill in the path and title parameters, a page callback for a settings form, and a setting form implementation, and an added submit handler for the settings form that called menu_rebuild() so the new tab could get registered.

@EvanDonovan:

Already did something like that for the site that brought me here.

With entities in D7, this may be becoming a moot issue-- and the user/entities solution may be ideal. Equally, the way users (and thus profiles etc) were implemented prior to D7, made this a rather sticky issue.

I'd be glad to write a handbook page if I a) saw a clear set of recommendations to give people and b) had the time. I also of course recognize that consideration (b) limits what a lot of other people can contribute, as well, :), but hope that we can push towards more "ideal" solutions if not perfect ones.

Thanks,

I guess there are some relations to #661572: Option to redirect content profile page to user profile page or vice versa. Both solutions should be compatible.