Closed (fixed)
Project:
Drupal core
Version:
7.x-dev
Component:
user.module
Priority:
Normal
Category:
Bug report
Assigned:
Issue tags:
Reporter:
Created:
10 Nov 2010 at 02:05 UTC
Updated:
3 Jan 2014 at 02:41 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
dave reidComment #2
BenK commentedSubscribing...
Comment #3
dave reidThis is a blocker for both #125640: Profile tokens and #691078: Field tokens in token module.
Comment #4
dave reidComment #5
dave reidRevised patch that also fixes that format_username() should always be sanitized with check_plain(), since that's exactly what it says in its doc page.
Comment #7
dave reidError with what parameter was passed to format_username().
Comment #8
fagoHm, the question is what would one expect when using the [user:name] token - the name the user has input in the user name field or the formatted user name, which may have been altered by modules. I think, it should be the first, while I agree the formatted user name should be available somewhere too, e.g. as [user].
Comment #9
fago@loading the full-account object:
Definitively, passing half-baken objects around is evil.
Comment #10
dave reid@fago As per #9 care to RTBC? :)
Comment #11
moshe weitzman commentedLooks good. Thx.
Comment #12
fagoWith that patch, how would I get just the user-name as entered by users if a module implements hook_username_alter()?
Comment #13
dave reidSame as before the patch. This had no change to the [user:name] token, just to how it was tested. Realname for D7 adds a [user:name-raw] token if it doesn't already exist.
Comment #14
webchickHm. Does this need to be benchmarked? How often is this going to get called?
Comment #15
dave reidIt's only used when people use [current-user:*] tokens and performing token replacement, so not exactly too often.
Comment #16
dave reidSo in other words, when this happens in core, it's not on every page, and it's only when responding to certain events. Marking back to RTBC.
Comment #17
moshe weitzman commentedWell, we statically cache users so user_load() would typically run once and even then would be called only if user specifically requested this token. You can imagine scenarios like a mail merge where we load many users but those are not going to be performance sensitive operations. I don't think we have a performance concern here.
Comment #18
webchickOkie doke then.
Committed to HEAD. Thanks!