file_managed_file_browser_open() throws PHP warnings when the managed_file element has no #field_name

[robertgarrigos]

Summary

file_managed_file_browser_open() in core/modules/file/file.module assumes every managed_file form element belongs to a Field API field, and unconditionally reads $element['#field_name']. Elements built outside Field API (e.g. a custom block form using #type => 'managed_file' directly) never set #field_name, so this line breaks any time the file browser dialog is opened on such an element — regardless of whether a file is currently assigned to it or not.

What made me hit this bug in practice: file_managed_file_pre_render() only hides the "Select existing file" button while the element has a valid fid. My Hero block's assigned file became unavailable (the fid no longer resolved to a real file), so that button — normally hidden — reappeared. Clicking it for the first time is what exposed the pre-existing #field_name bug described above.

Steps to reproduce

1. Create a Hero block and assign an image to it via the managed_file field. Save the block. While a valid file is assigned, the "Select existing file" / upload button stays hidden (file_managed_file_pre_render() sets #access = FALSE on it whenever #value['fid'] is not empty).
2. The underlying file becomes unavailable — in my case the assigned file disappeared from the site (file record and/or physical file gone; exact cause still under investigation), leaving the block referencing a fid that no longer resolves to a valid file.
3. Edit the Hero block again. Because the field's value is now effectively empty, Backdrop shows the "Select existing file" / upload button again (the condition in step 1 no longer holds).
4. Click "Select existing file" to open the file browser modal.
5. The two warnings below are logged, and only then does the dialog open.

Actual behavior

Two warnings are logged:

Warning: Undefined array key "#field_name" a file_managed_file_browser_open() (línia 1870 de /Users/robert/Sites/backdrop/core/modules/file/file.module).
Warning: Trying to access array offset on null a file_managed_file_browser_open() (línia 1871 de /Users/robert/Sites/backdrop/core/modules/file/file.module).

(the exact lines are the two below.)

$field = field_info_field($element['#field_name']);
$field_cardinality = $field['cardinality'];

$element['#field_name'] is undefined, so field_info_field(NULL) is called and returns NULL, and the following line then tries to read ['cardinality'] off NULL.

Expected behavior

No PHP warnings. managed_file elements not attached to a Field API field should default to single-file behavior ($field_cardinality = 1) instead of assuming #field_name is always present.

Proposed fix

$field_cardinality = 1;
if (!empty($element['#field_name'])) {
  $field = field_info_field($element['#field_name']);
  if (!empty($field['cardinality'])) {
    $field_cardinality = $field['cardinality'];
  }
}

Environment

• Backdrop CMS version: 1.34.3
• PHP version: 8.3

[argiepiano]

@robertgarrigos thanks for reporting and for providing a patch!!!

Regarding point 1:

While a valid file is assigned, the "Select existing file" / upload button stays hidden (file_managed_file_pre_render() sets #access = FALSE on it whenever #value['fid'] is not empty).

This is the normal behavior also for field api file reference fields, so this works as expected, unless I'm misunderstanding what you meant.

Regarding point 2:

in my case the assigned file disappeared from the site

This I'm not able to reproduce. I tried changing the image, and I did see the old eimage being marked as temporary (and eventually removed) since the hero was the only place where it was used. This is also normal.

Regarding point 5: I'm able to reproduce these warnings. The code that produces this is part of the overhaul of the multi-upload (another side effect). Good catch!

Your fix is not ideal, though. A non-Field API managed_file element CAN have the property '#multiple' => TRUE as explained in the FAPI documentation. Your patch prevents the user from selecting multiple files in the browser (I realize that the Hero image is supposed to be single, so you can't see the problem).

To see this problem you should create a form builder function that has:

  $form['managed_file'] = array(
    '#type' => 'managed_file',
    '#title' => 'My images',
    '#upload_validators' => array(
      'file_validate_extensions' => 'jpeg jpg png',
    ),
    '#browser_view' => 'image_library',
    '#multiple' => TRUE,
  );

After applying your patch, there is no warning when choosing "Select image" but you can't select multiple ones.

Marking this as "needs work"

PS: you pinpointed the cause of this correctly. I think the solution is to use the field cardinality if we are dealing with a field api field. If not, we should inspect the element and set the cardinality to -1 if #multiple is TRUE.

[argiepiano]

A quick solution building on what you submitted.

  $field_cardinality = 1;
  if (!empty($element['#field_name'])) {
    $field = field_info_field($element['#field_name']);
    if (!empty($field['cardinality'])) {
      $field_cardinality = $field['cardinality'];
    }
  }
  elseif (!empty($element['#multiple'])) {
    $field_cardinality = -1;
  }

[indigoxela]

I can confirm that this happens with every hero block when changing the file via image library. No matter if the previous file was lost or just removed on purpose.

    Warning: Undefined array key "#field_name" in file_managed_file_browser_open() (line 1870 of .../core/modules/file/file.module).
    Deprecated function: Using null as an array offset is deprecated, use an empty string instead in field_info_field() (line 726 of .../core/modules/field/field.info.inc).
    Warning: Trying to access array offset on null in file_managed_file_browser_open() (line 1871 of .../core/modules/file/file.module).

[robertgarrigos]

@argiepiano:

Regarding point 2:

in my case the assigned file disappeared from the site

This I'm not able to reproduce.

I probably didn't explain myself clearly enough: my file didn't just disappear. It was not backdrop's fault, nor a symptom of a problem. The file disappeared and triggered the error. You don't have to expect that the file will disappear. You have to delete it from the file system to trigger the error.

Good catch!

Claude's catch, actually.

Updated the PR with your suggestion.

[indigoxela]

@robertgarrigos sorry for the delay, I meant to test earlier, but... 😉

Here's how I tested:

1. Make sure to have an image wide enough (1200px) available via image library
2. Turn on error display of everything (on admin/config/development/logging)
3. On home open the default hero's block form and click on "Select existing file" button (open the dialog)

There I already see those:

    Warning: Undefined array key "#field_name" in file_managed_file_browser_open() (Zeile 1870 von ...core/modules/file/file.module).
    Deprecated function: Using null as an array offset is deprecated, use an empty string instead in field_info_field() (Zeile 726 von ...core/modules/field/field.info.inc).
    Warning: Trying to access array offset on null in file_managed_file_browser_open() (Zeile 1871 von ...core/modules/file/file.module).

Applied patch, flush caches, repeat step 3. Works for me! 👍

[argiepiano]

I can also confirm that the managed_file Form API elements work as expected. I tested both scenarios, an element with single cardinality, and one with '#multiple' => TRUE.