I have discovered that if a node has a multi-valued file field (one where more than one occurrence is permitted), then an attempt to save one or more files to that field will result in an ajax error as follows:

An AJAX HTTP request terminated abnormally.
Debugging information follows.
Path: /system/ajax
StatusText: n/a
ResponseText: 
Skip to main content
Production Rainbow                  
Error
Error message   Notice: Trying to get property of non-object in file_field_presave() (line 220 of /home/james/vmg-apws/modules/file/file.field.inc).  Warning: Creating default object from empty value in file_field_presave() (line 221 of /home/james/vmg-apws/modules/file/file.field.inc).  Notice: Undefined property: stdClass::$uri in file_save() (line 566 of /home/james/vmg-apws/includes/file.inc).  PDOException: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '' for key 'uri': INSERT INTO {file_managed} (filesize, status, timestamp) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2); Array
(
[:db_insert_placeholder_0] => 0
[:db_insert_placeholder_1] => 1
[:db_insert_placeholder_2] => 1385000089
)
in drupal_write_record() (line 7166 of /home/james/vmg-apws/includes/common.inc).       
The website encountered an unexpected error. Please try again later.      
Premium Drupal Themes

ReadyState: undefined

This is caused by an entry in the list of file field values in the %form_state['values'] array returned to the submit function containing an entry for an "extra" file (presumably the input field that was empty when the save button was clicked) that has a fid of zero (see below for dump of 'values' array

Array
(
    [nid] => 91
    [vid] => 275
    [type] => apws_job
    [field_apws_work_files] => Array
        (
            [und] => Array
                (
                    [0] => Array
                        (
                            [fid] => 2084
                            [display] => 1
                            [_weight] => 0
                            [description] => 
                            [upload_button] => Upload
                            [remove_button] => Remove
                            [upload] => 
                        )

                    [1] => Array
                        (
                            [_weight] => 1
                            [fid] => 0
                            [display] => 1
                            [description] => 
                            [upload_button] => Upload
                            [remove_button] => Remove
                            [upload] => 
                        )

                )

        )

    [submit] => Save
    [form_build_id] => form-uHfm81xhCvehsQcvEIG6ZgXmEUwgwSWzXYsL1Ko9mRs
    [form_token] => xM-mQ4He4C_s_d0oafeWQh33O5GxoLtIX9-IIOxDV80
    [form_id] => editablefields_form__node__91__275__field_apws_work_files
    [submit-] => Save
)

This does not happen when the normal node editing form is used, even though this dummy entry is present in the $_POST array, so presumably the logic that builds the $form_state array in that case has filtered this entry out. I'm not sure where that happens, or what filtering is done.

I have not tested whether this problem affects other multi-valued fields, perhaps in a less catastrophic manner, so it might be more than just file fields that need to be looked at.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

jlscott’s picture

Tracing progress through the function "editablefields_form_submit", I discover that the callentity_form_submit_build_entity($element['#entity_type'], $entity, $element, $form_state);
appears to properly prepare the node with the correct new field data (ie it does not include the emtpy file entry), but then the subsequent call_field_invoke_default('extract_form_values', $element['#entity_type'], $entity, $form, $form_state);
adds the empty file entry to the field data in $entity. This then fails when the subsequent call is made to "entity_save".

Removing the offending line appears to solve the problem. This needs to be verified with other field types (as presumably this call was added to address some other issue).

Patch attached.

mrconnerton’s picture

This patched helped me with #2267609: Cant accept null value where it wouldn't accept a null/empty value on a select term/entity reference field.