Notice: Undefined index: module in editablefields_fallback_formatter()

I had the same issue too and discovered that you have to put something into the "empty text" area in the editablefield's settings under Manage Display.

screenshot attached

i get this error like this:

Notice: Undefined index: module in editablefields_fallback_formatter() (line 173 of C:\xampp\htdocs\b2011\sites\all\modules\editablefields\editablefields.module).
Notice: Undefined index: module in _field_info_prepare_instance_display() (line 350 of C:\xampp\htdocs\b2011\modules\field\field.info.inc).
Notice: Undefined index: module in editablefields_fallback_formatter() (line 173 of C:\xampp\htdocs\b2011\sites\all\modules\editablefields\editablefields.module).
Notice: Undefined index: module in _field_info_prepare_instance_display() (line 350 of C:\xampp\htdocs\b2011\modules\field\field.info.inc).
SearchApiException: No field settings for index with id default_node_index. in SearchApiDbService->indexItems() (line 314 of C:\xampp\htdocs\b2011\sites\all\modules\search_api_db\service.inc).

subscribing

I thkn this happens when I disable a module which has formatters set in Fields or Views. When the formatter has become disabled, the Editable formatter is the first one,instead of the Default one that most modules offer.

The error happens with more modules, when they are enabled, disabled.
I have added the following to the code to find the wrong formatter.
After saving the mentioned field settings, the message no more appears.

function editablefields_fallback_formatter($entity_type, $entity, $field, $instance, $langcode, $items, $display) {
  // Set the fallback formatter.
  $display['type'] = $display['settings']['fallback_format'];
  $display['settings'] = $display['settings']['fallback_settings'];
  $formatter_type = field_info_formatter_types($display['type']);
  $display['module'] = $formatter_type['module'];
+ if (!isset($formatter_type['module'])) {
+   watchdog('editablefields', $instance['entity_type'] . ' '. $instance['field_name'] . ' ' . $instance['label'] . ' ' . $instance['widget']['type']);
+ }

  // Clone the entity to avoid messing with it.
  $cloned_entity = clone $entity;

  return field_view_field($entity_type, $cloned_entity, $field['field_name'], $display, $langcode);
}

I think the problem is more along the lines of #2 - if you insert something -- anything -- into the empty_text field, "it works."

Since the suggested fix worked for me quickly, I didn't spend a whole lot of time looking into this, but I think the attached patch gets at the real culprit. In editablefields_lazy_render_fields() there's an !empty() on the empty_text configuration, and I'm guessing it should be isset(). This didn't introduce a regression, though it could use review on a new install.

I had the same messages and had a go with the current dev. My conclusion: it's a permissions thing. Both inserting something into the empty_text field or applying the patch from #8 didn't do it for me. Setting permissions to edit the content type solved it for me.

So what needs to be done is check for node edit permissons (if that is possible by this module) or display a nice message if editable fields are not present. But if you want one to only edit your editable field and not the other node fields, there should be a more differentiated permission scheme.

I think that the source of the issue is that editablefields_field_formatter_info has

'fallback_format' => NULL,

So, later when editablefields_fallback_formatter tries to get the default format, there is nothing there. Setting fallback_format to 'text_default' clears up the issue for me but may cause side effects that I haven't discovered yet.

'fallback_format' => 'text_default',

Same issue here.

Notice: Undefined index: module in editablefields_fallback_formatter() (line 173 of /var/www/web/sites/all/modules/editablefields/editablefields.module).
Notice: Undefined index: module in _field_info_prepare_instance_display() (line 354 of /var/www/web/modules/field/field.info.inc).

Successfully worked around by adding some text to the empty_text field.

#2 worked for me as well. Thanks for posting and thanks for this great module
btw, #2 initially didin't work for me: after filling the empty text box and running cron I had 4 pages of the same errors. I had to clear cache a few times, now fine.

#8 Patch is working fine and message disappeared as soon as i patched and reloaded the page.
Thx for your effort and sharing.

Tested

#8 didn't work for me.
I also tried #2 and #2 + #8 without success.

The only workaround that seems to work for is is checking if "$formatter_type['module']" is set in function editablefields_fallback_formatter:

  if(isset($formatter_type['module'])){
    $display['module'] = $formatter_type['module'];
  }
  else{
    return;
  }

I concur with the "Edit Content Type" permission issue - admins with the permission do not see the error (and can edit the field) while anonymous users see the error. Solutions #2 and #8 failed for me as well - #15 did the trick however.

#15 indeed worked. Ready to commit a new version?

Might want to change set the status

Needs to be an actual patch file.

#15 works for me. Here's a patch.

I'm thinking we want to return something other than NULL here. From the API docs, field_info_formatter_types() returns "Either a single formatter type description, as provided by hook_field_formatter_info(), or an array of all existing formatter types, keyed by formatter type name." Will take a closer look at this later today... when I have a chance.

del.

Please try the patch provided in #1275924-7: Notice: Undefined index: default_formatter in editablefields_field_formatter_default_settings() with 'Media Field' and tell if it fixes the issue.

Applying #15 here + https://drupal.org/comment/8252581#comment-8252581 resolved the issue for me.

Patch #20 manually worked for me. Did not need the other one mentioned. Thank you.

Patch #20 manually worked for me too.

patch from #20 works.

@dags, could I get your thoughts on the return NULL return value from #21?

#20 works for me.

I'm all for fixing notices, but I'd like to provide more info to why it's missing to the user instead of just bailing.

'module' key should always exist, in what case does it not?

This is the line the adds it I believe in core:
modules/field/field.info.inc:221

Hello @joelpittet,

Looks like problem somewhere around field module.
If you'll change actual formatter for the field and if there is exists settings form for the formatter you have to open formatter settings form to save formatter settings (Please see attachment). Otherwise field module won't save even default formatter settings.

Also looks like patch from #20 was commited in dev version. I think that even this patch works good it would be better to solve this problem as it done for the formatter settings form (see editablefields_field_formatter_settings_form() function - via default formatter settings). I attach patch which reflects my vision.

The patch in #20 was committed (most likely accidentally) in this commit, which was for #2753349: Prevent huge cache form table.