Problem/Motivation

When using an image field in a field collection that is added to a node form using the field collection field and the 'embed' widget, clicking the "upload" button clears the selected file from the entity instead of uploading and attaching it. If you specify a file with "choose file" but don't click upload, and then save your node, the image is attached and functions as expected. Ie the issue impacts on Ajax based uploading of image widget fields in the embedded field collection form.

Proposed resolution

Firstly update to the latest -dev versions of field_collection and entity although that most likely won't fix it.

Remaining tasks

/

User interface changes

None

API changes

None

Original report by RobW

When using an image field in a field collection, clicking the "upload" button clears the selected file from the entity instead of uploading and attaching it. If you specify a file with "choose file" but don't click upload, and then save your node, the image is attached and functions as expected.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

RobW’s picture

Title: Image field malfunctioning on field collection form. » Image field malfunctioning on embedded field collection form.

Forgot to mention this occurs with the embedded widget only.

Deciphered’s picture

I can confirm this.

WilliamB’s picture

Subscribe

fago’s picture

I think there is a general problem with images/files if modules embed the field API form not at the $form root, like profile2 and field-collection do. Maybe search for a related core-issue.

also see #1095490: Problems with files/images in the user registration form

jamsilver’s picture

Just to add some more perspective. This was definitely *not* an issue with the earlier version of the embedded form functionality found here: http://drupal.org/node/977890#comment-4237396, but is something that we have run into since updating to the newest version of field_collection.

munkyonline’s picture

andymantell’s picture

Subscribe

lowelhal’s picture

Priority: Normal » Critical

Has anybody found a solution. Or are there an other widgets to use with field collection instead of the embedded widget? I need to solve this problem urgently to get field collection to work on a site that I am building for someone.

Deciphered’s picture

Priority: Critical » Major

lowelhal,

You can use the other widget packaged with the module, so the issue isn't critical, but it is a pain in the ass. The other widget just hides it on the Node form and you add the field collections via the Node page.

munkyonline’s picture

I'm now getting the following message in Chrome when I try and upload an image. The embedded form does not contain this unlimited image field, it's on a separate horizontal tab item created using the field group module.

An AJAX HTTP request terminated abnormally.
Debugging information follows.
Path:/file/ajax/field_home_slide/und/form....
StatusText:n/a
ResponseText:
Fatal Error: Call to undefinded method FieldCollectionItemEntity::setUp() in /var/www/domain/sites/all/modules/field_collection/field_collection.module on line 364
ReadyState:undefined

If I try and save the page without clicking the upload button then I still get this error:
Fatal error: Call to undefined method FieldCollectionItemEntity::setUp() in /var/www/domain/sites/all/modules/field_collection/field_collection.module on line 364

valderama’s picture

Using the current dev this error[1] persits, even when switching to hidden-widget.

If I remove the image field from the field collection, I _still_ get the same error with the embedded-widget. However, the using the hidden widget, it works.

[1] Fatal error: Call to undefined method FieldCollectionItemEntity::setUp() in website\sites\all\modules\_fields\field_collection\field_collection.module on line 364

UPDATE: Using the current dev of Entity API, it looks like that: Without an image field it works with both widgets. With an image field, the hidden widget works. Embedded widget works somewhat - clicking on "upload" does not upload, but when saving the node, the image is uploaded.

Also, I stumbled across strange behavior when switching between the different widgets and adding/removing the image field to the collection. Sometimes, instances of a collection "disappeared" and "reappeared" after deleting other instances..

lowelhal’s picture

Ok, i used the hidden widget, But would still like the user to be able to add data to the field collection fields while creating the content type. any patches or fixes to solve this problem whether it be a core problem or not?
Or any idea if successive releases will address this problem? and how soon?

TreyeDesigns’s picture

Subscribe

droplet’s picture

Subscribe

mariagwyn’s picture

I hope this is the right place to post this. I was directed here from: http://drupal.org/node/1205670

I am having this same problem. It does not appear to matter if the upload field is actually in the field collection. I have a beta tester telling me that saving his user profile, which has two field collections, produces this error each time he makes any save at all, and yes, there is an field for a file upload. However, this field is not in the field collection.

This is the error: Exception: The host entity may be set only during creation of a field-collection item. in FieldCollectionItemEntity->setHostEntity() (line 191 of /home/host/public_html/sites/all/modules/field_collection/field_collection.module).

I am not sure this is just a pain since it renders the embed widget unusable. This widget matches how content is normally added to a page (via an edit form rather than in the node view). Is there a way to backtrack to the previous recent dev? Does anyone have a copy? This new error breaks a number of content types I set up.

mariagwyn’s picture

I hope this is the right place to post this. I was directed here from: http://drupal.org/node/1205670

I am having this same problem. It does not appear to matter if the upload field is actually in the field collection. I have a beta tester telling me that saving his user profile, which has two field collections, produces this error each time he makes any save at all, and yes, there is an field for a file upload. However, this field is not in the field collection.

This is the error: Exception: The host entity may be set only during creation of a field-collection item. in FieldCollectionItemEntity->setHostEntity() (line 191 of /home/host/public_html/sites/all/modules/field_collection/field_collection.module).

I am not sure this is just a pain since it renders the embed widget unusable. This widget matches how content is normally added to a page (via an edit form rather than in the node view). Is there a way to backtrack to the previous recent dev? Does anyone have a copy? This new error breaks a number of content types I set up.

kugta’s picture

Subscribe

sebish’s picture

Updating entity module to the last dev version (7.x-1.x-dev from july 7) seems to solve the issue for me.

mariagwyn’s picture

I upgraded to entity, july 7 dev. The difference is that the site no longer throws the error page to the user. However, the error is still generated, and a change in settings are not saved. Note that the change is not in a field-collection.

correction: I also updated field collection to july 7. errors gone (see http://drupal.org/node/1204428)

pacome’s picture

Subscribing

I have the same behavior described on the first post (both with files & images)

In my case it only happens on the "general" create/edit form ; everything seems to work fine when I use the specific edit form of the field-collection.

Best
-P-

WilliamB’s picture

Hum i updated to latest version both module:
Entity: 7.x-1.x-dev - 2011-Jul-12
Field collection : 7.x-1.x-dev - 2011-Jul-05

And i still have the upload box getting cleared when i click on upload.
Does it really work for you now that you uploaded both modules only? or did you change anything else? Like getting Drupal 7.4?

mariagwyn’s picture

@williamb, I already had drupal 7.4 so I didn't think it a factor. Could be wrong about that.

pacome’s picture

some more details about the configuration i use :
Drupal 7.4
Entity : last dev (july 13)
Field-collection : last dev (july 5)

the behavior stays as described above..

crimsondryad’s picture

We are using Entity beta10 and the latest dev of field_collection ( July 4 ). Trying to upload an image fails, the image does not upload even when I save the collection. However, when I edit the collection record, I can upload successfully and subsequent edits don't remove the image. So it follows that the issue is in the create function for either entity or field_collection.

I haven't had a chance to dig around in the code, but I'm wondering what the difference is between the create and edit functions for those.

Cray Flatline’s picture

+1. Have same problem

mauriziopinotti’s picture

+1

alanburke’s picture

Subscribe

danieljackson’s picture

+1

somanyfish’s picture

+1

zilverdistel’s picture

subscribe

dharrison’s picture

+1

bjalford’s picture

Has anyone made progress with this? I'm struggling where to start - and pointers?

larowlan’s picture

Subscribe, I've got some time to look at this one in next few days

Finn Lewis’s picture

Just to add to the list, I'm seeing this behaviour on
Drupal 7.7,
Field Collection 7.x-1.x-dev (2011-Aug-11),
Entity 7.x-1.x-dev 2011-Aug-15.
I took a quick look a the post json response in firebug, but I could not see anything obviously wrong.
I also hope to get a chance to look further into this soon, has anyone made any progress yet?

Mike Dodd’s picture

+1 for Field Collection 7.x-1.x-dev (2011-Aug-11),

Rachid’s picture

+1

Jelle_S’s picture

+1 same problem

casey’s picture

Current code is missing my fix for filefields (http://drupal.org/node/977890#comment-4233662)

At least the #value_callback is missing.

Finn Lewis’s picture

@casey - looking at the patch on http://drupal.org/node/977890#comment-4233662 I see the #value_callback in the hook_field_widget_form() - but the following 'simplified' patch in http://drupal.org/node/977890#comment-4235428 does not seem to mention #value_callback. Was it then missed in following re-rolling of the patch or is it not needed for another reason? I tried adding the #vallue_callback and corresponding callback function but no joy. Any ideas?

casey’s picture

I'll look into it tomorrow (if nobody does today).

Finn Lewis’s picture

@casey - awesome - I'd look into it further myself, but flat out getting ready for Drupalcon - are you coming? I'll have to buy you a beer!

casey’s picture

Status: Active » Needs review
FileSize
1.73 KB

On a form rebuild the collection entity is rebuild and changes are left out. I haven't spent too much time on this; there might be a cleaner solution. Looking at the old code we always were using the field collection item entity in $items. Anyways, this shows it is fixable.

@ecofinn unfortunately not, thanks for the beer though :)

lukus’s picture

@casey;

I had the same behaviour - I've just applied your patch and it's worked successfully. When I applied the patch I received a warning: warning: 1 line adds whitespace errors.

Apart from that all seems good.

Thx.

Poieo’s picture

#42 is working for me as well.

rafaelcaceres’s picture

#42 is working for me too!

larowlan’s picture

Status: Needs review » Reviewed & tested by the community

Rtbc this is one of d7s big success stories

Finn Lewis’s picture

The patch in #42 works for me too. Thanks casey!

erik.erskine’s picture

#42 is not working for me - I have 7.7 core, with dev versions of field_module and entity (straight out of git).
Does this need to be applied in conjunction with another patch?

thanks

Fidelix’s picture

Ingaro, you have to apply the patch manually.

tim.plunkett’s picture

Just a reroll to remove whitespace, otherwise identical to #42. Patch still contains git credit for casey.

JmsCrk’s picture

Patch in #51 works for me when applied to 7.x-1.0-beta2

joetsuihk’s picture

#52 and I confirm #51 patch works without error

pacome’s picture

patch #52 worked for me too
Thanks a lot !

-p-

fago’s picture

Status: Reviewed & tested by the community » Fixed

The patch looks good to me as it implements the proper form-workflow using form-state. So I committed it, thanks.

benjas’s picture

Had exact same probelm. Upgraded field-collection to lastest dev version (7.x-1.x-dev) and fixed the problem. Many thanks.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

joey-santiago’s picture

Actually, i think i have still this issue using 7.x-1.0-beta5 .

When i add for the first time some files to the field collection, they get uploaded correctly. if i then go editing the node, no files are added. I haven't actually found and error in my error log, neither JS errors.

EDIT: i found out i'm having this issue only when using a multiupload widget for my file field.

MtRoxx’s picture

I have updated the field collection module (7.x-1.0-beta5) and I am still having the issue. Suggestions anyone?

alm’s picture

I'm experiencing this issue with 7.x-1.0-beta5 and mutiple file upload. Any solution? Tks.

alm’s picture

I found that my problem (same as MtRoxx) is related with module field permissions, I'm using a field collection with multiple file entries in user profile using module profile2. Only when I give the permission "Edit anyone's value for field field_multi_files" works well. Not working with the permission I want: "Edit own value for field field_multi_files".

bessone’s picture

Version: 7.x-1.x-dev » 7.x-1.0-beta5
Status: Closed (fixed) » Active

I have the same problem with 7.x-1.0-beta5, but looking at the code it seems that the patch #52 exist, just with some changes.

Any news?

bessone’s picture

Issue summary: View changes

added issue summary

mohan890’s picture

Issue summary: View changes

We are using multilingual website. we are facing an issue in field_collection-7.x-1.0-beta5 module. After we upload the image and save the node, while we edit the node, the image is not saved in the database.

To resolve this issue:

1. We have upgraded the module to field_collection-7.x-1.0-beta7. After that we can able to save the image but we are facing some regression issues such
as we are not able to save for other text fields which we created by Field Collection. So we reverted back to field_collection-7.x-1.0-beta5.
2. We have applied the patches -

Still the issue is there.

Any help and guide will be highly appreciated!

jmuzz’s picture

The released versions of field collection don't support multilingual sites yet. You can try the repository version which has support for content translation, or if you are using entity translation you can try one of the patches in #1344672: Field Collection: Field translation (entity_translation) support..

mohan890’s picture

Hi jmuzz,

Thanks for your response.

I applied the patches and tried the repository version also but the issue is not getting resolved.

To fix this issue I hacked the core module file. Below is the code which I modified.

module/file/file.field.inc (version = "7.28")

line no: 356

-if ($file->status == 0 || !empty($file_usage['file'])) {
+if ($file->status == 0 ) {

Now I am able to save, edit and delete the images.

But to hack the core module, it is not recommended. Can you please help to resolve this issue and it is urgent because we are facing this issue in PRODUCTION environment.

Any help and guide will be highly appreciated!

mohan890’s picture

Hi jmuzz,

I am waiting for your reply .Could you please guide how to resolve the issue.

jmuzz’s picture

Hi mohan890.

Are you seeing the behavior described in the issue summary? If it's something else, please open a separate issue for it so the problem this issue was created for can be resolved here.

Try to find out how to duplicate the problem you are having from a clean install and post the steps.

If you are using entity translation, make sure the settings are correct for the content type, fields, and in the Entity Translation configuration dialog.

capellic’s picture

While I know this isn't the right place to put this (per jmuzz in #67), I don't see that mohan890 opened a case somewhere else. I had the exact same issue as mohan890. But I just wanted to say that I tried the Dev version (2014-Aug-22) and it's working brilliantly! THANK YOU!

RaulMuroc’s picture

Latest dev solves things that beta7 not. Should be a beta8 released!

jmuzz’s picture

Status: Active » Closed (fixed)

Feel free to reopen with steps to reproduce if you see the behavior described in the issue summary with the latest version.

krishna.barman’s picture

Hi,

I'm facing the same issue :
When using an image/file field in a field collection that is added to a node using the field collection field and the 'embed' widget, clicking the "upload" button clears the selected file from the entity instead of uploading and attaching it.

This is happening in PHP 5.5. Its working fine in PHP 5.3.

Im using 7.x-1.0-beta8

Please suggest

krishna.barman’s picture

Status: Closed (fixed) » Active
bisonbleu’s picture

I'm having a similar issue with 7.x-1.0-beta8+11-dev (PHP 5.3.5).

Uploading seems to work in the node edit UI. But when I save, the image is gone.

And I get a PHP Warning:

Warning: array_key_exists() expects parameter 2 to be array, null given in theme_image_formatter() (line 605 of /Applications/MAMP/htdocs/mysite/modules/image/image.field.inc).

Update 1: reverting to field_collection-7.x-1.0-beta7 fixes this issue.
Update 2: I think this is due to the fact that my website is multilingual (there are issues with translations).
Update 3: All is well now after applying 1344672-459.patch to the latest dev.

alemadlei’s picture

So, I tried using latest dev.

* I have a content type which has a field (multiple values) of type field collection.
* The field collection has 4 fields. 3 Textfields and 1 image upload field.
* When creating a node
** I fill the information from the field collection and choose an image.
** I click the Add Another Item link
** Once the new field collection item is added, image is removed.

I tried applying patches, but nothing seems to work at the time. Any pointers of what I should look for wgeb debugging this?

alemadlei’s picture

I just realized that maybe this is working depending on the desired behavior.

* Working scenario:
** I choose a picture after clicking the file upload input.
** If I click the upload button, the image gets properly uploaded.
** Clicking the add more button adds a new field collection and the uploaded image remains there.
* Non workink scenario:
** I choose a picture after clicking the file upload input.
** I click the add more button, a new field collection is added but the selected image is not uploaded and the field is reset.

Maybe this is more related to core's file upload?

  • fago committed cc3ecc1 on 8.x-1.x authored by casey
    #1187010 by casey, tim.plunkett: Store field_collection_item in the...
jmuzz’s picture

Status: Active » Closed (fixed)

It should be working in beta 9 and the latest dev version.

@alemadlei - The ajax replaces the content of the whole multivalue field when the add button is hit. The extra step to upload the file by clicking the upload button is there by design. It's possible the user could select the wrong file in their browser popup, and if that happens it's important that the file doesn't immediately get uploaded to the server. I admit the UI is strange but I'm not sure how it could be fixed. The file shouldn't be uploaded when the user clicks "add more" because it's not clear that they would be sending their file then.

alemadlei’s picture

Hi @jmuzz,

For this site that I'm working on, we wanted the images to auto upload without the user having to click the upload button (we actually hide that button). The desired behavior would have been that if the user chooses a file and clicks the add more button, the image would upload (the desired behavior just for this scenario). The users added new rows, and picked files but they were getting clear every time a new row was added.

I understand that this is by design. Initially I thought that the file should get auto uploaded, because for instance, when you have other field types and click the add more button, the content that you set on the fields remain after the content is replaced.

In the end I did a workaround. If the users picks a file, there's a change handler that would trigger a mouse down on the upload button. If they pick an invalid type, it displays the message. If the file is correct, then it always remains there and they are able to add elements with the add more button.

So for the moment, this workaround seems to work ok for my site, and it doesn't affect the already designed behavior.

Elijah Lynn’s picture

I like the UX of #78, in addition, by default the upload button should be hidden and as soon as there is a change on the filefield it should just immediately upload. Validation handlers should handle appropriately.

atul4drupal’s picture

In My case it was #65 that worked, I know its not ok to hack the core but at times you have to do things that you know are not appropriate but that is the option you have at that time, for you know you had exhausted all possible options you can try, this solved the issue for me.

I tried patch from "https://www.drupal.org/node/1344672#comment-10320327" but they failed to apply.

My setup is multilingual and the Filed Collection Item that I have has several file upload fields:
First time the file saves, but on editing and trying to add another file by replacing the previous file, the file do not saves.

module/file/file.field.inc (version = "7.43") line 363
- if ($file-status == 0 || !empty($file_usage['file'])) {
+ if ($file-status == 0 ) {

To avoid updating this module accidentally, update file modules .info file by removing the information added by drupal.

Thanks.