Okay, I'm having a bit of trouble with this view. I've got a menu tab on the user's My Account page, with a view of the content they've created. My difficulty is in making the title of that page "Username" instead of a static "My content".
I figure that besides the User:Uid argument I also need a User:Name argument. The page title would thus be "%2". Since the argument won't actually be present, I need to provide a default argument. This may not be the best way of returning the user's name (the user whose My Account page is being viewed), but it's what I've got as the PHP to return a default argument:
$myuser = arg(1);
$result = db_query('SELECT * FROM {users} WHERE (uid = "' .$myuser. '")');
$usr = db_fetch_object($result);
return $usr->name;
However, the query that Views shows being executed is
SELECT node.nid AS nid,
node.title AS node_title,
node.created AS node_created
FROM 7dp_node node
INNER JOIN 7dp_users users ON node.uid = users.uid
WHERE (node.type in ('product')) AND (users.uid = 1) AND (users.name = 'n')
ORDER BY node_title ASC
where n in "(users.name = 'n')" is a UID -- not the user's name.
Now, I could have done something wrong. But I'm marking this as a bug, since if my PHP is simply
return "administrator";
the query being executed includes "(users.name = '1')". I get no records returned, although %2 returns "administrator" for the title. I'm no expert, but it seems to me that the search for users.name should be for "administrator", not "1".
I'm using a User validator and accepting either "Only allow string usernames" or "Allow both numeric UIDs and string usernames".
If this isn't a bug, though, please tell me where I've gone wrong.
Comment | File | Size | Author |
---|---|---|---|
#6 | 744468.patch | 1.77 KB | eporama |
#2 | 744468.patch | 2.17 KB | eporama |
Comments
Comment #1
mrtoner CreditAttribution: mrtoner commentedThis appears to be a duplicate of another issue that's nearly a year old, #406666: 'User: Name' argument generating a wrong query?. I'm going to mark that one as the duplicate, since it was never resolved and mine is more recent -- and perhaps it will get more attention.
(Merlin, you missed the real problem in that issue, the fact that the query appears to have been built incorrectly. The patch there was a just a workaround; the issue needs a fix.)
Based on the OP's finding of a problem in the validator, I was actually able to work around my issue by changing the validator for User:Name to PHP:
Not sure why this works, but now my user/%/content pages both list the appropriate nodes and are titled with the user's name.
Would appreciate feedback on the bug, though.
Comment #2
eporama CreditAttribution: eporama commentedThe validator seems to be assuming that you're using User: UID as the argument. Even when you do set User: UID as the argument, you can still set it to accept numeric (uid) or string (username) for the parameter passed in. If you're using User: Name as the argument and validating as a valid User, you can achieve the same functionality by switching to User: UID.
However, if you wanted to have the argument of User: E-mail (or any other User argument field) you can't validate as a valid User since currently
validate_argument()
in views_plugin_argument_validate_user.inc is hard coded to "name" and "uid" fields and always returns uid.Here's a patch that validates against the field of
$this->argument->options['field']
which is the argument field (e.g., User: E-mail => mail) and returns$this->argument->argument = $account->{$arg_fld}
(where $arg_field => $this->argument->options['field']).I agree with merlin's comment that if possible, you should use User: UID as this is the most performant, but it does seem odd that it would only work for User: UID. This patch shouldn't change the performance of using User: UID as the field in this case would be uid which is what the original functionality worked with anyway.
Comment #3
eporama CreditAttribution: eporama commentedBy the way, setting the validator to simply
return TRUE;
means that you're not actually validating the argument. You're just passing everything that comes in. The validator returns false when it fails, but sets some variables and then returns TRUE if it passes.Comment #4
dawehnerUpdate status. Please mark issues and needs review, then people will look at it :)
Comment #5
dawehnerDon't use such shortcut names
Why do we need a tab here? This code looks broken.
Powered by Dreditor.
Comment #6
eporama CreditAttribution: eporama commentedThanks dereine! Still fairly new to providing patches, so appreciate the help. I rerolled not using the shortcut variable and fixed the formatting.
I also redid the patch from the top of the views directory, is that better or not necessary?
Powered by Dreditor.
Comment #7
dawehnerJust in general this issue would be worth to be simpletested :)
Comment #8
eporama CreditAttribution: eporama commentedAnd since I'm also new to simpletesting... My plan is to write a new test function for viewsArgumentValidatorTest in the views_argument_validator.test file. It doesn't appear that there is a test for Validator: User at all, so first to write that and then can check to see whether or not my patch should introduce any new test requirements, but at least doesn't break the test.
Just want to make sure I'm not going about this all wrong... Thanks
Comment #9
eporama CreditAttribution: eporama commentedwell, glad I wrote the simpletest above... Cause this patch causes it to fail ;-)
Turns out that with my patch, we're assuming that the argument has user information (name, mail, etc.) but the test is written against a "Global: null" argument. Guess you could have a null argument and still want to validate it as a User (that's what the test does).
However this patch calls
$account->{$this->argument->options['field']}
which produces$account->null
and that get's warnings and then some of the tests actually fail. So until I sort that out, setting back to needs work.Comment #10
webfunkin CreditAttribution: webfunkin commentedany progress here?
Comment #11
dgsiegel CreditAttribution: dgsiegel commentedsubscribe
Comment #12
MustangGB CreditAttribution: MustangGB commented