Notice: Undefined index: #field_name in file_managed_file_save_upload()

You are correct I reproduced it, working on a fix right now.

The quick work around to this is put a file save directory location into your dynamic banner settings. For some reason the default save location is not loading. Which is public://banners which translates into sites/default/files/banners/ if your site is setup in this fashion. I am currently working on a fix for this but this would be how to get past the problem just for now. I'll let you know more as it develops and I will have to work on the bug more.

Fixed, pushing release soon thanks for the reminder :)

I recommend you uninstall the module before you download the new release sorry about this but the variables have changed names.

I tried the suggested hotfix, and the new (august 22th dev release), neither of them worked for me.

My solution:

- Go to my_drupal_path/sites/all/modules/dynamic_banner/includes/callbacks.php line 352, it should look like this:

    '#upload_location'    => variable_get('dynamic_banner_file_save_path', BANNER_DEFAULT_SAVE_LOCATION),

And change it to:

    '#upload_location'    => 'public://banners',

I suppose this causes loss of functionality, but originaly was unable to even upload images. Hope this helpes others in need and maybe the solution of the issue.

This is not needed but I have not be able to reproduce the problem after I fixed it. The original problem was that the variable was set to null. If I used the variable get call correctly it means that it will try to load the variable 'dynamic_banner_file_save_path' first if it does not exist it will use the second argument as the default which is the php constant 'BANNER_DEFAULT_SAVE_LOCATION' which is set earlier on in the call stack. So the hard fix is that what you mentioned to set the upload location but I technically cover my own @ss by setting it twice basically. I did some testing and if you set the settings up correctly it should not happen. So can you please tell me all the steps you took to get the bug to appear after a fresh install.

I'm curious if you posted the patch for this. I just had the same errors show up, and I have the latest version of this module installed. Specifically, here is what I get:

1. ADD BANNER generates the following errors:
   
   Notice: Trying to get property of non-object in dynamic_banner_admin_form() (line 261 of /home/sites/ssw.columbia.edu/web/sites/all/modules/dynamic_banner/includes/callbacks.inc)
   
   before I even add anything.
2. In addition, on save I get the following errors:
   
   Warning: array_flip(): Can only flip STRING and INTEGER values! in DrupalDefaultEntityController->load() (line 178 of /home/sites/ssw.columbia.edu/web/includes/entity.inc)
   
   
   Notice: Trying to get property of non-object in dynamic_banner_image_handler() (line 767 of /home/sites/ssw.columbia.edu/web/sites/all/modules/dynamic_banner/includes/callbacks.inc).
3. Third issue, the template file doesn't seem to easily be overridden, I'm still working on this now. Trying to avoid hacking the core template file rather than using from my theme.

Thanks!

subscribe

Yup me to. Any fix on this?

For reference, the problem you have is that the files directory that it is trying to save files to is not writable.
Make the files directory writable and the error should go away.

However there is an underlying problem, which is the undefined index error, which seems to be caused by drupal core.

See #1903010: Notice: Undefined index: #field_name in file_managed_file_save_upload()

I got the same issue but I solved it with changing the file permission to read & write

Confirming that changing the file permission to read & write fixed it for me.

I had to apply chmod 777 to private file path, configured from within a webform, to fix this issue on local host (using a vagrant box).

As rooby has mentioned you'll want to make sure that the directory is writable by your web user. If you continue to have this issue you might want to dig further at how you have your user writing files to the disk. You will want to ensure that your web user is setup to be able to write to those directories and that it has been allowed by any gate controls (SELinux permissions, antivirus etc). If that still does not work you might want to investigate an issue with an improper UMASK for that user which kills off permissions when you apply them with Drupal.

Side note: I will also be further investigating how Dynamic Banner creates this directory in the first place which might reveal the root cause.

Applying 775 worked for me.