Problem: User view page [?q=user/id] does not display correctly, with fields either missing, or "Array" being displayed.
This is primarily due to the "category" key being overwritten in user_view(). This is mainly triggered only when the blog module is enabled. The blog module also returns an incorrectly formatted array in hook_user.
This patch:
-Merges the category array rather than overwrite existing keys in user_view.
-Fixes blog module hook_user() output.
-Also adds a "last_seen" field to the page - this IMO is a lot more useful and universally useful than the join date of the user.
-Fixes a typo or two.
This page also outputs each field as a form :/ - I have no idea why, but this seems to be happening in the profile module as well. I've left it in for now, but if there's no valid reason for this, I'll be more than happy to get rid of the icky stuff.
Thanks
-K
P.S This is a dupe moved here for clarity.
| Comment | File | Size | Author |
|---|---|---|---|
| #6 | user_view_0.patch | 2.82 KB | Zen |
| #2 | 45444_user_profile.patch | 3.18 KB | Bèr Kessels |
| user_view.patch | 3.08 KB | Zen |
Comments
Comment #1
jakeg commented+1
Fixes the bug for me. Haven't really looked at code style etc though.
Comment #2
Bèr Kessels commentedTested and it works as advertised.
However, a -1 on the extra 'last seen'. Personally I am already no fan of the member since, but adding this last seen thing is even worse. Here is why:
A lot of sites do want to show some sort of member profile.
They offer private fields, public fields etc.
but *nowhere* is advertised that they will have to show how long they are member. *let alone when they were last online*.
this, IMO is a privacy infringement on a lot of (types of) sites. Hence I rerolled the patch, this time without the last seen part.
We could consider in uture to make such history data more verbous, but then it has to be:
* well thought out
* optional for the whole site
* optional per user (if the whole site allows it to be optional)
Bèr
Comment #3
DexterMilo commentedI get the following errors after applying patch either patch:
* warning: array_merge() [function.array-merge]: Argument #1 is not an array in /home/.bastion/rylacrit/montrosehealth.com/modules/user.module on line 1340.
* warning: array_merge() [function.array-merge]: Argument #1 is not an array in /home/.bastion/rylacrit/montrosehealth.com/modules/user.module on line 1340.
* warning: array_merge() [function.array-merge]: Argument #1 is not an array in /home/.bastion/rylacrit/montrosehealth.com/modules/user.module on line 1340.
* warning: implode() [function.implode]: Bad arguments. in /home/.bastion/rylacrit/montrosehealth.com/modules/user.module on line 646.
Comment #4
jakeg commentedWorks for me (both patches, latest getting rid of the 'last scene' bit)
Comment #5
jakeg commentedThe latter patch should be committed, as this is a bug fix not an extra feature (which may have privacy concerns) patch.
Comment #6
Zen commentedHi :)
@Bèr: Fair enough :) I was operating on the principle of "In for a penny, in for a pound" :) I'm going to be adding a patch for the contact module to allow the user the option of not sending his e-mail address with his personal contact form messages - I'll try to incorporate this in (with appropriate controls) along with that.
@dextermilo: Thanks for reviewing - what version of PHP did you test this on? Please test again with the attached patch.
Can you guys also please comment on the usage of the form API for layout? Right now, if there are 10 fields on a profile page, there are also 10 dummy form blocks that are piggy-backed on them? Is there a reason for this?
Cheers,
-K
Comment #7
ax commentedthis very issue is a dupe of http://drupal.org/node/40200, which has a "ready to be committed" ...
Comment #8
ax commented... and solves some more issues.
Comment #9
Zen commentedJust great :/
Sorry about that mate - I did do a quick search - not a terribly efficient one apparently.
Thanks for the heads-up. I'll continue this over on the other thread. I'm incorporating the form removals as well.
Cheers :)
-K