I've tried to gather as much info about this issue as possible. Sadly I'm not able to resolve it, although I felt I was close at times. Let's start with the pathology.
Steps to reproduce.
- Install the lastest 8.x
- Enable the language module. This error does not occur if the language module is disabled.
- Apply the patch in this issue (unless it has already been committed): #1960612: jQuery UI 1.10 update broke Create.js, and thus in-place editing
- Create an Article node with a title and body, but not image in the image field.
- Go to the node page (node/1) and select "Quick edit" from the contextual links.
- Change the body field test and click Save.
- You should see an AJAX error like this:

The text of the error
An AJAX HTTP error occurred.
HTTP Result Code: 200
Debugging information follows.
Path: /edit/form/node/2/body/und/full
StatusText: OK
ResponseText: Recoverable fatal error: Argument 1 passed to Drupal\file\FileUsage\DatabaseFileUsageBackend::add() must be an instance of Drupal\file\Plugin\Core\Entity\File, boolean given, called in /Users/jbeach/code/drupal/core/d8/core/modules/file/file.field.inc on line 267 and defined in Drupal\file\FileUsage\DatabaseFileUsageBackend->add() (line 51 of /Users/jbeach/code/drupal/core/d8/core/modules/file/lib/Drupal/file/FileUsage/DatabaseFileUsageBackend.php).
I think this error begins with a bad value assigned to the image field's language property. It surfaces like this:
$entity->field_image['und'] = array(0 => NULL);
I don't know where this assignment happens, that's been the focus of my debugging efforts. I assume it happens somewhere in the field composition stages. Here is what the error looks like in _field_invoke() in field.attach.inc.

The $items variable on line 411 is set to array('0' => NULL) which causes two bad things to happen:
- empty($items) returns FALSE.
- for loops on the $items variable run through one iteration on a value that is NULL.
These two behaviors account for the downstream errors. The first we see in the logs is a call to array_flip on an array that contains a non-string or non-number value because the value is NULL.

I've looked in the language module but don't see where where a NULL value is pushed into an array e.g. $someArray[] = NULL or something similar.
| Comment | File | Size | Author |
|---|---|---|---|
| #6 | Screen Shot 2013-04-24 at 14.59.48.png | 53.47 KB | wim leers |
| Screenshot_4_6_13_1_54_PM.png | 159.11 KB | jessebeach | |
| Screenshot_4_6_13_2_04_PM.png | 236.71 KB | jessebeach | |
| Screenshot_4_6_13_3_18_PM.png | 61.4 KB | jessebeach |
Comments
Comment #1
wim leersAt this point it's — AFAICT — definitely still possible that the cause of this problem lies in the calling code, i.e. in edit.module.
Comment #2
wim leersBetter title.
Comment #3
swentel commentedWondering if this is related to #1916858: EntityFormController::submit() returns an unrenderable $entity depending on hook_field_load() implementations which we opened after #501428: Date and time field type in core (see #149) - debugging some as this may as well be my fault - although I'm amazed by the fact that simply enabling the module blows these things up.
Comment #4
berdirCould also be an EntityNG problem, similar to #1957748: hook_field_prepare_view() is passed empty field values for EntityNG Entities and #957888: landing page wizard -default layout not engaging.
Comment #5
wim leersYeah, #1957748: hook_field_prepare_view() is passed empty field values for EntityNG Entities might have fixed this!
Comment #6
wim leersI checked, and #1957748: hook_field_prepare_view() is passed empty field values for EntityNG Entities didn't fix this:
Comment #7
dcam commentedhttp://drupal.org/node/1427826 contains instructions for updating the issue summary with the summary template.
Comment #8
wim leersNo need for an issue summary update, the problem is clearly described. Not every issue has to strictly follow the issue summary format, it's only a guideline.
Comment #9
wim leersHurray! :) I can't reproduce this anymore! This got fixed somewhere in the entity or field system I think :) It never made sense that Edit module could be at fault for this.
One less major!
Comment #9.0
wim leersadded some markup