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.
| Comment | File | Size | Author |
|---|---|---|---|
| profile_privacy_correct_fapi.patch | 1.59 KB | coltrane |
Comments
Comment #1
quicksketchNo 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.
Comment #2
coltraneIt'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.
Comment #3
quicksketchCommitted. Thanks again!
Comment #4
Anonymous (not verified) commentedAutomatically closed -- issue fixed for two weeks with no activity.
Comment #5
izmeez commentedJust 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
Comment #6
izmeez commentedI 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
Comment #7
coltraneThis 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
Comment #8
izmeez commentedThanks 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
Comment #9
coltraneNope, 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).
Comment #10
quicksketchI 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.
Comment #11
izmeez commentedThank you both for your comments. I have downloaded the 1.1.2 version and will try it out.
Thanks,
Izzy
Comment #12
izmeez commentedThis 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
Comment #13
quicksketchThanks, 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.
Comment #14
Anonymous (not verified) commentedAutomatically closed -- issue fixed for two weeks with no activity.