I just applied most of the pending patches to the current dev and fixed some bugs they had. I pretty much needed all the functionality they offer for my current project and everything seems to work like a charme now. This patch includes the following issues:

#502708: Realnames not rebuilt
Just patched.

#487576: Pull RealName from node title (Content Profiles)
RealName now works with the node title when using content profile. I just added one line at the end of content_profile_load_profile() in realname_content_profile.inc:
$account->title = $profile->title;
The title wasn't added to the $account object because $fields only contains cck fields provided by content_fields(). Since the title field is required and therefore always available I just took it from the node object $profile.

#443880: REALNAME module stops panel override from working
Just patched.

#566644: blogtitle and realname are incompatible
Just patched.

#369334: Realname for Privatemsg autocomplete
Just patched.

#462860: "Overwrite user fields in view" variable not setting in admin page
Just patched.

#478746: array_merge problem after realname installation
Just patched.

#391666: Adding table with calculated realnames
After changing the RealName fields in the content profile node they were not updated in the database table. I changed realname_nodeapi() in realname.module to just delete the old realname in the table when the node is inserted, updated or deleted. There is no need to put in the new one right away. This is automatically done on the next request.
db_query('DELETE FROM {realname} WHERE uid = %d', $node->uid);

I also added the missing files realname_plugin_argument_validate_user.inc and realname_handler_filter_user_name.inc to make views work correctly.

Hopefully someone could review this patch and Nancy can apply its changes to the dev. RealName is a great module and I would really appreciate to have a more updated dev.

CommentFileSizeAuthor
#21 realname_content_profile.patch304 bytesDrakeRemory
#4 priv.jpg58.84 KBbarylov
realname.patch19.21 KBDrakeRemory

Comments

wilgrace’s picture

wilgrace commented

Mate, I can't tell you how much this is appreciated - one sweep through the bugs and a patch for all. Just tested it, and the three issues I had (rebuild fail, Views checkbox not accepting and using Profile title) all sorted.

I still get a fail after a certain point in the rebuild, but I think that's because of strange formatting in the Realnames I'm trying to use.

I suggest this is committed - should help a lot of people who've been struggling with issues

DrakeRemory’s picture

DrakeRemory commented

Well, I'm questioning the whole rebuilding process anyway. The way I see it we should just empty the realname table similar to what I did when a profile node is updated and the old entry is just deleted. Next time a realname is needed and not found in the table it is generated on the fly.

wilgrace’s picture

wilgrace commented

Ok, the bugfixes all seem to have taken, except one new issue has arisen: viewing All Users at admin/user/user/list gives me a white screen of death. I have to disable to module to view/edit users

This could be related to one user account which seems to be corrupted - viewing their profile page gives me a memory timeout - so it could be related to that, though deleting the user and profile page doesn't fix it

Apart from that it's working like a dream

UPDATE: this is happening where a user hasn't been given a realname in the table. Assign one manually in the db and the profile page works, and i'd imagine that doing this fr all the users would fix the user list page

An Issue was raised elsewhere for the module to check whether a realname exists, otherwise return username. Has this been applied?

barylov’s picture

barylov commented
StatusFileSize
new priv.jpg58.84 KB

Hi!

Thank You for this patch! everything works great!

But i need help with one thing. When I want to send a private message to someone and i write real name of this person the autocomplete field shows me for example some thing like this : john smith (fox) - after i chose this name from the autocomplite field in the "to field" i can only see username of this person. What should i do to see a realname instead of username? (see the attachment)

sorry for my English ;)

barylov’s picture

barylov commented

and it would be nice to see (in private message autocomplete field) only friends instead of all users :)

DrakeRemory’s picture

DrakeRemory commented

Actually I had something like showing only friends in privatemsg's autocomplete field but I decided to drop it. This should be a feature request for the integration of the friend module you are using.

I aslo wanted to show the realname in the to field. The problem is, that privatemsg takes the username to know who the recipient of the message is. That's the reason why after selecting an autocomplete suggestion the username is put in. What we could do about this is hiding the actual to field and showing the selected users with a little jquery app (like facebook does). But I don't have the time right now to do this although I'm planning to do it in the near future.

barylov’s picture

barylov commented

Thank you for reply.

Do You know how can I integrate user relationship module to show only friends real names in privatemsg to field? When I'm not using the realname module i can see only friends in the privatemsg to field. But when I enable realname module with your patch i can see everybody. It's very important to me have this function working but i'm begginer programmer so i'm not able to do this for my own. I would be very grateful for any help!

nancydru’s picture

nancydru
she/her/hers
Primary language English
Location Boston
commented

So, is this RTBC or "Needs work"?

wilgrace’s picture

wilgrace commented

From my testing, the only issue I've had with the patches above was in checking whethera Realname is created, in which case use Username. Without this, some of the user pages are breaking.

Otherwise it gets my thumbs up - fixes a bunch of issues

nancydru’s picture

nancydru
she/her/hers
Primary language English
Location Boston
commented

Then you should have marked it as "Needs work" so the patch developer knows to fix it. The alternative is to let it get committed then open a new issue. Which you do depends on how serious you think the problem is.

nancydru’s picture

nancydru
she/her/hers
Primary language English
Location Boston
commented
Status: Needs review » Fixed

Committed to 6.x-1.x-dev.

nancydru’s picture

nancydru
she/her/hers
Primary language English
Location Boston
commented

@DrakeRemory: Do you have a CVS account?

I suspect there are other issues you have fixed here; could you possibly browse the issue queue and check, marking fixed any that are, please?

DrakeRemory’s picture

DrakeRemory commented

No I don't have a cvs account. But I'm pretty sure I mentioned all issues in my post.

nancydru’s picture

nancydru
she/her/hers
Primary language English
Location Boston
commented

"mentioned all issues" -- I took a quick scan of the issue queue and saw a few that are probably duplicates or at least similar and may already be fixed by your patch.

If you get a CVS account, I'll give you access.

shawn dearmond’s picture

shawn dearmond commented

Any chance of getting these bug fixes in the 5.x release?

nancydru’s picture

nancydru
she/her/hers
Primary language English
Location Boston
commented

If someone does a patch.

shawn dearmond’s picture

shawn dearmond commented

This patch here is the one I'm most interested in.

http://drupal.org/node/369334#comment-1515162

You had it working for 5.x until the issue was switched to 6.x. Are you planning on committing that patch to 5.x?

nancydru’s picture

nancydru
she/her/hers
Primary language English
Location Boston
commented

I committed my patch even though I was never totally happy with it.

Status: Fixed » Closed (fixed)

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

darktygur-1’s picture

darktygur-1 commented
Status: Closed (fixed) » Needs work

Because of the new line at the end of content_profile_load_profile(), RealName could potentially blast the title of anything a user could've authored. Already it's affecting people's forums. See #606364: Author name instead of subject/title in forum topic list. It's probably also the cause of #608630: Realname break forum module. Can it be backed out, or else a more robust solution implemented?

DrakeRemory’s picture

DrakeRemory commented
StatusFileSize
new realname_content_profile.patch304 bytes

I think the node title was never filtered by check_plain(). I attached a patch please try and report back if this fixes your problem.

wretched sinner - saved by grace’s picture

wretched sinner - saved by grace commented

@DrakeRemory - that doesn't solve my problem with Blog titles. All I get is a nicely HTML escaped title, instead of a non-HTML escaped title.

izmeez’s picture

izmeez commented

subscribing

YK85’s picture

YK85 commented

#369334: Realname for Privatemsg autocomplete
subscribing

darktygur-1’s picture

darktygur-1 commented

@DrakeRemory - I don't think you get it. That $account variable is very often not a user object. It very often is just something the user happens to have authored, and by setting the title like that, you're blasting away titles of random objects.

One of the patches/bugfixes of this issue added that line. Where did it come from, and why is it still there?

DrakeRemory’s picture

DrakeRemory commented

You're right this line should be taken out. It was attempt to get node titles to work as realnames. But this is not really needed since we could just use auto nodetitle and create whatever cck field we need for our name. This functionality should be dropped. Unfortunately we have to wait for Nancy to do this...

robby.smith’s picture

robby.smith commented

subscribing

jthorson’s picture

jthorson commented

Just in case anyone's looking here, we wrote a patch which ensures this routine is only run on user objects and content_profile nodes ...

See http://drupal.org/node/606364#comment-2908082 .

YK85’s picture

YK85 commented
Status: Needs work » Needs review

#21 needs more review or amended?

coderintherye’s picture

coderintherye commented
Status: Needs review » Needs work

I'm not sure, but it looks like to me that the work has moved over to http://drupal.org/node/606364#comment-2908082 and that the current patch in this queue does not properly address the issue.

So setting to needs work, but this may need to be set to fixed or duplicate with a focus to the other issue.

hass’s picture

hass commented
Status: Needs work » Closed (outdated)