Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
I have to say that I am loving the real name module right now, but there is an important issue that I cannot figure out. Real name is working right now in views and the profiles of the users but for some reason it does not seem to be working with user references. I have a content type that display user references as a field, but it displays their username like (tomjones45) rather than (Tom Jones). I was wondering if anyone has encountered this issue or is facing a similar problem?
Comment | File | Size | Author |
---|---|---|---|
#47 | entity-label-1194086-46-widgets.patch | 7.67 KB | yched |
#45 | entity-label-1194086-45-formatteronly.patch | 11.29 KB | yched |
#43 | entity-label-1194086-43.patch | 18.56 KB | yched |
#39 | user-reference-autocomplete_on_realname.patch | 1.11 KB | liquidcms |
#26 | 1194086-user-reference-use-entity-label.patch | 9.08 KB | Dave Reid |
Comments
Comment #1
Dave ReidIt likely means that the code is not using format_username() to display the names of the accounts. Are you using the References module for your user references?
Comment #2
joeschmidt45 CreditAttribution: joeschmidt45 commentedYes, I am using the references module. Is there a way to get user references to use the format_username() function?
Comment #3
oceanos CreditAttribution: oceanos commentedSubscribing. I have the same problem with Real Name when using References module.
Comment #4
Dave ReidThe problem is user_references doesn't use the proper entity_label() function (which calls format_username()) to display a user's name. Best practice when displaying the title of an entity is to always use entity_label().
Comment #5
oceanos CreditAttribution: oceanos commentedThat was fast! Unfortunately, the patch breaks my site when a user reference field is displayed...
Comment #6
dimitris.spachos CreditAttribution: dimitris.spachos commentedSubscribing. The above patch Is it working or not? I manage to get the same result by changing
$query = db_select('user', 'u')
to
$query = db_select('realname', 'u')
in user_reference.module, line 304, but I don't believe it's a proper solution.
Comment #7
mariagwyn CreditAttribution: mariagwyn commentedsub
Comment #8
jason89s CreditAttribution: jason89s commentedI ran into this problem too. I tried the patch in #4 and it broke the site with the WSOD
PHP Fatal error: Call to undefined function user_load_mulitple()
I also tried the hack in #6 and it failed as well. Based on #6 I changed the same function to have the following and this worked for me:Comment #9
jason89s CreditAttribution: jason89s commentedAnd now I found the problem in the patch from #4. It works fine, but the function "user_load_multiple" was spelled wrong.
Comment #10
mariagwyn CreditAttribution: mariagwyn commentedjason: can you correct and upload the patch? I can test...
Maria
Comment #11
jason89s CreditAttribution: jason89s commentedI don't have a good way of creating or using patches right now. I do everything by hand. But you can use the patch from #4 and on line #19 of the patch have it say
+ $accounts = user_load_multiple($new_uids);
instead of
+ $accounts = user_load_mulitple($new_uids);
The change to the patch can be done before its applied.
Comment #12
mariagwyn CreditAttribution: mariagwyn commentedI just applied the patch in #4, with spelling correction from jason89s. Seems to work. I am attaching the patch, but if I do it wrong, be nice b/c I have never attached a patch before.
Comment #13
Dave ReidThat's what I get for not testing my own patch. :)
Comment #14
mariagwyn CreditAttribution: mariagwyn commentedHm. I applied this patch on my live site. While it does indeed show the real name in user reference fields, when I save content with this field present, I get this error:
This is on a name that worked just fine before I edited the content.
In my logs I noticed the following, which match the time I applied the patch: "Guest" generates the following errors:
These errors are generated when a node that has no user reference field is visited.
Comment #15
mariagwyn CreditAttribution: mariagwyn commentedreversed patch, errors disappeared, and some of my pretty real names are gone. I will patch again when something is up.
Comment #16
jason89s CreditAttribution: jason89s commentedI'm experiencing those same errors as well, reversing the patch fixed the errors.
Comment #17
mariagwyn CreditAttribution: mariagwyn commentedDave, any suggestions on the patch? I am happy to test another version.
Comment #18
Dave ReidOk, comprehensive patch to get both user and node references to use entity_label(), entity_uri() and use the proper object load functions. I'm guessing all the odd loading is because user_load() was not cached in Drupal 6, but now since we have the entitytype_load_multiple functions - the results are stored in a static cache.
I tested both the node and user ref fields with all three types of widgets (autocomplete, select, checkboxes) to ensure that there are no XSS security regressions from this patch.
Comment #19
Dave ReidFixed a couple of stray cleanups.
Comment #21
Dave ReidResolved conflict.
Comment #22
Dave ReidComment #23
mariagwyn CreditAttribution: mariagwyn commentedJust applied it to most recent dev. It looks good so far! I will report back if I discover errors. Thank you! I have a whole bunch of professors who are very uptight about how their names appear.
Comment #24
bhauff CreditAttribution: bhauff commentedSubscribing.
Comment #25
Crell CreditAttribution: Crell commented#21 is working fine for me for the default formatter, but not with plain text. With plain text, I get nothing rendered at all. :-(
Comment #26
Dave ReidDang, you beat me to finding that.
Comment #27
Crell CreditAttribution: Crell commented#26 fixed that. Yay Dave!
Comment #28
presleyd CreditAttribution: presleyd commentedWorking great for me.
Comment #29
dgastudio CreditAttribution: dgastudio commentedi can't apply this patch now. it doesnt work neither with beta 3 nor with last dev.
then i want to reference any user, i type for example: admin, but in autocomplete, hist full name is suggested.
Comment #30
KarenS CreditAttribution: KarenS commentedThis patch adds a node_load() or user_load() to every autocomplete. And it introduces node_load_multiple() and user_load_multiple() to every potential reference. We've always tried to avoid the loads because the potential references list can be huge, and each individual referenced entity can also be huge.
This needs some benchmarking to make sure performance is not impaired when there are a massive number of large referenced entities. I know we have the new ways of caching the nodes and users so maybe it's OK, I'd just like to have someone confirm that this change isn't going to degrade performance.
Comment #31
Dave ReidThen, needs review is the more apt status.
Comment #32
KarenS CreditAttribution: KarenS commentedI also want to note that http://drupal.org/project/entityreference uses a similar technique to what is used here -- a direct query of the table that avoids entity_load(). Entity Reference might become the successor to this project as a more generic module that can 'do it all', so you might want to pose this idea on that project as well.
Comment #33
liquidcms CreditAttribution: liquidcms commentedthanks Dave for pointing me to this from here: #1296254: userreference formatter where i did up a quick module last night to do the formatter part of this.. oops.. oh well.
couple things i noticed using this patch instead of my new module: my approach was to add new formatters: http://screencast.com/t/ljyPBu1ytGjE - your patch works great for what i need; but wouldn't it be possible someone might want the actual username?
also, i looked very quickly at the patch and had high hopes for this fixing the autocomplete (plus Karen's comment in #30 makes me think i am missing a config somewhere?) - but it doesn't seem to fix the autocomplete issue (for userref fields; havent yet tried on harder case of fixing noderef autocompletes).
is this still being worked on or should i continue with the autocomplete fix i was going to do in my module and just do it as a patch for References?
Comment #34
Damien Tournoud CreditAttribution: Damien Tournoud commentedIn regard to #32: entityreference doesn't avoid entity_load() at all. We do query the tables directly (because we have no other choice), but we only get a list of ids and call entity_load() on it before using it.
Comment #35
austin_drupal CreditAttribution: austin_drupal commentedHi - I have been using this patch for about a month now and it works great. Can we get the patch committed?
Comment #36
liquidcms CreditAttribution: liquidcms commentedas per my comments in #33 i think this still needs work - or at least perhaps just a definition of the spec for this.
i think the autocomplete needs to complete on the realname - is this not seen as a required part of this?
i can fix the patch to do this if we can agree that it is a necessary part of this (and that it isn't there now - i don't think it is; although code looks like it was modified in that area)
Comment #37
liquidcms CreditAttribution: liquidcms commentedany update on at least the intent of this fix. or is this a bug somewhere else?
as i mentioned above, even though the autocomplete field now displays realnames; it doesn't do search on them.. which still makes this relatively useless for many applications (i guess pretty much all of them)
i guess for now i will assume that is a bug and look at fixing this in references module.
Comment #38
davapiano CreditAttribution: davapiano commentedIt would be great to see a working autocomplete with realname. Any work in progress somewhere?
Comment #39
liquidcms CreditAttribution: liquidcms commentedi submitted this patch on References module a while back: http://drupal.org/node/1234656#comment-5161934
but accidentally posted on wrong project.. as the issue started there. so will post here as well
Comment #41
Alan D. CreditAttribution: Alan D. commentedInterested in regards to the name field module that also has the user name formatting option. This would be impossible to do this via the database as there are 5 columns that could be formatted in an infinite number of combinations once it has applied the given name format.
Comment #42
yched CreditAttribution: yched commentedRegarding the performance impact :
- It's sad that we add that much full entity_loads() just to get the node titles and user names, but that's how D7 works - and that's also partially because D7 has multiple_load and static caching.
- That's pretty much what we forced upon Views as well.
- That's how Entity Reference works already, and we're not trying to be smarter than them...
What worries me more is the fact that autocomplete widgets now display the entity_label() (i.e possibly "Real Name" if realname.module is enabled) in the filled values and in ac suggestions, but still do the matching against the actual node.title or user.name db column. The resulting UI is inconsistent : the values that come pre-populated when editing an existing node or when clicking an ac suggestion are not themselves within the set of matchable strings. No re-entrance.
I don't see any workaround : entity_label() and the associated 'label callbacks' can alter display values all they want at runtime, but doing an autocomplete match still requires querying one given db column somewhere. And ad-hoc patches like #39 are obviously not the solution.
However, "that's how Entity Reference works already, and we're not trying to be smarter than them..." also applies here, and I'm OK committing this to References. This will need a reroll, though, I'll try to take care of that.
Comment #43
yched CreditAttribution: yched commentedHere's an updated patch for the current state of 7.x-2.x-dev.
Comment #44
BrightBoldLike @liquidcms, I'm interested in being able to do the autocomplete search on the RealName. Is that achievable given @yched's points in #42 and if so is it reasonably part of this request or should it be a different issue?
Content administrators (on two different sites) don't necessarily know people's usernames, so if the person has picked something obscure the only way to get them to autocomplete is to look up their username in the People list, (which they may not have the proper permissions to view). So being able to autocomplete on RealName is a high priority for them, but I don't know how technically achievable it is.
If not possible as part of References core, maybe @liquidcms's patch could be converted to a custom module for people who need that particular ad-hoc solution? I'm assuming the reason that's not a good global solution is that is it designed only one specific use case, but there may be other reasons. People who understand the core issues here — what's the best way to proceed for those of us who need this functionality?
Comment #45
yched CreditAttribution: yched commentedActually I'm still pondering on the "widget" side.
For now, committed the attached patch - "formatters" only.
Comment #47
yched CreditAttribution: yched commentedWhich leaves the following part still uncommitted for widgets.
Comment #48
StephenRobinson CreditAttribution: StephenRobinson commentedUpgrade references to 7.x-2.x-dev - 2011-Dec-22, and it does work.
Comment #49
yched CreditAttribution: yched commented@SangersDrupalDude : yup, it now works in userref values displayed by formatters.
The issue is still open for the "widgets" side, which still refer to the core user name - see comments #42 - #45 - #47.
Comment #50
chunglk CreditAttribution: chunglk commentedI have been ported to D7
Userreference Realname
Comment #51
Crell CreditAttribution: Crell commentedJust a note that we've been running this patch on Palantir.net for some time without issue. Admittedly it's not a big site, but it's a data point. This really should get committed eventually...
Comment #52
Alex Andrascu CreditAttribution: Alex Andrascu commentedCrell, can you please let me know which patch is that ? The one in #47 ?
Comment #53
jenlamptonThere's also a patch on #1885380: Real Realname Support.
Comment #54
tassaf CreditAttribution: tassaf commentedJust change the autocomplete path value for the field in the hook_form_alter
And don't forget to give the "Access user profile" permission to the user who will use this field