Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
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
Comment | File | Size | Author |
---|---|---|---|
#69 | views-1609088-3.21.patch | 5.5 KB | RoSk0 |
#62 | 1609088-62.patch | 5.54 KB | rpayanm |
| |||
#47 | views-username-notice-1609088-45.patch | 5.7 KB | johnv |
#45 | views-username-notice-1609088-45.patch | 5.7 KB | klausi |
#27 | Capture.JPG | 59.66 KB | boregar |
Comments
Comment #1
dawehnerThis issue is already fixed in 7.x-3.x-dev, but please think about it when you update.
Comment #3
boabjohn CreditAttribution: boabjohn commentedHi 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):
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
Comment #4
boabjohn CreditAttribution: boabjohn commentedJust 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.
Comment #5
dshields CreditAttribution: dshields commentedI'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!
Comment #6
mojiro CreditAttribution: mojiro commentedIn 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;
Comment #7
ericpugh#6 Worked for me. Thanks mojiro.
Comment #8
JvE CreditAttribution: JvE commentedRan 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.
Comment #10
JvE CreditAttribution: JvE commentedOh 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'.
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.
Comment #11
JvE CreditAttribution: JvE commentedCaused 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
Comment #12
bvanmeurs CreditAttribution: bvanmeurs commentedWhen 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)
Comment #13
Jawi CreditAttribution: Jawi commentedworked for me
Comment #14
nlisgo CreditAttribution: nlisgo commentedI 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.
Comment #15
JvE CreditAttribution: JvE commentedIn 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:
Comment #16
jasom CreditAttribution: jasom commentedHello,
I just wanna report this error:
- 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.
Comment #17
johnvI 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.
Comment #18
JvE CreditAttribution: JvE commentedThis needs test coverage.
Comment #19
johnv@JvE, by including the patch from #10?
Comment #20
JvE CreditAttribution: JvE commentedThat 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.
Comment #21
drummI 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.Comment #22
johnv#17: views_1609088_17_undefined_index_uid.patch queued for re-testing.
Comment #23
jasom CreditAttribution: jasom commented#17 error disappear
Comment #24
Rob C CreditAttribution: Rob C commentedI 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'.
Comment #25
boregar CreditAttribution: boregar commentedHi, 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.
Comment #26
JvE CreditAttribution: JvE commentedThis still needs test coverage.
@hillmore: Under "More" enable "Use formatted username" or "Overwrite the value to display for anonymous users" see #10 and #15
Comment #27
boregar CreditAttribution: boregar commented@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).
Comment #28
matthias_mo CreditAttribution: matthias_mo commentedI made a patch out of comment #6
Comment #29
jasom CreditAttribution: jasom commented#28 worked for me
Comment #30
ubuntuslave CreditAttribution: ubuntuslave commentedTrue, the patch given by #28 worked for me, too!
Thanks!
Carlos
Comment #31
rar CreditAttribution: rar commentedI 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.
Comment #32
ayalon CreditAttribution: ayalon commentedI also had the language field and unchecked the Link option.
Patch #28 works and fixes the problem
Comment #33
ayalon CreditAttribution: ayalon commentedComment #34
johnvPatch #28 might work, but merely removes the symptom.
Please also consider patch #17, which removes the root cause.
Comment #35
JvE CreditAttribution: JvE commentedAs stated before, that patch only hides the error, it does not solve the problem.
#17 may solve the issue but lacks test coverage.
Comment #36
alessandro rancati CreditAttribution: alessandro rancati commented#17 worked for me
Comment #37
alessandro rancati CreditAttribution: alessandro rancati commentedIt actually removed the notice AND the link to the user page.
Comment #38
jcdarocha CreditAttribution: jcdarocha commented#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
Comment #39
bobojo CreditAttribution: bobojo commentedSo... 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.
Comment #40
marleo CreditAttribution: marleo commentedWorkaround: add "User: Name" twice.
Leave the first one default but exclude from display.
Rewrite the second one as required.
Comment #42
JvE CreditAttribution: JvE at One Shoe commentedAs stated before, patch #28 only hides the error, it does not solve the problem.
#17 may solve the issue but lacks test coverage.
Comment #43
dchalmer CreditAttribution: dchalmer commentedRe. 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:
...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.
Comment #44
robcarr#40 doesn't work for me - related to a Real Name issue - see #1239478-91: How to display a user's username (not real name) in Views once RealName is enabled?
Comment #45
klausiHere is the patch from #17 including a test case.
Comment #46
ptmkenny CreditAttribution: ptmkenny commentedThe patch in #45 fixes the issue for me on my site, but I don't have the technical chops to review the whole patch.
Comment #47
johnvI re-attached the patch from #45, only to try to trigger the testbot - the test is waiting for 3 months now.
Comment #48
joelpittetThank you this works well. The uid is working with things like entityform_uid and relationships.
Comment #49
dqdUndefinded index error disappears. I can confirm the patch works so far and I can't find any drawbacks yet after some days testing.
Comment #50
JvE CreditAttribution: JvE at One Shoe commentedPatch 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>
Comment #51
joelpittet@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?
Comment #52
JvE CreditAttribution: JvE at One Shoe commentedWithout the patch you get a notice, with the patch you get an empty string. Both are not expected.
Comment #53
maxplus CreditAttribution: maxplus commentedOK Thanks, testing #47.
I only have the uid field in my view, not the username field.
Comment #54
RoSk0I 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.
Comment #55
KingdutchPatch applies cleanly and works with views 3.15 en Drupal 7.52
Comment #56
MegaChriz CreditAttribution: MegaChriz as a volunteer commentedTested 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++
Comment #57
vistree CreditAttribution: vistree commentedPatch in #47 works for me, too. Is this something which can be commited?
Comment #58
dqdWell, as stated already @ #49: yes it can. :)
Comment #59
pietrocap CreditAttribution: pietrocap commentedHi, I get again the same error with the latest .dev.
Comment #60
indigoxela CreditAttribution: indigoxela commentedUnfortunately 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?
Comment #61
joelpittetComment #62
rpayanmComment #63
joelpittetThe reroll looks great, thanks @rpayanm
Comment #65
dawehnerThank you for the work and especially testing! Committed and pushed to 7.x-3.x
Comment #66
dqd@dawehner++
Comment #68
DamienMcKennaComment #69
RoSk0Re-roll of #62 on top 3.21 version.