| Project: | FileField Sources |
| Version: | 7.x-1.x-dev |
| Component: | General |
| Category: | bug report |
| Priority: | major |
| Assigned: | Unassigned |
| Status: | reviewed & tested by the community |
Issue Summary
Problem
This issue is present on file field that can accept unlimited number of values after one of FF Sources methods is enabled.
After user select existing file (via referencing existing or browsing through IMCE) there are no more Add a new file form i.e. user cannot upload / select new file without refreshing (save + edit or preview) whole node edit form.
Proposed resolution
Workaround can be to preview node and then Add a new file form will show up - but as stated in #11:
Since the core upload functionality works correctly, I suspect the problem can be related to an API change that must be taken into account by filefield_sources.
Problem is probably related with #1059268: Files are lost when adding multiple files to multiple file fields at the same time issue and it is not appearing in D7.8, but in D7.10.
IMCE for File Field module had similar problem that was fixed.
Original report by GiorgosK
after uploading an image a form to add another image should be presented
After upgrading from 7.8 this functionality got lost
I think this functionality got lost on my upgrade to 7.9
Comments
#1
filefield sources seems to be at fault
tried the following
upload a file with "remote URL" & "reference existing" enabled
and the form to add another file appears
but if you try to use remote file or reference existing
the form to add another file does not
EDIT: if after remote uploading an image save the node the form to upload / remote upload another image appears
#2
Confirm this behaviour.
#3
I think that it may be related to the #1059268: Files are lost when adding multiple files to multiple file fields at the same time and patch 1059268.patch.
This patch was applied to Drupal 7.9
#4
same problem here .
#5
same problem too
hope someone patch it
#6
I noticed after upgrading 3 different sites of mine to 7.9 this happened to all of them , its a bug in 7.9
#7
confirm this behavior. it actually shows the form when using the upload feature, but not on the browse the server one!
#8
subscribe
#9
Same here
#10
+
#11
I can confirm the problem doesn't happen with Drupal 7.8, but happens with 7.10.
I used this makefile to create a test site:
core = 7.x
api = 2
projects[drupal][type] = core
; Specify the version to test against a particular version of D7
projects[drupal][version] = 7.8
; Save some clicking for going through the admin by enabling admin_menu_toolbar.
projects[admin_menu][subdir] = contrib
projects[filefield_sources][subdir] = contrib
What I did was I installed two test sites (7.10 and 7.8); on each site I modified the Image field that comes with the Article content type to accept unlimited values. I then proceeded to create a node using the standard upload functionality (Drupal Core) and it showed the "Add New File" widget correctly, right below the latest image uploaded. Finally I just installed filefield_sources, enabled it on the Image field, created a second node (this time using the "Reference Existing" functionality for the Images field) and the symptom showed up: no "Add New File" widget to upload more images.
Since the core upload functionality works correctly, I suspect the problem can be related to an API change that must be taken into account by filefield_sources.
EDIT: A site I'm working on (7.10, with many other modules) has the same problem when using IMCE Browser.
#12
subscribing
#13
subscribe
#14
Hi folks.
Please stop subscribing, start following. :)
Regarding this issue, it is also present if you are using IMCE file browser:
Before:
After:
I shorten title and added higher priority..
#15
Just added to issue summary:
#16
Thanks @mariomaric. I haven't had time to investigate what in Drupal 7.8 and higher broke this functionality. The IMCE fix could help pin that down.
#17
Has anyone been able to find a workaround or fix the issue?
#18
If you comment out line 202 in filefield_sources.module it seems to fix it. Although I imagine this has some other knock on effect i'm unaware of, hopefully it will give someone with more knowledge a place to look.
//$element[$key]['#access'] = FALSE;EDIT: Ignore this, doesn't work at all.
#19
subscribe
#20
@Wound - Please stop subscribing, start following
#21
Sorry, #18 did not work for my situation. Until it gets fixed, I'm just telling my clients to add a file, save the node, then go back in to edit. The input for an additional file shows up then. Annoying, but at least they can add the content.
#22
Hi,
please try and help review the attached patch.
Field values are stored in field state 'items', and not in form state 'values', after ajax refresh from D7.9. This patch tries to work with both.
I had to tackle this when I needed to create my own submit handler for FileField Sources Plupload, a sandbox project that adds Plupload (multi file upload) as a FileField Sources source. Shameless plug, i know, but I need help testing/reviewing. ;)
Edit:
Don't use this. See #27.
#23
#22 works perfectly for me, thanks atlea
#24
#22 worked for me, too. Thanks!
#25
I repeated the testing I performed on #11 for Drupal 7.10 and the patch at #22 seems to solve it correctly, both for "reference existing" and for "IMCE browser".
I'm attaching the exact same patch, but created with git diff --no-prefix, so that it can be applied by drush make.
EDIT: A test site can be easily created using this makefile:
core = 7.x
api = 2
projects[drupal][type] = core
; Specify the version to test against a particular version of D7
projects[drupal][version] = 7.10
; Save some clicking for going through the admin by enabling admin_menu_toolbar.
projects[admin_menu][subdir] = contrib
projects[imce][subdir] = contrib
projects[filefield_sources][subdir] = contrib
projects[filefield_sources][patch][] = http://drupal.org/files/filefield_sources-fix_submit_handler-1329056-25.patch
#26
Great to hear that its working! I have updated the code to handle empty values and clearing out input when the field is in a container.
I recreated the patch, so please use the attached patch against a clean 7.x-1.x-dev and not on top of the previous patch.
Atle
Edit:
Don't use this. See #27.
#27
Sorry - there was a small error in patch #26. Please use attached file.
#28
Patch at #27 is working like a charm.
#29
Patch at #27 works ok; tested as indicated in #11, only with 7.10.
#30
Patch #27 worked, using FF Sources & elFinder. Thanks
#31
I can confirm as well, Patch #27 applied and tested, it's working on drupal 7.10. Thanks!
#32
so maybe its time to let the maintainer know that there something to commit
#33
I can also confirm that #27 fixes this issue, thank you!
#34
Patch works fine for me!
#35
Seems to work for me too
THX
#36
Patch is already in 'reviewed & tested by the community' status so I think it's better time to "follow" instead of reporting fix's status. Stop subscribing, start following, so we can see when the patch is commit in the tracker :)
#37
@Ayesh
you are right about a follow / subscribe issue
but in this case more report that the patch works gives the maintainer even more confidence that the patch works correctly (the more tests the better) ...
#38
Got it!
Thanks Giorgos. and sorry about bad suggestion.
#39
@Ayesh
I am not saying I am correct, all I am saying its not clear cut better to stop posting in this particular case ...
#40
As the maintainer I also agree with this. The more agreements that the patch works the better. This patch is particularly a bit funky because it works around a seemingly inexplicable change in Drupal core. At this point I'm pretty confident it works but I'm questioning if there's not an "easier" approach. Then again, if it works it really should probably just be committed anyway.
#41
@quicksketch: I agree it's a bit funky, but so is core's new way of handling this. ;) Did you find an easier approach, or could we at least commit this until this approach is found?
#42
Has this been committed? I am on 7.12 having this same issue. I am wondering if I should add the patch but want to know if it has been committed to HEAD. Thanks.
#43
No it's not committed, sorry for my lack of updates. I'll make sure to include this in the next release, please apply the patch to your own sites with confidence that it will be included in the next version. The more testing the better.
#44
Not sure what is going on, but doesn't work for me. I tried to patch all versions with same result: it does allow me to select, but does not attach. It does not disappear but nevertheless does not attach anything.
The same behavior is also on Reference existing. I tried on 7.x-1.4 and on 7.x-1.x-dev.
I'm on Drupal 7.14
Are there any clues on why this happens? I'd really like to help and to have this thing back as it is VITAL for any UX situation.