Sorry Nathan, with further testing I find stuff I missed in the port. It's good its found, but it'd be easier for you if they were all at once I know :)

A non-admin user gets the following error when viewing their account page after setting some fields as private and others as not.
Fatal error: Unsupported operand types in /var/www/d62/includes/common.inc on line 2712

The error is because the indexes weren't correct in the FAPI code in hook_user() for generating fields. I just went ahead and duplicated the form building arrays from profile_view_profile() as well.

CommentFileSizeAuthor
profile_privacy_correct_fapi.patch1.59 KBcoltrane

Comments

quicksketch’s picture

No problem. :)

Do you have any idea why this affects the 6.x version of the module but it's fine in Drupal 5? I'd like to maintain the most amount of consistency between the versions as possible.

coltrane’s picture

It's because of the change to the view operation in hook_user() between 5 and 6. In 5 on 'view' returned an array of arrays with simple indexes, like user_user() in 5 but in 6 'view' adds to the $account->content array. Compare to user_user() in 6.

quicksketch’s picture

Status: Needs review » Fixed

Committed. Thanks again!

Anonymous’s picture

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.

izmeez’s picture

Title: Fatal error on user page » Profile privacy Fatal error on user page Drupal 6.x

Just tetsing this module and found the same problem. Is a fixed version available for download or do we need to apply the patch?

Thanks,

Izzy

izmeez’s picture

Priority: Normal » Critical
Status: Closed (fixed) » Active

I hope this is the right thing to do. I have changed the status of this issue to active and priority to critical. I encountered the same problem. An authenticated user after selecting to not display some fields cannot view their account and receive a fatal error. Subsequent attempts by user to view their account also result in a fatal error. It was necessary to disable the module to allow user access to view their accounts again.

It would be good to see this fix in a release. Thanks,

Izzy

coltrane’s picture

This was committed (http://drupal.org/cvs?commit=132363) but a release from that branch has not been made. If you need this now you can try out profile privacy from CVS http://drupal.org/handbook/cvs

izmeez’s picture

Thanks for the reply, but isn't it only people with CVS access that can download directly from CVS? I am not a module developer just someone trying to use it. If an update is available with a fix for this critical bug that would be great. Thanks,

Izzy

coltrane’s picture

Nope, you don't need CVS access to read the cvs repositories, only to write to them. An update IS available, just not in a .tag.gz file format. You have a few ways to update the code you are running before a .tar.gz release is made. Apply the patch above (drupal.org/patch/apply) or checkout from cvs (drupal.org/handbook/cvs).

quicksketch’s picture

Status: Active » Fixed

I made a release for 1.1.2 several weeks ago, but something on drupal.org prevented it from being published to the project page. I went in and manually published the node and it seems to be available now. Sorry for the trouble.

izmeez’s picture

Thank you both for your comments. I have downloaded the 1.1.2 version and will try it out.

Thanks,

Izzy

izmeez’s picture

This version does indeed resolve the critical bug on Drupal 6 that did not allow a user to view their account after over-riding some profile fields.

There is a minor problem in that the version shows as 6.x-1.1-2 and the Drupal updates does not recognize this as the same as 6.x-1.1.2 so it continues to show there is a new version which is not the case.

Thanks very much for this very useful module.

Izzy

quicksketch’s picture

Thanks, my little experiment with trying to use "minor" release numbers didn't go well ultimately, so I'll release a 1.2 version eventually to replace my 1.1.2 version.

Anonymous’s picture

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.