We make use of content profile in various projects. The functionality is much appreciated but the usability is a bit poor, especially the way the node types are integrated in the '/user' page. We've received a lot of feedback these pages are too complicated with a lot of tabs, subtabs and links.
In an attempt to improve this I've looked at the way User registration module integrates the default account fields with the cck fields during registration. I'm not too deep into programming Drupal so I've tried to do some copy/pase/edit in order to integrate the cck-fields into the user/#/edit pages. It is roughly working now except that when submitting Drupal complains fields have been altered by a different user. I probanly don't understand all the details of the order in which the Forms API is supposed to work ;-)

Please find attached a draft version of the content_profile_edit module that might eventually find its way into this module. I'm looking for feedback and improvements.

Comments

Version:6.x-1.0-beta4» 6.x-1.x-dev
Assigned:solide-echt» Unassigned
Status:Active» Needs review
StatusFileSize
new2.4 KB

We did some more work on the module and it seems to be working fine now. I really think this is a big usability improvement for editing content profile data. I change the status to 'needs review' and hope this can make it into the dev branch.

Hi,

I tried your module... the idea is really great! I searched for it as a quite normal feature for the original content profile module.

I think it needs more work 'cause node save doesn't work as expected (content profile fields remain unchanged).

The content profile form appears with title field in the centre of the user form... maybe it should be unset and the content profile form put wherever the user wants with the behalf of #weight attribute.

Thanks!

I got this to work by commenting out the last function (function content_profile_edit_user_modify_submit) on content_profile_edit.module. Next step is to get rid of the secondary tabs that still appear when editing the profile.

Got it - there's a setting in admin/content/node-type/member-profile/profile where you can hide those secondary tabs. Just replace the member-profile piece of that URL with whatever you named your Content Profile node type.

subscribing

Status:Needs review» Needs work

Turns out this wasn't working like I thought it was, but it's got to be close.

If you use this module as-is, both your Content Profile and Account Info fields show up in edit view. If you make a change to your Account Info, it saves. However, if you change a Content Profile field, that won't save.

If you comment out the last function in the module (content_profile_edit_user_modify_submit), the opposite happens. So it's got to be close? Anybody have any ideas? I'm working on it trial-and-error style since I'm not great at PHP, so any help by somebody with skills would be much appreciated!

Status:Needs work» Needs review

Remove the drupal_goto() from line 119. It's short-circuiting both saves from happening.

Only problem this presents is that the message presented to the user now becomes two messages. On my site, for example, I get:

* The changes have been saved. (standard Drupal profile edit confirmation)
* Profile profile: has been updated. (content profile confirmation)

No big deal, I'll probably unset one or the other somewhere else.

subscribing

subscribing

I also agree there should be an additional Profile edit option at the Display settings (at admin/content/node-type/profile/profile). Currently, I have set "Show a secondary tab below the user's edit tab" which is currently the least confusing display style IMO. However, the best would be something like "Show inside the user's edit page".

Can someone please post a patch?

Thanks.

Title:Integration with user/#/editintegration with user/#/edit
Status:Needs review» Needs work

Please make sure to post proper patches, check the documentation.

Category:task» support

Hello,

I've patched content_profile with content_profile_edit and it works well.

I 'd like to switch account sector and profile sector.

Basically, we find first the account block and the profile block after. I'd like to have the inverse (the profile block first and the account block after)

Any idea to do that ?

Thanks,
-Crush

+1 subscribing

Where is the proper patch for this feature?

Oops, I didn't see this issue...

I've done a module with a similar purpose at #689796: content_profile_useredit.

subscribing nice work :)

Subscribing. Would love to see an official module out of content_profile_edit or content_profile_useredit.

Have you any plans to make an official module of this? I'll co-maintain if you need somebody.

It would be awesome to see this in an official module!

Additionally, if we can determine which fields specifically to show on user/#/edit and which fields to show on a different tab it would be nice (in my case I would like firstname and lastname and some other fields to show on the user/#/edit and the rest to be in a tab called Profile)

Thanks!

Subscribing. Would make this module much better for my application.

StatusFileSize
new2.89 KB

I tried this out, and encountered (and more or less fixed) two problems:

  1. If you're using locale module, the user's language setting doesn't save when the amalgamated user profile form is submitted. No error message.
  2. When editing a user as admin, changing the username caused error message "Username [NEW USERNAME] does not exist."

I couldn't quite figure out what was stopping the locale setting from being saved, while all other account settings, content profile data, and even user settings from contrib modules such as Masquerade, were saving fine. I got as far as determining that in the $form_state array, $form_state['clicked_button']['#post']['language'] was set properly to the new language I selected, whereas $form_state['values']['language'] contained the old setting. So I just shoved this bit of code into the beginning of content_profile_edit_user_modify_validate() :

  // Make sure the language setting saves.
  if ($form_state['clicked_button']['#post']['language']) {
    $form_state['values']['language'] = $form_state['clicked_button']['#post']['language'];
  }

Ideally we'd want to figure out exactly why the language setting was being lost, and generalize that code with a mind to preventing any similar occurrence with other modules that alter the user account form with hook_user().

I fixed the problem that was preventing admin users from changing others' usernames by adding a line to content_profile_edit_modify_profile_form(), to get rid of the standard node form validator from the form's #validate array. Seemed OK to do, since node_validate() is explicitly called in content_profile_edit_user_modify_validate() anyway.

  // Also remove node validation.  We will call node_validate ourselves from content_profile_edit_user_modify_validate()
  $form['#validate'] = array_diff($form['#validate'], array('node_form_validate'));

Some notes on the cause of this problem: In node_validate(), around lines 798 - 805 of node.module, if and only if you're editing as admin, the author name is checked to make sure it's an existing user. When using content_profile_edit, the author name node_validate() gets is the new username, which of course fails validation, because the user hasn't been saved with the new name yet. Here's that chunk of node.module:

  if (user_access('administer nodes')) {
    // Validate the "authored by" field.
    if (!empty($node->name) && !($account = user_load(array('name' => $node->name)))) {
      // The use of empty() is mandatory in the context of usernames
      // as the empty string denotes the anonymous user. In case we
      // are dealing with an anonymous user we set the user ID to 0.
      form_set_error('name', t('The username %name does not exist.', array('%name' => $node->name)));
    }
...

No time to rework it as a patch right now, so here is the whole content_profile_edit module with my abovementioned alterations.

StatusFileSize
new3.03 KB

One more little thing - I found that the "Delete" button at the bottom of the user profile edit page didn't do a thing, even throw an error. So I yanked it out and replaced it with a link to user/$uid/delete. In content_profile_edit_modify_profile_form():

  unset($form['delete']);
...
  // Add delete link.
  $form['delete'] = array(
    '#value' => l(t('Delete'), 'user/'.$form['#uid'].'/delete', array('attributes' => array('class' => 'user-delete-link'), 'query' => array('destination' => $_GET['destination'] ? $_GET['destination'] : '<front>'))),
    '#weight' => 99,
  );

This is even hastier work, but who knows, it might come in handy for somebody. Here's the further altered module.

Hi - this was exactly what I was looking for. Thanks! I would like to now theme the user edit page using a template (tpl) file. I have tried using
a file in my theme called: user-profile-form.tpl.php. Also tried adding this to my theme function in my themes template.php -

function chocolate_theme() {
  return array(
    'user_register' => array(
       'arguments' => array('form' => NULL),
       'template' => 'user-register',
       ),
    'user_profile_form' => array(
       'arguments' => array('form' => NULL),
       'template' => 'user-profile-form',
       ),
   );
}

Still no luck. Any suggestions? As you can see I created a TPL for the user reg page, and would like my edit user page to look and feel similar.

:) David

BTW - I'm using D6

I disabled your module and my template file is recognized on the user edit page. Do you have any ideas ZoeN?

:) David

Just for anyone who might stumble upon this - I stumbled on the answer:

Changed template.php in theme to:

function chocolate_theme() {
  return array(
    'user_register' => array(
       'arguments' => array('form' => NULL),
       'template' => 'user-register',
       ),
    'customerprofile_node_form' => array(
       'arguments' => array('form' => NULL),
       'template' => 'customerprofile-node-form',
       ),
   );
}

Renamed TPL file in theme directory to: customerprofile-node-form.tpl.php

AND...

Created a blank theme function in content_profile_edit.module:

function theme_customerprofile_node_form($form) {
//print 'Hi';
}

It literally needs nothing in it.

Hope this helps someone. Thanks to Zoe who looked at it too.

:) David

subscribe

Hm... Doesn't work for select fields :(

Doesn't work with node reference fields.

It actually works fine with select fields on one content type but it doesn't work on another... Hm...

[edit] I had a look at the code but the error seems rather impossible to me. The form array's are getting merged.... Has anyone a hint on where to look for?[/edit]

page-user-edit.tpl.php is the name of the file that you have to use to style it. But the select fields doesn't work, quite annoying. Just doesn't display.

Then also, it mixes 2 different content profiles.

StatusFileSize
new5.95 KB

Didn't find this thread till now, and haven't read the entire thread, but here's a patch that adds it as an option to content_profile_registration and moves around some code so can use a shared function. Shrug.

subscribe

I like the idea of the patch in #31 a lot better than using the unsupported module (so thanks!!), but I'm getting the WSOD on my user/%uid/edit page when I've got the "use on Account edit" option marked.

This happened with content profile 6.x-1.x and 6.x-1.x-dev. I thought it might've had to do with me using CCK 6.x-3.x-dev, but after reverting back to CCK 6.x-2.x, the WSOD persists. My content profile fields are showing up on the registration page; the problem seems to just be on the account edit page.

Has anybody else had luck with this patch? Any ideas about what could be going weird or where to troubleshoot?

Status:Needs work» Needs review

nice patch!

there is a small typo inside there though: look for unidesk_content_profile_registration_add_profile_form($type, $form, $form_state, $node); and remove "unidesk_" in the beginning - it will all work.

@HEY_GERMANO: you can make PHP display_errors, then you would see this small bug and could fix it ;) but anyway, enjoy.

StatusFileSize
new5.94 KB

...Oops; I never actually used the patch sorta (implemented it in a custom module then quickly put copy and pasted it into cp just to make the patch).

Status:Needs review» Needs work

well, I just found an issue with it.. it doesn't consider any permissions.. for example I have my site set up in a way that has 2 profile content types, but one is only allowed to be created by users of a particular role.. so obviously that 2nd content type doesn't appear on the user registration form, but I might want it to appear on the user edit form if the user has the appropriate permission - this was working with tabs, which only appeared for those content types that the user was able to create/edit.

Any chance you could look into this?

Thanks a million.

hey hey, any ideas? :)

StatusFileSize
new6.13 KB

I was as able to make a slight modification to the patch in #35 to make it only show the content types that the user has permission to create.

hmm, this patch does what I mentioned, but at the expense of some pretty weird stuff happening (I think it was also happening in the first version of the patch).

Try something like that: have 2 content profile content types, and make some user have 1 of them created and the other one not.. Then enable both these types to show up on user edit page and add some data into the 2nd, previously uncreated content type. What happens for me is that a new node is created for BOTH content types, so I end up with two nodes of type 1 and one node of type 2.. which is very annoying :(

Any suggestions would be greatly appreciated! Thanks!

I'll be trying to fix up this patch; I do believe I see why arski is having issues.

For future reference, thomas, use node_access to check node access, ie node_access('create', 'content_type').

StatusFileSize
new9.59 KB

Here's a slight update, but def. still needs work.

Thanks for following this up!

Do you mind just saying two words about what you've fixed in this version? Thanks a lot!

Status:Needs review» Needs work

Next try.

Added some merging in of after_build/pre_render/validation/submission to try to decrease probability of conflicts
(lines with content_profile_merge in them)

Adding in customization of what fields appear for each (lines with content_profile_hide and user_profile_hide in them)

Added some access check trying to make sure the user has that profile type and can edit it

Instead of making a new object when saving, get the current one and override with the new values only when relavent.

Have not tested in a set up with multiple content types yet, but have tested both registration and editing.

Status:Needs work» Needs review
StatusFileSize
new10.73 KB

Where did my patch go? ~.~

Hey there,

Just tested it and it still has several issue.

1. So, the biggest problem is that I still get new nodes created when submitting the user edit page, even if a node of that type already exists.. it appears that it works somehow like this:
- if you have a (or more) nodes of a CP type, they are deleted one at a time each time I submit the user/edit page..
- if I don't have it, a new node is created every time I submit the user/edit page (i.e. even if I submit with a validation error)..

2. The second issue seems to relate to the access fix, so if a user is editing his account who is restricted to access one of the CP types, he gets redirected to a page like node/6087/edit?destination=user/50 if he submits the form - either successfully or with validation error. That node in my case is the last of the ones that he IS allowed to access.

A user like admin who can edit all types does not get redirected to one of the nodes, but rather to the usual place defined in the system.

Hope this helps and thanks a lot in advance for your help!

Cheers

So what's the difference between what this patch does and what http://drupal.org/project/account_profile does?

umm, theres probably not much of a difference indeed. Only that this module should be probably doing that and asfar as I can see account_profile is just as buggy as this patch :D

If you are experiencing a bug that blocks new users when they change their profile, try adding $form_state['values']['status'] = 1; before user_profile_form_submit($form, $form_state); in function content_profile_edit_user_modify_submit

any updates on this patch and the issues from http://drupal.org/node/586464#comment-3816102? :(

cheers

Status? Is this still viable ATM?

@ #1

This module will deactivate Save Button from admin/user/#/edit page

@arski did you ever work out the issues from #45? Particularly item no. 2?

Thanks,
JR

@arski I found a temporary solution that is specific to my use case. Please note that I studied this patch and compared it to my use case for content_profile_useredit.module in order to come up with this solution. This fix should work for both modules however, the functions are simply named differently.

Where it says

foreach ($form['#content_profile_edit_use_types'] as $type => $typename) {
      content_profile_edit_modify_profile_form($type, $form, $form_state);
    }

I created if statements that checked to see if the user had permissions to see if the user had the ability to edit the field and "continued" the foreach loop in those specific use cases.

foreach ($form['#content_profile_useredit_use_types'] as $type => $typename) {
        if ($typename == 'Favorite Subjects' && !user_access('edit field_favorite_subjects')) {
                error_log("The for each loop should continue here if the user doesnt have access to favorite subjects");
                continue;
        }
        else if ($typename == 'Profile Subject' && !user_access('edit field_profile_subject')) {
                error_log("The for each loop should continue here if the user doesnt have access to profile subjects");
                continue;
        }
        else {
                content_profile_edit_modify_profile_form($type, $form, $form_state);
        }
    }

This code is by no means a long term fix for this module, but perhaps someone else would like to take the time to rewrite it into a viable patch where the $typename's associated edit field permission is checked before the content_profile_edit_modify_profile_form is executed.

Cheers,
JR