Posted by mettasoul on May 30, 2012 at 10:02pm
21 followers
| Project: | Views |
| Version: | 7.x-3.x-dev |
| Component: | user data |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs review |
| Issue tags: | Needs tests |
Issue Summary
Undefined index: uid in views_handler_field->get_value() (line 360 of ...\views\handlers\views_handler_field.inc).
This error can be reproduced by creating a user view and deselecting "Link this field to its user" and "Use formatted username" in the user name field settings.
Also "Use formatted username" only works (minus this error) when both are deselected. It would be nice if you could still link the raw data to the user by only deselecting "Use formatted username" and keeping "Link this field to its user" selected.
Thanks for all your hard work
Comments
#1
This issue is already fixed in 7.x-3.x-dev, but please think about it when you update.
#2
Automatically closed -- issue fixed for 2 weeks with no activity.
#3
Hi guys,
Not sure if this is actually fixed? Just updated to latest dev (14 June), cleared caches etc, but still get these errors (one or two errors for each person selected by the view):
Notice: Undefined index: uid in views_handler_field->get_value() (line 375 of /home/xxxx/prod/htdocs/drupal/sites/all/modules/views/handlers/views_handler_field.inc).The error first declared itself on line 360, per this issue. After update, the line shifted to 375.
Attached is the view we're working on.
It may come from some contortion around our attempt to provide a link to the user's profile page.
1. We require plain name forms for our usernames: Joe Smith instead of Assoc Prof Joe Smith.
2. But on the various places where Joe is displayed on the site, we need a *displayname* form, which is provided by a CCK field on the user entity.
3. When constructing our View, we want to display the DisplayName and *link this to the user's profile page*
But how?
4. So we include the core username field as the first field, exclude it from display, and then rewrite the DisplayName field to provide the link to the profile page.
This usually works...though it feels inelegant...
However in these latest Views versions we're getting the Notices above.
Advice, career counselling, etc happily received!
JB
#4
Just an update on this: when we take off the ReWrite rule from DisplayName (ie, the [User: Name] field is not being displayed OR used in a rewrite), the notice still presents .
When we remove the field [User: Name] from the display entirely, the notice is silenced.
So: something is amiss with the UID and the simple act of adding the [User: Name] field to the Views usual User views default.
#5
I'm experiencing the same error on a view that displays only the username.
Everything works fine until I uncheck "Link this field to its user" and "Use formatted username".
Any help on this would be great!
#6
In order to get rid of the message I replace the line 375 with
$alias = isset($field) && isset($this->aliases[$field]) ? $this->aliases[$field] : $this->field_alias;
#7
#6 Worked for me. Thanks mojiro.
#8
Ran into this bug too.
It occurs when you add a user_name field which is not linked to the user, formatted or having anonymous rewritten.
views_handler_field_user->render() always calls ->render_link() regardless of whether or not the link_to_user option is enabled and the choice of making a link or not is done on the views_handler_field_user->render_link() function.
views_handler_field_user_name extends views_handler_field_user and overrides render_link() with a function that incorrectly assumes the 'uid' field has been added to the handler.
In reality the 'uid' field is only added:
- by views_handler_field_user if the option 'link_to_user' is enabled
- by views_handler_field_user_name if the 'overwrite_anonymous' or 'format_username' options are enabled.
Patch is attached, please review.
#9
The last submitted patch, views-user_name-1609088-8.patch, failed testing.
#10
Oh boy, those tests need work too :(
Here's a patch that provides a view to use in testing ('link_to_user' set to 0).
Unfortunately this brings to light a big flaw in the way that the username display handler test is written.
The options 'link_to_user', 'overwrite_anonymous' and 'format_username' have an effect on the query that views executes, but in the testcase, the view is only executed once and the effect of the options on the display only is tested. Therefore either this test "viewsHandlerFieldUserNameTest" needs to be rewritten to take changes to the query caused by the options into account, or the options should be changed to have no effect on the query.
It all seems to come down to the inclusion of the 'uid' or not.
The tests and the handler assume it is always included so maybe we should always include uid.
And for some reason the test incorrectly assumes that the name for user0 will be 'Anonymous' rather than '' when none of the options are enabled.
It looks like the 'format_username' option was added after the last update to the tests and it used to be on by default.
This is the current unpatched result of all the combinations of options for both UID 0 (account->name = '') and UID 1 (account->name = 'username').
options['anonymous_text'] was set to 'overwritten'.
UID link_to_user overwrite_anonymous format_username Result:0 FALSE FALSE FALSE NOTICE: Undefined index: uid
0 FALSE FALSE TRUE 'Anonymous'
0 FALSE TRUE FALSE 'overwritten'
0 FALSE TRUE TRUE 'overwritten'
0 TRUE FALSE FALSE '<span class="username" xml:lang="" typeof="sioc:UserAccount" property="foaf:name">Anonymous (not verified)</span>'
0 TRUE FALSE TRUE '<span class="username" xml:lang="" typeof="sioc:UserAccount" property="foaf:name">Anonymous (not verified)</span>'
0 TRUE TRUE FALSE 'overwritten'
0 TRUE TRUE TRUE 'overwritten'
1 FALSE FALSE FALSE NOTICE: Undefined index: uid
1 FALSE FALSE TRUE 'username'
1 FALSE TRUE FALSE 'username'
1 FALSE TRUE TRUE 'username'
1 TRUE FALSE FALSE '<a href="/user/1" title="View user profile." class="username" xml:lang="" about="/user/1" typeof="sioc:UserAccount" property="foaf:name">username</a>'
1 TRUE FALSE TRUE '<a href="/user/1" title="View user profile." class="username" xml:lang="" about="/user/1" typeof="sioc:UserAccount" property="foaf:name">username</a>'
1 TRUE TRUE FALSE '<a href="/user/1" title="View user profile." class="username" xml:lang="" about="/user/1" typeof="sioc:UserAccount" property="foaf:name">username</a>'
1 TRUE TRUE TRUE '<a href="/user/1" title="View user profile." class="username" xml:lang="" about="/user/1" typeof="sioc:UserAccount" property="foaf:name">username</a>'
The fix from #6 changes the results to '' and 'username' for uid0 and uid1 respectively. But it also hides all other bugs where a handler is incorrectly assuming a field is present.
Changing views_handler_field_user_name to always include the uid field also fixes the bug, but then the test fails because it expects 'Anonymous' when all options are false, but gets ''.
I can write a new testcase that test for the actual values we get now (without the error of course) but I am uncertain if these actual current results match up withe the really expected results.
I mean: should 'link_to_user' really force a around anonymous? Should overwrite_anonymous really override that? Etc..
Then there is also the way that views_handler_field_user_name implements 'link_to_user'. It calls theme_username() on the account. But what if the theme overrides that to output no link?
The parent views_handler_field_user uses $this->options['alter']['make_link'] = TRUE;
Advice on how best to proceed with this issue is appreciated.
#11
Caused by: #1252538: Pass full user object to format_username()
Related:
#1445694: Test views_handler_field_user_name
#1445404: Views: user name raw display is truncated
#368234: Add a textfield for the value to print for anonymous users in views_handler_field_user_name
#12
When the uid and name are null (which may occur when using a view that has a left join on a user table), I get 'Warning: array_flip(): Can only flip STRING and INTEGER values! in DrupalDefaultEntityController->load() (line 178 of /home/adrupal/www/includes/entity.inc).'.
This is due to the fact that the null value is returned when the user table record does not exist (when the user is either deleted or was anonymous). This shortcoming can be fixed by replacing 'null' by 0 for uid:
(Location: views_handler_field_user_name.inc)
<?phpfunction render_link($data, $values) {
$account = new stdClass();
$account->uid = $this->get_value($values, 'uid');
$account->name = $this->get_value($values);
if ($account->uid === NULL) {
$account->uid = 0;
}
if (!empty($this->options['link_to_user']) || !empty($this->options['overwrite_anonymous'])) {
if (!empty($this->options['overwrite_anonymous']) && !$account->uid) {
// This is an anonymous user, and we're overriting the text.
return check_plain($this->options['anonymous_text']);
}
elseif (!empty($this->options['link_to_user'])) {
$account->name = $this->get_value($values);
return theme('username', array('account' => $account));
}
}
// If we want a formatted username, do that.
if (!empty($this->options['format_username'])) {
return format_username($account);
}
// Otherwise, there's no special handling, so return the data directly.
return $data;
}
?>
#13
worked for me
#14
I experience this issue with views-7.x-3.5
#6 worked for me and I was apply to introduce it without hacking views but just extending the views_handler_field_user_name class by creating my own custom views field handler.
hook_views_data_alter to the rescue. Thanks for the help. But this needs to be fixed.
#15
In order to fix this we need to know the desired result for each case in the table in #10
Then I could write a proper test and fix.
For now, as you can see from that table, the easiest workaround is to enable the format_username option.
I've added a picture to clarify where to find the three options affecting this issue:
#16
Hello,
I just wanna report this error:
Notice: Undefined index: uid in views_handler_field->get_value() (riadok 375 from ../sites/all/modules/views/handlers/views_handler_field.inc).- Im using 7.x-3.5 views.
Views description:
I'm using view with relationship "author" and context "NID" to see info about node author: name, picture, member since, last access. Everything goes fine but when I add user language there is error above.
#6 solved problem.
#17
I agree with the analysis in #8, and the slogan in #10:
(#6 only removes the symptom, not the root cause.)
However IMO the solution is another, since the error is not only in user_name:
User: Uid does NOT generate an error, regardless of settings.
User: Language generates an error, but only if 'Link this field to its user' is NOT set.
User: Name generates an error, but only if 'Link this field to its user' is NOT set.
Other User:... fields do not have this error, since they do not derive from User: Uid.
Why don't we ALWAYS add the Uid in the query of the base user handler? This adds no additional cost to the query, since you will read the 'users' table anyway.
After that, we need to make sure the subclasses always implement the parent::init() function.
- User: Language is OK, since it does not implement it itself;
- User: Name is OK, since it calls parent::init() already;
- Other views_handler_field_user_* are not subclases and set 'Uid' themselves.
Attached patch implements this. It removes duplicated functions, too.
#18
This needs test coverage.
#19
@JvE, by including the patch from #10?
#20
That would be a start. It'll fail though because with the patch the uid0 username is '' while the test expects 'Anonymous'.
I still don't know what it should be, otherwise I'd do a proper rewrite of the whole views_user test set.
#21
I can confirm we had this happen on the
api/association_members.jsonpath in http://drupalcode.org/project/association_drupalorg.git/blob/89439d20f25.... I'm working around it with settings as described in #10. I did briefly try the patch and it did remove the notices, but I don't know enough about the views internals here to credibly comment on the change.#22
#17: views_1609088_17_undefined_index_uid.patch queued for re-testing.
#23
#17 error disappear
#24
I get the same error for a 'nid' after i've installed the views_php module. Comment #6 also seems to get rid of the error message in my case, so i'm not sure where to start a new issue about this, and i wonder if something similar to the current patch (wich only seems to address the issue for 'uid') could be done for the 'nid'.