Undefined index: available_options in select_or_other_field_formatter_view()

Something's wrong in your configuration, check your fields' settings and make sure 'available options' is not empty.

Good to hear you figured it out, though I don't really get how that happened either.

I can confirm this problem. It happens when a new field is created. The format is not carried through to the view modes. New fields are given a default format which has to be manually changed to Select or other. A major pain when a bunch of fields are created!

I've done a test of different field settings but no pattern or cause found yet.

Update:

(updated module from 7x-2.8 to 7x-2.9 with no change in behavior)

Tracked this down to incorrect field format setting in the Manage display settings. A text field was given the 'Select (or other)' format in error.

Cause

There seems to be two reasons that allow this error to happen:

1) It seems the Format option on the Manage display settings allows the user to grant 'Select (or other)' format to text fields when the text field does not have the Select (or other) format set on the Manage field settings page. The Select (or other) option should not be available if the field does not have this format set in the Manage field settings.

2) When a new field with Select (or other) format is created the format is not carried through to the Manage display settings. I am not sure if this is by design or not, but I feel it should default to the setting in the Manage fields setting. Having to manually set to 'Select (or other)' on every Manage display page is just an invitation for oversight and errors.

I understand what you're saying, but I'm not sure there is anything I can do about it. Plus it seems to me like that code should only run when 'select or other' is chosen as the format..., which you're saying it isn't. And the 'undefined index' should be defined for all select or other fields regardless of the format anyway...
So long story short, I don't have a complete understanding of the problem and therefore don't know what to do about it (if anything is even possible).
Plus the hosting service I use for development doesn't give me these errors, I really need to do something about that.

I don't know if there is anything I can do about this other than documentation. If you know otherwise, please inform me how.

Sorry guys I don't know what to do about this one. If you can give me a patch or some ideas we may be able to go from there, if that's the case; feel free to reopen.

Turns out this is related to the PHP error reporting level. If PHP Notices are reported, then an 'undefined index' notice is posted on pages not using this module (including pages displayed to anonymous users). I've submitted a patch that will hopefully be incorporated into the next release. In the meantime, replace the following lines in select_or_other.field_widget.inc:

  $field_options = explode("\n", $instance['widget']['settings']['available_options']);
  $pos = strpos($instance['widget']['settings']['available_options'], '|');

with this:

  $available_options_is_set = isset($instance['widget']) &&
                              isset($instance['widget']['settings']) &&
                              isset($instance['widget']['settings']['available_options']);

  // Added conditional statement to prevent PHP Notices.
  // See http://drupal.org/node/1417356.
  if($available_options_is_set) {
    $field_options = explode("\n", $instance['widget']['settings']['available_options']);
  }
  else {
    $field_options = array("");
  }

  // Added conditional statement to prevent PHP Notices.
  // See http://drupal.org/node/1417356.
  if($available_options_is_set) {
    $pos = strpos($instance['widget']['settings']['available_options'], '|');
  }
  else {
    $pos = false;
  }

Forgot to attach patch file...

This is not at all patch for the problem here, and you have not addressed the points that have been raised. You've simply hidden the error message (in a unnecessarily complicated way) and the resulting logic no longer does what the code was intended to do.

@danielb: In hook_field_formatter_view() I don't see a check on the $display['type'] that I would normally expect in a field formatter view, but regardless, when I dpm($display) I can see that 'type' = 'select_or_other_formatter' for every text field that I've created on my vanilla D7 install. I have yet to create a single select_or_other field (or rather a field using this widget).

Meh, I should have checked other view modes. I can't explain why, but this is what happened to me and likely happened to others in this issue as well as the duplicates that I see in your queue – for view modes such as 'teaser' or custom ones, "Select or other" was picked as the display widget for some various text fields. I'm not sure why this would be chosen over 'default' on a new field.

Got similar problem:
Notice: Undefined index: available_options in select_or_other_field_formatter_view() (line 405 of [...]\sites\all\modules\select_or_other\select_or_other.field_widget.inc).
Notice: Undefined index: available_options in select_or_other_field_formatter_view() (line 406 of [...]\sites\all\modules\select_or_other\select_or_other.field_widget.inc).

For what its worth, i was having this problem until I realized that I was using select-or-other display formatters on regular text fields on my entities. One flaw of Select-or-other module is that it makes its own formatter the default for all text fields, so it is easy to let it slip in when you're doing field display config.

#15 BINGO!
I had same problem and tracked it down to same
thanks for pointing this out.

In the latest dev version Select (or other) options have been moved down so they should not be selected as the default for new fields.

See: #1953284: Increase module weight