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

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

dawehner’s picture

Status: Active » Fixed

This issue is already fixed in 7.x-3.x-dev, but please think about it when you update.

Status: Fixed » Closed (fixed)

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

boabjohn’s picture

Status: Closed (fixed) » Active
FileSize
20.18 KB

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

boabjohn’s picture

Version: 7.x-3.3 » 7.x-3.x-dev

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.

dshields’s picture

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!

mojiro’s picture

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;

ericpugh’s picture

#6 Worked for me. Thanks mojiro.

JvE’s picture

Status: Active » Needs review
FileSize
1.47 KB

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.

Status: Needs review » Needs work

The last submitted patch, views-user_name-1609088-8.patch, failed testing.

JvE’s picture

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.

bvanmeurs’s picture

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)

  function 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;
  }

Jawi’s picture

worked for me

nlisgo’s picture

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.

JvE’s picture

FileSize
34.59 KB

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:

username_options.gif

jasom’s picture

FileSize
5.46 KB

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.

johnv’s picture

Title: Undefined index: uid in views_handler_field->get_value() » Undefined index: uid in views_handler_field->get_value() (line 375 of views_handler_field.inc)
Status: Active » Needs review
FileSize
1.86 KB

I agree with the analysis in #8, and the slogan in #10:

It all seems to come down to the inclusion of the 'uid' or not.

(#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.

JvE’s picture

Status: Needs review » Needs work
Issue tags: +Needs tests

This needs test coverage.

johnv’s picture

@JvE, by including the patch from #10?

JvE’s picture

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.

drumm’s picture

I can confirm we had this happen on the api/association_members.json path 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.

johnv’s picture

Status: Needs work » Needs review
jasom’s picture

#17 error disappear

Rob C’s picture

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'.

boregar’s picture

Version: 7.x-3.x-dev » 7.x-3.7

Hi, same problem when creating a view listing users: the problem appears only if I add the language field and I uncheck the Link this field to its user checkbox.

JvE’s picture

Version: 7.x-3.7 » 7.x-3.x-dev
Status: Needs review » Needs work

This still needs test coverage.

@hillmore: Under "More" enable "Use formatted username" or "Overwrite the value to display for anonymous users" see #10 and #15

boregar’s picture

FileSize
59.66 KB

@JvE: this parameter is not present in the configuration window for the Language field. The only parameter that appears in the "More" section is "Administrative Title" (see capture below).

capture

matthias_mo’s picture

I made a patch out of comment #6

jasom’s picture

#28 worked for me

ubuntuslave’s picture

True, the patch given by #28 worked for me, too!

Thanks!

Carlos

rar’s picture

I found this page independently and had implemented a solution similar to comment #6. Just commenting here that this issue pops up even when uid was excluded from display in a view and solved as noted above.

ayalon’s picture

I also had the language field and unchecked the Link option.

Patch #28 works and fixes the problem

ayalon’s picture

Issue summary: View changes
Status: Needs work » Reviewed & tested by the community
johnv’s picture

Patch #28 might work, but merely removes the symptom.
Please also consider patch #17, which removes the root cause.

JvE’s picture

Status: Reviewed & tested by the community » Needs work

As stated before, that patch only hides the error, it does not solve the problem.
#17 may solve the issue but lacks test coverage.

alessandro rancati’s picture

#17 worked for me

alessandro rancati’s picture

It actually removed the notice AND the link to the user page.

jcdarocha’s picture

#6 Worked for me. Thanks so much mojiro.
Was stuck with this ID field, mean time all others fields were working well.

Tried to change the "Link this field to its user" and "Use formatted username" as it was written first, but nothing happened...

Thx.
JC

bobojo’s picture

So... what's wrong with the patch in #17? It gets rid of the error, and doesn't seem to harm performance or anything. I don't know nearly enough about how Views operates to understand all the underlying theory involved, though. I'd love to get deeper into it, but I just don't have time atm.

marleo’s picture

Workaround: add "User: Name" twice.
Leave the first one default but exclude from display.
Rewrite the second one as required.

Status: Needs work » Needs review
JvE’s picture

Status: Needs review » Needs work

As stated before, patch #28 only hides the error, it does not solve the problem.
#17 may solve the issue but lacks test coverage.

dchalmer’s picture

Re. comment #40; Thank you, this worked for me, but only if I also ticked "Use formatted username" in the More fieldset.

To get the username hyperlinked, if it helps anyone:

  • add the User: Uid field into the list of fields in the View, with "Exclude from display" ticked;
  • Rewrite results > "Output this field as a link" ticked;
  • Link path = user/[uid]

...One use-case is when you have disabled username truncation: see https://api.drupal.org/comment/57303#comment-57303

I know this is a workaround, but I suspect there are others who would prefer a workaround to patching Views.

robcarr’s picture

klausi’s picture

Status: Needs work » Needs review
Issue tags: -Needs tests
FileSize
5.7 KB

Here is the patch from #17 including a test case.

ptmkenny’s picture

The patch in #45 fixes the issue for me on my site, but I don't have the technical chops to review the whole patch.

johnv’s picture

I re-attached the patch from #45, only to try to trigger the testbot - the test is waiting for 3 months now.

joelpittet’s picture

Status: Needs review » Reviewed & tested by the community

Thank you this works well. The uid is working with things like entityform_uid and relationships.

dqd’s picture

# latest Drupal 7.x with latest views 7.x installed

git apply -v views-username-notice-1609088-45_0.patch
Checking patch modules/user/views_handler_field_user.inc...
Checking patch modules/user/views_handler_field_user_language.inc...
Checking patch modules/user/views_handler_field_user_name.inc...
Checking patch tests/user/views_handler_field_user_name.test...
Applied patch modules/user/views_handler_field_user.inc cleanly.
Applied patch modules/user/views_handler_field_user_language.inc cleanly.
Applied patch modules/user/views_handler_field_user_name.inc cleanly.
Applied patch tests/user/views_handler_field_user_name.test cleanly.

Undefinded index error disappears. I can confirm the patch works so far and I can't find any drawbacks yet after some days testing.

JvE’s picture

Status: Reviewed & tested by the community » Needs work

Patch makes anonymous username disappear.

Link this field to its user: off
Use formatted username: off
Overwrite the value to display for anonymous users: off

Expected result: <span>Anonymous</span>
Actual result: <span></span>

joelpittet’s picture

@JvE I don't see anything in the patch that does this... Isn't the formatted username supposed to be on for that to work?

JvE’s picture

Without the patch you get a notice, with the patch you get an empty string. Both are not expected.

maxplus’s picture

OK Thanks, testing #47.
I only have the uid field in my view, not the username field.

RoSk0’s picture

Status: Needs work » Reviewed & tested by the community

I do not agree with #50 because patch doesn't change behavior of the the module in relation to anonymous user. If "Use formatted username" is checked you will see "Anonymous" as expected. Without this checkbox there is nothing to produce so empty string is expected result.
Patch applies cleanly and getting notices off.
Tested in multiple views with similar configuration on Views 3.14 and Drupal 7.50.

Can we please have this patch committed.

Kingdutch’s picture

Patch applies cleanly and works with views 3.15 en Drupal 7.52

MegaChriz’s picture

Tested the scenario in #50 without the patch applied for a node based view for field "User: Name" and a relationship "Content: Author". Got an empty string for anonymous users. So that behavior is not introduced by the patch.

With the patch applied, the error message "Undefined index: uid" is gone.
RTBC++

vistree’s picture

Patch in #47 works for me, too. Is this something which can be commited?

dqd’s picture

Well, as stated already @ #49: yes it can. :)

pietrocap’s picture

Hi, I get again the same error with the latest .dev.

indigoxela’s picture

Unfortunately patch #47 doesn't apply anymore.

The problem persists: "Undefined index: uid".

What exactly es needed to get this bugfix into dev?
It was RTBC already, but there was no real progress.

@johnv or @klausi - could one of you reroll the patch, please?

joelpittet’s picture

Status: Reviewed & tested by the community » Needs work
Issue tags: +Needs reroll
rpayanm’s picture

Status: Needs work » Needs review
Issue tags: -Needs reroll
FileSize
5.54 KB
joelpittet’s picture

Status: Needs review » Reviewed & tested by the community

The reroll looks great, thanks @rpayanm

  • dawehner committed 0a26967 on 7.x-3.x authored by rpayanm
    Issue #1609088 by JvE, johnv, rpayanm, matthias_mo, klausi, jasom,...
dawehner’s picture

Status: Reviewed & tested by the community » Fixed

Thank you for the work and especially testing! Committed and pushed to 7.x-3.x

dqd’s picture

@dawehner++

Status: Fixed » Closed (fixed)

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

DamienMcKenna’s picture

RoSk0’s picture

FileSize
5.5 KB

Re-roll of #62 on top 3.21 version.