Notice: Undefined offset: 0 in views_handler_field_field->set_items()...

This seems to be a duplicate of #1070744: Undefined index: es en views_handler_field_field->get_items()

Same here, using views 7.x-3.x-dev (2011-Apr-16) with a GMap display.
I have the Office hours field, which is not filled. Does error occur only on 'complex' fields? An empty integr/text-field never gave this message.

The message is raised when the field definition has no content defined in hook_field_load(). You can try putting the following in the line before the raising-line: dpm($entity->{$this->definition['field_name']});
A 'normal' field returns e.g.:
a term:
... (Array, 1 element)
\en (Array, 1 element)
\\0 (Array, 1 element)
\\\tid (String, 2 characters ) 85

a text field:
... (Array, 1 element)
\und (Array, 1 element)
\\0 (Array, 3 elements)
\\\value (String, 4 characters ) content of field
\\\format (String, 10 characters ) plain_text
\\\safe_value (String, 4 characters ) content of field

Office_hours only shows:
... (Array, 0 elements)

trgreen23, how does your field look like?
dereine, should the contibuting field be fixed/amended, or should Views catch this exception?

Since the code already contains some tests for !empty($entity->{$this->definition['field_name']}, I guess this can be solved in Views itself.
Here is a small patch. (Needs fixing indentation and comments, but it's better readable this way)

Thanks for finding out the real reason. This is a great peace of information.

Please take care that drupal code style is still valid in this file.

thanks dereine. I know. But without indentation it was harder to see the differences, and a ref to the issue is for my own bookkeeping. I'm happy to provide a clean patch if the solution is OK.

In general i'm wondering whether we should fix the bug here, or in the field modules. Because this error shows a bug in this field modules, which is good from my perspective. The developers should know this.

In the case of OfficeHours, they did not implement hook_field_load() and other hook_field_.. functions. I don't think that omitting functionality is an error?

A brief chat with DamZ points to Views actually handling the formatter output wrong (or rather, not flexible enough), because there's no rule saying the rendered structure needs to be keyed by $delta.

In general, not implementing hook_field_load() is fine, but as I said above, we have a different problem.

EDIT: Actually, the docs for hook_field_formatter_view() do say that the rendered structure needs to be keyed by $delta.
The problem is that the office hours module doesn't implement hook_field_formatter_view() at all :P So the problem is definitely in the module.
Will think a bit on whether Views can be a bit smarter here.
We can at least check if $render_array is empty.

Any movement on this? I am getting this warning in views that display "Field Collections" (http://drupal.org/project/field_collection). If I remove the field from the view, the error disappears. Note I am also opening an issue on field collections since it seems very field-type specific.

I get this same error with the custom formatters module enabled (version 7.x-2.0-beta2) module.
The patch from #5 does silence the errors.

If there is no content, then shouldn't raw just be set to an empty string?

<?php $items[$count]['raw'] = isset($render_array['#items'][$count]) ? $render_array['#items'][$count] : ''; ?>
Instead of the current:
<?php $items[$count]['raw'] = $render_array['#items'][$count]; ?>

applied the patch in #5, seems to work for me.

The patch in #5 silences the error for me, but my fields disappear (a couple text fields and fivestar). Haven't had time to investigate too much yet.

Edit: actually, I should say the *content* of the fields disappears, but the fields' div tags are rendering.

Sean, can you try just making the change I mentioned in #12 only?
This change only silences the message.

Does the problem you mention in #14 still happen after that change?

subscribe

Kevin, I'm afraid #12 gives some different errors:
EDIT: nevermind... I was applying the code in #12 to an older version of the file. The errors are gone now.

• Notice: Undefined index: base table in views_handler_field_field->query() (line 80 of /var/aegir/platforms/drupal-7.0/sites/all/modules/views/modules/field/views_handler_field_field.inc).
• Notice: Undefined index: in views_handler_field_field->query() (line 110 of /var/aegir/platforms/drupal-7.0/sites/all/modules/views/modules/field/views_handler_field_field.inc).
• Notice: Undefined index: entity keys in views_handler_field_field->query() (line 115 of /var/aegir/platforms/drupal-7.0/sites/all/modules/views/modules/field/views_handler_field_field.inc).

#12 worked for me, using dev from june 17. Seems that the code has changed since then. If I remember right, i didn't apply #5 if that makes sense...anyways, thank you so far, kevin!

I am using the dev from july 02. The fix from #12 works. Any possibility this can be committed to the dev? Or are we not certain this is the solution?

Again, on most recent dev, applied #12. If this is the best solution, can it please please be committed? I get a FLOOD of errors every time I upgrade views.

I get this error with rc1, but only on one particular site.

subscribe

Set status back

I updated to the new dev today and still have the error

Reporting that you continue to get the error doesn't do anyone any good:

1) There is a patch
2) the patch is marked 'needs work'
3) We will not commit bad patches. dereine explicitly said the patch does not meet code style requirements. Setting this issue back to 'needs review' without addressing what is needed to be done is disrespectful. I am in awe that later responses ignore dereine entirely. :/

There are three choices:

1) Run your patched Views with the uncommittable patch
2) Fix the coding style in the patch
3) If you're unable, get someone who can.

I am, however, not at all happy with the idea that we should commit a patch that does not conform to our requirements to fix your bug. What kind of maintainers do you think we are? If you wish to participate, please help. If you do not wish to help or are not able to help, then absolutely positively do not make demands that we change our procedures for you.

Well, I don't think we are ignoring dereines' comments.
A short recap:
- johnv's patch #5 is effective, but merely hides symptoms, and definitely needs work to meet coding standards.
- thekevinday's patch #12 is an addition or a replacement - I really can't say. thekevinday??
- But the discussion in #8-#10 is still open: "should we fix the bug here, or in the field modules?"

Other participants, can you pinpoint your message to any contrib causing the message? See #4 for help on analyzing this.

At this point, I am a bit unclear where we are in this process, and I apologize if my request to commit something is jumping the gun. Here is where I think things in my testing process:

1. The patch in #5 doesn't apply to the most recent dev.
2. The manual fix in #12 seems to work, in that it silences the errors, and I do see any errors that I can trace to this original error in my site. I am getting other views errors, but I have no reason to think they are related.
3. I haven't the foggiest idea how to create a patch that incorporated #12. That said, I will happily test a new patch on a git version of dev as soon as one is available, and I will report back as clearly as I can my results.

Maria

#12 is intended to be a replacement to #5.

But please keep in mind, its purpose was to directly solve the problems being reported.
There is always the possibility that the root cause is something else. (which brings you to the decision from #8 & #10)

And as a personal note, I tend to favor using watchdog to report problems so that they are reported without costing end-user experience as these here errors certainly do.

#12 fixes the problem for me for 7.x-3.0-rc1 version.
The stange thing is I don't have this notice on my production site but only on my backup of the site...
Which is very weird... (sql + file dump mounted on a windows machine instead of a linux one)

Update status.

So i'm wondering whether some kind of watchdog entry should be thrown here, as this seems to be a real bug somewhere else in the process.

The patch at #28 by thekevinday solves a similar issue I had (more information here: http://drupal.org/node/1247792#comment-4883974).

Had the same problem. Subscribing..

Subscribing

subscribe - same error mesage

subscribe

Not sure if this is helpful: For me, the issue appears if I drop a particular Computed Field into a View. The site uses two Computed Fields - one works fine and one kicks back that error.

#28 worked for me
txs

@ sneeuwgetsie, You can help use finding the root cause. Which field gave you the problem? If you know some debugging, #4 might give you a hint.

My root cause was that I had field collections in nodes view was listing and some of those nodes had fields in field collections empty.

Patches above seem to address same lines, my solution is similar

      if (!empty($render_array['#items'])) {
        $items[$count]['rendered'] = $render_array[$count];
        $items[$count]['raw'] = $render_array['#items'][$count];
      }

As some parts of the code there changed this patch doesn't apply anymore.

I am not sure what the correct behavior is, so I made two different patches.

patch a:
- This is a remake of my patch from #28.
- I am also wondering, should raw be set to an empty string or not set at all?

patch b:
- This is a remake based on #39.
- The behavior here is if the count does not exist, then completely skip the field.
- Mine is different from #39 in that I only skip if the specific count is not present, not if the items array is empty.

Patch b-1 eliminates the notice for me, which was also caused by an empty field_collection.

#41 patch b-1 works for me

#41 one b works for me. thank you

This has been fixed upstream.
I noticed that in 3.0, the code now looks like:

<?php
    foreach (element_children($render_array) as $count) {
      $items[$count]['rendered'] = $render_array[$count];
      // field_view_field() adds an #access property to the render array that
      // determines whether or not the current user is allowed to view the
      // field in the context of the current entity. We need to respect this
      // parameter when we pull out the children of the field array for
      // rendering.
      if (isset($render_array['#access'])) {
        $items[$count]['rendered']['#access'] = $render_array['#access'];
      }
      // Only add the raw field items (for use in tokens) if the curent user
      // has access to view the field content.
      if ((!isset($items[$count]['rendered']['#access']) || $items[$count]['rendered']['#access']) && !empty($render_array['#items'][$count])) {
        $items[$count]['raw'] = $render_array['#items'][$count];
      }
    }
?>

Which is pretty much the same fix supplied by the patches here plus a few more checks.