Problem/Motivation:

This issue is to implement Field Translations support (i.e. support for the entity translation module).

Proposed resolution:

See the attached patch that adds support for field translation. Latest patch: #1344672-437: Field Collection: Field translation (entity_translation) support..

Current Status:

Some users report the latest patch works, so long as you do not make all levels of a nested collection translatable. Users are cautioned that data loss has been reported -- please test carefully.

Remaining tasks:

There are some issues with the patch that need to be fixed. (See comments for details):

CommentFileSizeAuthor
#560 update_errors.png41 KBjmuzz
#560 field_collection-entity_translation_support-1344672-560.patch70.52 KBjmuzz
#550 field_collection-entity_translation_support-1344672-550.patch69.86 KBjmuzz
#543 field_collection-entity_translation_support-1344672-531-without-527.patch69.87 KBjmuzz
#543 field_collection-entity_translation_support-1344672-531-with-527.patch69.96 KBjmuzz
#538 interdiff-1344672-531-with-527-538.txt814 bytesgnucifer
#538 field_collection-entity_translation_support-1344672-531-with-527-538.patch70.53 KBgnucifer
#531 interdiff-1344672-530-531.txt1.22 KBloopduplicate
#531 interdiff-1344672-510-531.txt3.45 KBloopduplicate
#531 field_collection-entity_translation_support-1344672-531-without-527.patch69.87 KBloopduplicate
#531 field_collection-entity_translation_support-1344672-531-with-527.patch69.96 KBloopduplicate
#530 field_collection-entity_translation_support-1344672-530.patch67.95 KBloopduplicate
#530 interdiff-1344672-527-530.txt1.73 KBloopduplicate
#530 interdiff-1344672-510-530.txt2.23 KBloopduplicate
#528 interdiff-1344672-510-527.txt3.25 KBloopduplicate
#527 field_collection-entity_translation_support-1344672-527.patch70.03 KBdewalt
#527 field_collection-1344672-1.png63.6 KBdewalt
#527 field_collection-1344672-2.png29.17 KBdewalt
#518 settings-for-field-collection.jpg131.39 KBwroxbox
#510 interdiff-1344672-504-510.txt1.94 KBchrisdarke42
#510 field_collection_field-1344672-510.patch69.94 KBchrisdarke42
#504 field_collection_field-1344672-504.patch70.32 KBsylus
#489 interdiff-459-489.txt1.35 KBGaëlG
#489 1344672-489.patch69.78 KBGaëlG
#488 seleniumIDE_1344672-486.txt4.02 KBGaëlG
#487 seleniumIDE_1344672-484.txt4.11 KBGaëlG
#487 1344672-487.patch70.11 KBGaëlG
#487 interdiff-459-487.txt893 bytesGaëlG
#484 1344672-484.patch69.78 KBGaëlG
#484 interdiff-459-484.txt1.34 KBGaëlG
#469 fc_debug_second_third_n_fc_in_translated_lang.png44.98 KBjoseph.olstad
#468 Screen Shot 2015-09-18 at 07.45.16.png90.67 KBidflood
#459 field_collection-add_entity_translation_support-1344672-459.patch69.75 KBjoseph.olstad
#459 interdiff_447_to_459.txt1.01 KBjoseph.olstad
#447 field_collection-add_entity_translation_support-1344672-447.patch70.39 KBcolan
#447 interdiff-1344672-437-447.txt2.46 KBcolan
#442 field_collection-entity_translation-modules_dir-1344672-442.zip601.58 KBentendu
#442 field_collection-entity_translation-DB_test-1344672-442.txt2.44 MBentendu
#322 interdiff-315-318.txt628 bytesjwilson3
#322 interdiff-314-315.txt3.08 KBjwilson3
#318 field_collection-et-1344672-318.patch59.67 KBjmuzz
#315 field_collection-et-1344672-315.patch59.63 KBjmuzz
#314 field_collection-et-1344672-314.patch56.55 KBjmuzz
#309 interdiff-304-308.txt1.99 KBjwilson3
#309 field_collection-entity-translation-support-1344672-308.patch59.59 KBjwilson3
#304 field_collection-entity-translation-support-1344672-304.patch57.45 KBjames.williams
#295 field_collection-et-1344672-295.patch1.25 KBopdorp
#292 interdiff-1344672-284-292.txt3.71 KBseanr
#292 field_collection-entity-translation-support-1344672-292.patch59.39 KBseanr
#284 field_collection-entity-translation-support-1344672-284.patch62.21 KBjagilpe
#282 field_collection-entity-translation-support-1344672-282.patch33.7 KBjagilpe
#273 field_collection_field-1344672-273.patch31.62 KBalcroito
#265 field_collection-et-1344672-265.patch30.06 KBjmuzz
#259 field_collection-et-1344672-259.patch29.67 KBjmuzz
#248 field_collection-et-1344672-248.patch27.54 KBxumepadismal
#244 field_collection-et-1344672-244.patch27.54 KBjmuzz
#237 interdiff-1344672-236-237.txt1.65 KBalcroito
#237 field_collection_field-1344672-237.patch29.47 KBalcroito
#236 field_collection_field-1344672-236.patch29.13 KBalcroito
#234 field_collection-et-1344672-234.patch26.84 KBpbuyle
#232 field_collection-et-1344672-232.patch27.13 KBpbuyle
#228 field_collection-et-1344672-228.patch28.51 KBmh86
#227 field_collection-et-1344672-227.patch28.51 KBmh86
#218 field_collection-et-1344672-216.patch28.26 KBjmuzz
#212 screenshot-by-nimbus (1).png26.5 KBRaulMuroc
#210 field_collection-et-1344672-187.patch28.6 KBjmuzz
#198 field_collection_et-2.patch3.36 KBmgifford
#196 field_collection_et.patch3.04 KBtrim108
#187 field_collection-et-1344672-187.patch28.6 KBsylus
#177 field_collection-et-1344672-177.patch28.27 KBjmuzz
#170 interdiff_155-170.txt3.75 KBjmuzz
#170 field_collection-et-1344672-170.patch28.48 KBjmuzz
#163 field_collection-et-1344672-163.patch27.55 KBdshields
#155 field_collection-et-1344672-155.patch26.68 KBjmuzz
#155 interdiff_153-155.txt3.33 KBjmuzz
#153 interdiff_89-153.txt2.4 KBjmuzz
#153 field_collection-et-1344672-153.patch27.47 KBjmuzz
#149 field_collection-et-1344672-89.patch25.22 KBjmuzz
#130 field_collection-1344672.tar_.gz170 KByaoweizhen
#127 field_collection-1344672-108-v2.tar_.gz227.51 KBDarren Clark
#127 field-collection-et-1344672-108-v2.patch3.39 KBDarren Clark
#108 field-collection-et-1344672-108.patch3.38 KBDarren Clark
#101 field_collection-et-1344672-89-2.patch23.33 KBDarren Clark
#89 field_collection-et-1344672-89.patch25.22 KBjmuzz
#87 field_collection-et-1344672-87.patch25.21 KBjmuzz
#87 interdiff_79-87.txt880 bytesjmuzz
#79 field_collection-et-1344672-79.patch27.19 KBjmuzz
#79 interdiff_72-79.txt1.24 KBjmuzz
#72 field_collection-et-1344672-72.patch28.42 KBjmuzz
#72 interdiff_66-72.patch2.38 KBjmuzz
#66 field_collection-et-1344672-66.patch23.2 KBjmuzz
#66 interdiff-64-66.txt1.15 KBjmuzz
#64 field_collection-et-1344672-64.patch23.18 KBjmuzz
#64 interdiff.txt980 bytesjmuzz
#53 interdiff-1344672-45-53.txt1.37 KBacrollet
#53 field_collection-et-1344672-53.patch23.11 KBacrollet
#45 field_collection-et-1344672-45.patch22.51 KBplach
#42 field_collection-17_and_37_complete_2-1344672-42.patch19.06 KBdan.munn
#40 fiel_collection-17_and_37_complete-1344672-40.patch18.62 KBdan.munn
#39 17_and_37-1344672-39.patch18.22 KBjmuzz
#38 17_and_37-1344672-38.patch18.22 KBjmuzz
#37 avoid_malformed_allow_additions-1344672-37.patch1.15 KBjmuzz
#35 stop_saving_through_host_entity-1344672-35.patch638 bytesjmuzz
#26 custom_code-add_child_element.png23.91 KBbroon
#13 field_collection-entity_translation_support-1344672-13.patch19.11 KBmalberts
#17 field_collection-entity_translation-1344672-17.patch19.32 KBmalberts
#15 field_collection-entity_translation-1344672-15.patch19.75 KBmalberts
#8 The-attached-patch-1344672-8.patch21.51 KBayushjn
#324 interdiff-318-323.txt5.52 KBjmuzz
#324 field_collection-et-1344672-323.patch60.47 KBjmuzz
#331 interdiff_324-331.txt1.25 KBjmuzz
#331 field_collection-et-1344672-331.patch61.08 KBjmuzz
#332 smartling.zip462.79 KBSoul88
#334 field_collection-et-1344672-334.patch61.08 KBjmuzz
#334 interdiff_331-334.txt596 bytesjmuzz
#335 field_collection-et-1344672-335.patch63.23 KBjmuzz
#335 interdiff_334-335.txt2.15 KBjmuzz
#355 field_collection-et_support-1344672-355.patch63.21 KBGeorgique
#355 interdiff-335-355.txt1.77 KBGeorgique
#359 interdiff_355-359.txt7.44 KBjmuzz
#362 field_collection-patch_284_applied_to_latest_dev-1344672-301.patch60.52 KBbartvig
#363 field_collection-patch_284_applied_to_latest_dev-1344672-363.patch60.52 KBbartvig
#365 field_collection_patch_284_applied_to_dev-1344672-365.patch60.52 KBjoseph.olstad
#382 field_collection-entity_translation-1344672-382.patch60.6 KBhswong3i
#385 field_collection-entity_translation-1344672-385.patch67.8 KBhswong3i
#391 field_collection-entity_translation-1344672-391.patch67.99 KBkrisgraham
#401 field_collection-entity_translation-1344672-401.patch67.9 KBjkuma
#402 field_collection-entity_translation-1344672-402.patch67.71 KBjkuma
#406 field_collection-entity_translation-1344672-406.patch67.51 KBjoseph.olstad
#406 interdiff_402_to_406.txt1.07 KBjoseph.olstad
#409 field_collection-entity_translation-1344672-409.patch66.02 KBLendude
#409 interdiff-1344672-406-409.txt1.17 KBLendude
#410 field_collection-entity_translation-1344672-410.patch68.01 KBLendude
#417 field_collection-entity_translation-1344672-417.patch66.84 KBomarlopesino
#417 interdiff-1344672-410-417.txt929 bytesomarlopesino
#419 field_collection-entity_translation-1344672-419.patch66.81 KBomarlopesino
#419 interdiff-1344672-410-419.txt901 bytesomarlopesino
#421 field_collection-entity_translation-1344672-421.patch70.79 KBomarlopesino
#421 interdiff-1344672-410-421.txt3.16 KBomarlopesino
#423 field-collection-tests.mysql_.zip106.55 KBomarlopesino
#426 interdiff-1344672-421-426.txt1.59 KBJohnny vd Laar
#426 field_collection_field-1344672-426.patch76.79 KBJohnny vd Laar
#428 field_collection_field-1344672-428.patch68.94 KBJohnny vd Laar
#430 field_collection_field-1344672-430.patch70.93 KBJohnny vd Laar
#437 interdiff-1344672-430-437-do-not-test.patch1.85 KBdas-peter
#437 field_collection_field-1344672-437.patch70.86 KBdas-peter
#441 field_collection_field-1344672-441-interdiff.txt1.27 KBkallehauge
#441 field_collection_field-1344672-441.patch70.1 KBkallehauge
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Sborsody’s picture

Entity translation doesn't seem to really work yet. See #1366220: Field collection translatable Field language for setHostEntity.

klonos’s picture

Title: Field translation? » Field Collection: Field translation (entity_translation) support.

When I try to enable entity translation for the "Field collection item" (under /admin/config/regional/entity_translation), I get these errors:

The configuration options have been saved.

* Notice: Undefined index: base path in entity_translation_menu_alter() (line 162 of /var/www/my-site/sites/all/modules/entity_translation/entity_translation.module).
* Notice: Undefined index: access callback in entity_translation_menu_alter() (line 207 of /var/www/my-site/sites/all/modules/entity_translation/entity_translation.module).
* Notice: Undefined index: access arguments in entity_translation_menu_alter() (line 207 of /var/www/my-site/sites/all/modules/entity_translation/entity_translation.module).
* Warning: array_merge(): Argument #2 is not an array in entity_translation_menu_alter() (line 207 of /var/www/my-site/sites/all/modules/entity_translation/entity_translation.module).

Is this the right issue to follow for this problem or should I try my luck in #1366220: Field collection translatable Field language for setHostEntity or elsewhere or even file a separate issue?

klonos’s picture

Applying the patch from #1366220-4: Field collection translatable Field language for setHostEntity doesn't fix the errors I mention above.

heretic381’s picture

Any news for this issue?

mducharme’s picture

Component: Documentation » User interface
Category: support » bug
Priority: Minor » Normal

Can I suggest an approach of NOT LISTING entities that ET does not support so that we don't keep getting trapped? Can ET check for support while getting the list of entities enabled in this checklist?

I considered creating a new issue out of this, but hoping for feedback first.

dshields’s picture

Sounds like a great idea to me!

plach’s picture

Yes, I've been considering something like that for a while. I've just had no time to work on it yet...

ayushjn’s picture

Status: Active » Needs review
FileSize
21.51 KB

The attached patch adds the required support of field translation to this module. Please make sure that all the required modules, especially entity translation and field translation are enabled and properly configured.

dreizwo’s picture

Thanks a lot for this patch. In my enviroment my field_collection is a bundle of several fields with entity_translation enabled. The field_collection is embedded in a node (unlimited elements). If you create a new language depended node, all nested field elements will be still language independent.
After debugging a while, I added this quick hack(!) to field_collection_field_presave method- works for me now as expected. Perhaps someone has a better idea...

function field_collection_field_presave($entity_type, $entity, $field, $instance, $langcode, &$items) {
    foreach($items as &$item){
        // In case the entity has been loaded / created, save it and set the id.
        if(isset($item['entity'])) {
            if(!empty($item['entity']->is_new)) {
                $item['entity']->setHostEntity($entity_type, $entity, $langcode, FALSE);
               //HACK - ENSURE THAT ALL NESTED ELEMENTS USE THE GIVEN LANGCODE - EVEN ON CREATE 
                if($langcode!=LANGUAGE_NONE) {
                    // the current field is the bundle
                    $bundle = $field['field_name'];
                    $field_instance = $entity->$bundle;
                    $options = array(
                        'deleted' => FALSE,
                    );
                    $field_entity_fields =
                            _field_invoke_get_instances($item['entity']->entityType(), $bundle, $options);
                    $field_entity_items = &$field_instance[$langcode];
                    foreach($field_entity_items as $delta => $field_entity_item){
                        $field_entity = $field_entity_item['entity'];
                        if(is_object($field_entity)) {
                            // Merge default options.
                            $field_info = $field_entity->fieldInfo();
                            foreach($field_entity_fields as $field_entity_field)
                            {
                                $field_name = $field_entity_field['field_name'];
                                if($field_info['translatable']) {
                                    //change to $langcode
                                    $value = $field_entity->$field_name;
                                    if(isset($value[LANGUAGE_NONE])) {
                                        $value = $value[LANGUAGE_NONE];
                                        $field_entity->$field_name = array($langcode => $value);
                                    }
                                }
                            }
                        }
                    }
                } /// HACK - END
            }
            $item['entity']->save(TRUE);
            $item = array('value' => $item['entity']->item_id);
        }
    }
}
inolen’s picture

Today I ran into a problem using field_collection with entity_translation.

It appears that entity translation makes the assumption inside of entity_translation_entity_form_get_handler() that there will be only one EntityTranslationHandlerInterface per node form by caching off the result in $form_state['storage']['entity_translation']['handler'].

This of course breaks down when you have a field collection entity which needs a different EntityTranslationHandlerInterface instance. Has anyone looked into this? I temporarily just disable the caching in the entity_translation module.

carn1x’s picture

Patch in #8 doesn't apply to latest stable or dev for me.

bforchhammer’s picture

Status: Needs review » Needs work

NW based on #12. Also, there's at least 4 different issues (including this one) that are concerned with integrating ET and field collection, see #1568618-6: Field Collection integration.

malberts’s picture

Preliminary support for entity_translation.

The specific use case where I tested:
A bean entity containing an unlimited field_collection field.

The bean is translatable but the field_collection field is not.
The field_collection_item entity for that field is translatable.

In this scenario you can translate whatever is on the bean but the values (entity ids) for the field_collection field are shared between translations. These field_collection entities are translated when viewing the admin page of the bean. The field_collection field is set to display as "Field collection items" which renders links for each item.

Example:
On the host entity:
field1: [en]="text", [es]="texto
field2: [und]=collection(id1, id3, id5)

collection_id1: ...translations...
collection_id3: ...translations...
collection_id5: ...translations...

There is another scenario which people might want based on UX where the field_collection fields are translatable with the intent of doing the field_collection_item translations at the same time as translating the host entity. However, technically this is an incorrect usage (for that purpose).

Example:
On the host entity:
field1: [en]="text", [es]="texto
field2: [en]=collection(id1, id3, id5), [es]=collection(id2, id4, id6)

This is because you are actually allowing a different collection per language. There might be valid cases where you would want to allow different collections per language where you do (not) want to have translations of the field_collection_items themselves. I did not address that scenario in this patch, but it might be related to #1865244: Allow multiple translation handlers on the same form

This patch adds
- default paths for field_collection_items
- entity_translation support
- paths for Devel output
- 'Translate' link when displaying field collection as "Field collection items"
- #1683784-42: Field Collection entities are untranslatable because they do not define valid base path

I am not sure if there are also entity_translation issues that we need to look at for this.

Component: User interface » Code

The last submitted patch, field_collection-entity_translation_support-1344672-13.patch, failed testing.

malberts’s picture

Status: Needs work » Needs review
FileSize
19.75 KB

Trying a differently generated patch, otherwise I'm not sure what that failure means.

Status: Needs review » Needs work

The last submitted patch, field_collection-entity_translation-1344672-15.patch, failed testing.

malberts’s picture

Status: Needs work » Needs review
FileSize
19.32 KB
klonos’s picture

eristoddle’s picture

That patch semi-works. And seeing it, I realized how involved this whole fix is.

For example, I can create the field collection in English and it comes back up in the form when I edit it. That's a new one. Was used to seeing blank fields.

But when I go create a Spanish translation, the field collection is stored as spanish, but each of the fields that are in it are English. I checked the database. For some reason these do come up in the form under the Spanish tab, but are not displayed under Spanish in the frontend which makes sense.

So at the end of creating a record using this patch, I have:

entity
field-collection - en
field en
field en
field-collection - es
field en
field en

malberts’s picture

@eristoddle: I assume you have the field_collection field set as translatable?

I tried to explain the theoretical/technical issue with that in #13. I think this scenario causes some strange behaviour which I did not look at in this patch. I believe the Inline Entity Form issue #1545896-19: Add Entity Translation integration contains a general description of what's wrong here too.

Generally speaking, if you make the field_collection field translatable then what you are actually saying is that you want different collections per language and not that you want to translate the individual field collection items. This is as opposed to having a shared, language-neutral collection where the individual items are localised. However, I do not know what your desired outcome is.

Depending on what exactly you want to do, my advice would be to set the field_collection field as not translatable and then translating the field_collection_items separately. However, that might not be possible UI-wise depending on your host entity. In my case, the Bean host entity has its own admin page, so I make it display the field collection with links which gives me a translate link for each item. Note that I cannot translate the individual field collection items when translating the host entity, I must use the links.

We definitely need more eyes here and it would be nice if some higher-ups can give some thoughts. The problems I mentioned above are my understanding of what's going on here, but I might be wrong.

broon’s picture

Thanks for that patch, malberts. This seems very interesting and your patch (#17) applied fine.
However, I am not sure how to translate any field collection item. I don't see a translate link. What am I missing?

My setup is as follows:

  • Content type "Overview" with a field_collection field (unlimited).
  • Field collection "Overview item" with a text field (translation needed) and an image field (no translation necessary).

The CT "Overview" is translatable. Its field_collection field is not translatable. Field collection entities are translatable (entity translation module).

The text field within the field collection should now be made translatable, right?

Thanks in advance,
Paul

malberts’s picture

@Paul.B, this is were the UI problem comes in. I don't currently have a solution for translating the field collection items while translating the host entity. The patch implements the necessary functions to allow translating the individual field collection items on a one-by-one basis. This is not ideal from a UX perspective, but there are three ways that you can do this:

1. Display formatter on host entity

Set your field_collection field's display formatter as either "Links to field collection items" or "Field collection items". When you select that in the Field UI it will show you a summary text of "Links: Add, Delete, Edit, Translate". This will result in links being output for each item.

This method will only work if there is a separation between the admin and non-admin display of your content. In my case, I have an admin and user-facing display, allowing the former to use that field formatter while the latter uses a View to display a slideshow. In your case, using a Node you will most likely only have one display.

2. View

Build a View using "Field collection item". You can customise it as you want, but include the "Field collection item: URL" field. This will give you a link to get to the individual entity page where you will then find a Translate tab.

Currently there isn't a Views field that will output the Edit/Translate links for you, so you will have to make a custom link if you want to link directly to the translation page. You could try the path "field-collection-item/[item_id]/translate" (where [item_id] is the field collection item ID token) which uses the new default path coming from that patch. That should take you to the translation screen directly from the View.

3. Dedicated translation module

A dedicated translation workflow module like Translation Management Tool will expose your field collection item entities on an overview screen indicating which languages are outstanding. However, if you do not need this level of translation management, then this might be overkill.

Let me know if you have success with any of these methods.

cossimo’s picture

@malberts: I have been monitoring this issue in various threads for about a year now, and your explanation in #13 finally gets to the nut of the problem. Thanks for that!

With that said, given the structural issues you outline and address with your patch, and the subsequent UI issues that result, it begs the question of how useful field collections are on an entity translated website. That is, if field collections can't be translated *directly* on a node-based host entity along with the other field entities, then in a lot of (and perhaps most) instances, a site builder would be better off creating a content type for a group of fields, create a view for displaying them, and relate them back to the host entity using entity reference. This avenue is made even more compelling by the ongoing extensibility problems (at least I consider them problems) of the field collection module and the patches required to integrate it with modules such as node clone and feeds.

So, I guess my burning question is, is it ultimately possible for field collections to be translated directly (without linking out) on a node-based host entity--thus, making it much easier for front end developers such as myself to accommodate a bunch of relatively non-technical content editors and maintainers? Or is the prospect of accomplishing this so difficult and remote that it will likely never be part of the module?

The main reason I ask is that, if the project isn't insurmountable, I might be able to convince my company to subsidize work on this. Otherwise, I'll probably have to abandon the field collection module in favor of other options.

malberts’s picture

@cossimo: OK, first of all, I am not an expert on what I am about to say, so if somebody with more experience has something else to say I'd be glad to change my mind :).

TL;DR version: There's no way to do inline/embedded translation until Entity Translation supports it. If your company has time/money to throw at this issue, I suggest you get in contact with plach (his progress: #1865244-3: Allow multiple translation handlers on the same form). I do not know the effort needed to get this done, but plach is the main Entity Translation developer and he says its a tough task.

Long version:
As I understand it, the root of this problem goes beyond Field Collection. The problem is that the Entity Translation functionality necessary to allow "inline entity translation" is not there yet, but it is being worked on: #1865244: Allow multiple translation handlers on the same form
Until that is solved I do not think there is a solution - only the workarounds I mentioned in #22.

There is work under way to solve that issue for Inline Entity Form: #1545896: Add Entity Translation integration but it is not done yet.
Which brings me to my next point. There is an alternative solution to Field Collection in the form of using Entity Reference and Inline Entity Form. As far as I know Field Collection is older than the mentioned projects and thus implemented things in its own way.

Technically, a Field Collection field references the Field Collection Item entity and presents it in an embedded form. As far as I'm concerned (but just speculating) Field Collection-like functionality can be implemented using Entity Reference and IEF with some glue code. The main difference between FC and plain ER+IEF is that FC gives you an entity type by default and creates the bundle type when you create an FC field. ER+IEF is generic and so by default you will need a separate entity type and create the bundles manually before creating the fields. An alternative FC implementation would provide a similar entity type by default but then create the new bundle types when you create the field (similar to what it does now). This will allow FC to piggyback on the work of those modules meaning there's less to worry about here.

If the data you are capturing is very complex or represent something entity-like, it would be best to define a custom entity type. ECK does not support entity translation yet (#1798646: Make ECK entities translatable (entity translation integration).) so your only option there is to define the entity type in code.
If what you are referencing is Node-like, i.e. you want all the extra information (like path, published, sticky, etc.) associated with Nodes, then you can use Nodes. But using a Node for non-Node data with just a few fields means you get some baggage. Whether this is a performance issue in your case depends, but it does add unnecessary overhead.
If you are capturing data for a "common" use case, maybe have a look if there isn't a module that already defines an entity type for it. For example, if it is commerce-related related, try Commerce. If it is CRM-related, look at RedHen CRM, Party, CRM Core or maybe just a custom user Profile. Or maybe the data can be captured by a single field: like price+currency in Commerce, postal address in Address Field or physical properties in Physical Fields.
However, if what you are capturing is just a few fields that does not fit into any existing use case then what you use right now depends on your time I guess. I.e. whether you want to code a custom entity, deal with other FC issues, (ab)using nodes, etc.

Having said all that, you still won't have inline/embedded entity translation with the ER+IEF method. However, once those modules get the integration you will be ahead because it would then still have to ported to FC.

cossimo’s picture

@malberts: Much obliged. This is very helpful!

broon’s picture

Hey malberts,

I tried quite some different ways to accomplish the FC effect and just want to share my setups.

In the first project I am using FC with your patch. It actually turned out, that my problem was related to multilingual setting for the homepage. When that was fixed, it worked as intended. Both languages just have their own sets of FC items as pointed out in your last example in #13.

For the second project I thought of ways to get roughly the same effect with my "default tools", such as different content types and views. Referring to my content types from #21, "Overview" is a normal node type with title and body text. Then I created a second node type "Overview item" which has at least an additional entity_reference field pointing to "Overview" nodes. By either using view blocks or views and panel node pages I can then display all "Overview items" along with the "Overview" node. Either way, I am adding a custom footer (or header) text to the displayed view which contains a link to create a new "Overview item". The icing on the cake is provided by Entityreference prepopulate module which allows me (well you guess it) to prepopulate the entityreference field with the correct "Overview" node.
However, this method still is not really easy-to-use for a default editor.

So, for the third project I actually turned the system around and added the entityreference field to the parent "Overview" node type. With some custom code, the node edit/add form is altered and sports a link to create a new child element from within the parents edit form. By clicking the link (as seen in the attached image), the user is redirected to the "Add Overview item" page. After saving that child element, the user has to translate the item right away. Only then, the user is taken back to the "Overview" edit page and may even insert the just created item by clicking another new button.

I think, none of the three possibilites is THE perfect solution, but I have all three of them running on production site for three different projects. In each case the respective solution fits the client. Thanks go to both of you, malberts and cossimo, for giving me some ideas to work on.

cossimo’s picture

I've been playing with the #17 patch, and it seems to work well, except for strange behavior when I try to add multiple sets of values.

For example, let's say I have a content type with field collection Xn, which is set to accept unlimited values and for which translatability is disabled. Within field collection Xn, there are several associated fields (let's say Xnx, Xny, and Xnz), all of which are set to translatable.

If I add one set of values to field collection Xn and save it, everything works fine. The values are appear on the node, in any views I create using the fields, etc. And all the subfields Xnx, Xny, and Xnz can be translated with no problems.

The hitch comes when I try to add multiple values for field collection X. For example:

Field Collection Xn
-X1
--X1x
--X1y
--X1z
-X2
--X2x
--X2y
--X2z
-X3
--X3x
--X3y
--X3z
etc...

Each time subsequent sets of values are added on the node edit page (for example, X2 and all its subvalues), the previous values (X1x, X1y, X1z) disappear. They don't necessarily disappear from the database because if you (have not made any of the subfields required and can) save the node, all the values appear correctly (on the node page and in any views). However, they do not appear when editing the node -- or I guess more accurately, they appear and disappear in different patterns as new values are added.

I have noticed some duplication in views when displaying translated subfields, but have not delved far enough in to this yet to see whether setting up field language filters or adjusting the query settings will have an effect . Edit: This views duplication can indeed be handled with field language filters and setting query settings to distinct.

bdecarne’s picture

malberts, your patch #17 saved my life. Field collection is a very good module, support for ET is criticial.

csedax90’s picture

the path doesn't work for me... how can i configure my node type and all fields of field collection to work together?

steinmb’s picture

@CRY_X2 pls. provide more info about your setup, what you were trying to do, what you expected to happen and what did happen. Simply writing, it does not work, is not very helpful :)

csedax90’s picture

The modules

I'm using the ET dev, the entity dev and the Field Collection dev with path #17

The goal

I must do a simple slideshow where a slide have one image, one description e one text field... the image is unique for all languages, but the description and the text must be translated

Current setup (doesn't work)

I've created a new content type called Slideshow, translatable with ET. In this content type i've a Field Collection field who is translatable.
In the Field Collection settings i've created an image field (untranslatable), a long text field (translatable) and a text field (translatable).

The problem

I can upload the image, set different text for language but when i see the content all translatable fields doesn't appears, and if a try to show the fields with a view it shows nothing...

thanks to all who can help me

appzella’s picture

I installed the patch an everything but as soon as I add a field collection field in a content type I become the following error message when I want to ad a content of this content type.

Fatal error: Class 'EntityTranslationFieldCollectionItemHandler' not found in /Users/Username/Sites/acquia-drupal/sites/all/modules/entity_translation/entity_translation.module on line 1710

appzella’s picture

I run the patch again, it seems to work now.

malberts’s picture

For anyone who gets the same issue as appzella, remember to flush your caches after patching.

@CRY_X2: please have a look at my posts (starting at #13) in this thread. Basically, it would be better if you set the field_collection field as not translatable and the field_collection entity as translatable. You won't be able to translate the slides on the Slideshow node, but you will be able to translate them separately (#22).
I tested it with a similar setup for a slideshow, however, just instead of a Slideshow Node I used a Slideshow Bean. In my case everything worked.

jmuzz’s picture

#17 mostly worked for me. I had a problem using the individual field_collection_item forms causing an EntityMalformedError. I'll attach the one liner that I used to fix it but I don't know if it's the best solution.

Some details: The default behavior of field_collection has the save function delegating to the host entity. This may be a problem with entity translation but I fixed it by telling field_collection to just save itself when accessed through the individual forms. It turns out that path auto and some rules I was using were reacting to node save events and they were trying to do some of their own translating. The problem seems to start in entity_translation_language() in entity_translation.module where it gets the translation handler for the current form and then tries to apply the current entity to it... In this case the current entity is the node holding the field_collection but the form was for the field_collection_item so the handler expects a field_collection_item entity type and the call to setEntity triggers the acception somewhere down the line.

Status: Needs review » Needs work

The last submitted patch, stop_saving_through_host_entity-1344672-35.patch, failed testing.

jmuzz’s picture

My last patch was a bust, it couldn't handle new field_collection_items since it wasn't saving the host entity.

This one involves a hack to unset the reference to the form after all the data is collected and the node is about to be saved, that way entity_translation won't get the wrong translation handler from the form.

It also checks to see if the field_collection itself is translatable before setting a langcode for a new field_collection_item . This seems to be necessary to get a new field_collection_item to save if the item itself is not translatable but the fields in it are.

jmuzz’s picture

FileSize
18.22 KB

Probably better to include #17 in the patches I post since they rely on it. They might have a chance of passing tests then. Speaking of which, anybody understand why my last patch was ignored?

jmuzz’s picture

Status: Needs work » Needs review
FileSize
18.22 KB

Oh I get it I have to set the status. Guess I didn't really have to upload it again either.

dan.munn’s picture

Your compiled patch doesn't include the class definition for the Entity translation handler, which is included in patch #17 (the whole
includes/translation.handler.field_collection_item.inc added in this patch is omitted in yours). I've included this and re-submitted patch.

Status: Needs review » Needs work

The last submitted patch, fiel_collection-17_and_37_complete-1344672-40.patch, failed testing.

dan.munn’s picture

Status: Needs work » Needs review
FileSize
19.06 KB

Apologies, did not spot that the previous patch generation contained errors :/

murtza’s picture

#42: field_collection-17_and_37_complete_2-1344672-42.patch queued for re-testing. clicked by mistake

plach’s picture

Assigned: Unassigned » plach

I am working on this.

plach’s picture

Assigned: plach » Unassigned
FileSize
22.51 KB

Here is a patch providing support for translation with both the standalone UI and the embedded widget. It depends on #1865244-17: Allow multiple translation handlers on the same form. It's heavily based on the previous ones but there are a lot of changes so I'm not posting an interdiff.

zeno129’s picture

I am having an issue related to the patch included above.

Exception: The host entity cannot be changed. in FieldCollectionItemEntity->updateHostEntity() (line 384 of /var/www/mapr/sites/default/modules/field_collection/field_collection.module).

I posted the details here: https://drupal.org/node/2059763

interdruper’s picture

I am testing patch #45 with patch #26 from #1865244: Allow multiple translation handlers on the same form previously applied.

The translated values of field collection items are stored correctly, but they are shown only when default (original) language is selected.
I tested several display formatters in the field collection's fields, with the same result.

Retested over a brand new installation, and now everything works ok. I use a Field collection inside an generic entity, with 2 languages. Translations are stored and displayed correctly inside the field collection. Be sure that you have enabled entity translation also for the field collection itself, not only for its translatable fields.

plach’s picture

@zeno129:

Please don't open bug reports for code that has not been committed yet, let's stay focused here.

@interdruper:

The translated values of field collection items are stored correctly, but they are shown only when default (original) language is selected.

This patch does not cover rendering, if you have problem with displaying the items it might a different issue. Can you reproduce it on a clean install?

plach’s picture

Copying the bug report from #2059763: Unable to translate a field collection when translating the parent node:

I am getting the following error when I try to save a translation for a node that has unlimited field collections:

Exception: The host entity cannot be changed. in FieldCollectionItemEntity->updateHostEntity() (line 384 of /var/www/mapr/sites/default/modules/field_collection/field_collection.module).

I have the following relevant modules enabled:

  • field_collection 7.x-1.0-beta5+1-dev (2013-Apr-12)
  • entity_translation 7.x-1.0-beta3+1-dev (2013-Jul-24)
  • i18n 7.x-1.9

With the following patches:

Steps to reproduce issue:

  1. Create content type with an unlimited collection field
  2. Create a node in language 1 (Ex. English)
  3. Click on translate, modify content for language 2 (Ex. Spanish) and hit save

Notes:

  • When I click on translate all the field values from the other language come pre-filled, including those of the field collection.
  • If I click on 'eliminate' for each field collection, add them again for the translation and click save, there are no errors.

I believe this might have something to do with the translation's field collections still referencing the IDs for the other field collections in the original node. I am trying to find the code that pre-fills the field collection values for the translation to verify my hypothesis.

plach’s picture

The exception aboe is thrown when the host entity object passed on submit is different (has a different ID) from the one set when building the form. Maybe one of the two is empty in your case?

mavrom’s picture

I really do not remember where I found this patch, however if I replace field_collection_field_presave function in sites/all/modules/field_collection/field_collection.module with the following one, then concerning translation the Field Collection Module behaves as expected

function field_collection_field_presave($host_entity_type, $host_entity, $field, $instance, $langcode, &$items) {
  foreach ($items as $key => &$item) {
    // In case the entity has been changed / created, save it and set the id.
    // If the host entity creates a new revision, save new item-revisions as
    // well.
    if (isset($item['entity']) || !empty($host_entity->revision)) {
      if ($entity = field_collection_field_get_entity($item)) { 
        if (!empty($entity->is_new)) {
          $entity->setHostEntity($host_entity_type, $host_entity, LANGUAGE_NONE, FALSE);
        }
        else {
          if ($host_entity_type == 'node' || $host_entity_type == 'field_collection_item') {
            // Reset item_id when it's a new translation.
            if (isset($entity->nid) && !$entity->nid) {
              $item['entity']->item_id = '';
            }
            else {
              $query = new EntityFieldQuery();
              $query->fieldCondition($item['entity']->field_name, 'value', $item['entity']->item_id, '=');
              if (isset($entity->nid)) {
                $query->entityCondition('entity_id', $entity->nid, '!=');
              }
              $result = $query->execute();
              // Reset item_id if another node with the same instance exists.
              if (!empty($result)) {
                $item['entity']->item_id = '';
              }
            }
          }
        }

        // If the host entity is saved as new revision, do the same for the item.
        if (!empty($host_entity->revision)) {
          $entity->revision = TRUE;
          $is_default = entity_revision_is_default($host_entity_type, $host_entity);
          // If an entity type does not support saving non-default entities,
          // assume it will be saved as default.
          if (!isset($is_default) || $is_default) {
            $entity->default_revision = TRUE;
            $entity->archived = FALSE;
          }
        }
        $entity->save(TRUE);

        $item = array(
          'value' => $entity->item_id,
          'revision_id' => $entity->revision_id,
        );
      }
    }
    else {
      // Prevent collections from being attached to newly translated content
      // when the field collection widget is set to hidden.
      if ($host_entity_type == 'node' && isset($entity->translation_source)) {
        unset($items[$key]);
      }
    }
  }
}
acrollet’s picture

For reference - the patch in #51 is from #1316162: Support content translation and host entity cloning

acrollet’s picture

I found that the exception mentioned in #49 is thrown when a field collection item is marked as archived. Updated patch that

a) moves the code that checks for a non default revision above the call to updateHostEntity, and
b) modifies it to also check the host entity for a is_new_revision property, to handle what the bean entity type's behavior.

interdiff + patch attached. Needs review since I'm not sure if there could be other adverse consequences to changing the execution order in the presave hook. Works for me in my testing.

klonos’s picture

adinac’s picture

@plach In #45 you said that the patch would allow to translate field collection items on the host entity form (in the embedded widget). Can you please describe the steps/settings needed to make this work. Thanks.

plach’s picture

@adinac:

Well there are many use cases, but I guess the most common is leaving the field_collection field untranslatable and making the "Field collection item" entity type translatable in the Entity Translation settings. Obviously at least one field on the field collection item needs to be translatable.

You need the latest ET dev release.

klonos’s picture

...leaving the field_collection field untranslatable and making the "Field collection item" entity type translatable in the Entity Translation settings. ...

Well, to begin with let me say that this is at least something (which honestly is better than not having the feature at all). But, it doesn't make sense UX-wise because we make people go pogo-sticking looking for the "proper" place to enable settings. Ideally, setting the field_collection field to be translatable would (somehow) also make the "Field collection item" entity type translatable (and the other way 'round).

...Obviously at least one field on the field collection item needs to be translatable.

Again ideally one would expect something like the translatabily settings to be disabled with a note saying that "At least one field on the field collection item needs to be translatable." along with a link to the admin page to do precisely that. Then, once at least one field is set to be translatable, auto-return the user (or provide a link) back to where they were in order to complete the main task they set of to accomplish in the first place.

Anyways, as I already said, I'll take something then nothing at all and I honestly appreciate the work behind this. Thanx.

adinac’s picture

I have a translatable entity with a field collection field with unlimited values. The field collection entity is translatable, it also contains some translatable fields and the field collection field on the host entity is left untranslatable.

The translation of the field collection on the host entity form works ok but i noticed that when creating the entity, the first time you click on the "Add another item' button and there is a single element for the field the translatable fields on the field collection lose their values. I couldn't figure out why this happens yet. Did anyone else ran into this problem? Some possible fixes?

Thanks.

Maico de Jong’s picture

#53 is working for me, few things to look after:

I have a field collection with two fields, one translatable.
Field collection field in host entity is not set to translatable

- In Entity Translation settings don't check 'Hide shared elements on translation forms' for the host entity since the field collection field is not translatable. (only fields inside the field collection) It will hide the field collection fields, maybe there is a solution to this because leaving it unchecked also shows other untranslatable fields you might not want.
- All fields inside the field collection get '(all languages)' added to the label, this probably has something to do with above.

Cyclodex’s picture

Hy all.
I had also huge problems with setting up the field_collection with entity translation. Right now it seems that latest code and the patch from #53 is working out here.

Just one issue I have: Because I am not running PHP 5.3 the anonymous function is a little problem in this patch.
uksort($operations, function($a, $b) use ($keys) { return $keys[$a] - $keys[$b]; });
As Drupal supports basically:

Drupal 7: PHP 5.2.5 or higher (5.3 recommended).

I would suggest that we change the function to something compatible to PHP 5.2.5

I am not sure if it would be something like this :

function _doThat($a, $b) {
  global $keys;
  return $keys[$a] - $keys[$b];
}

uksort($operations, "_doThat");
  • I also don't really get what it is doing exactly :) sorry for that...
  • So then we could name the function a bit better than I did
  • I am also unsure about the global $keys, perhaps you find a better solution!

Thanks for the instructions at #56 which helped a lot, I think we should make this more clear to the people out there, trying to use field collection and content translation...

fago’s picture

+++ b/field_collection.module
@@ -918,6 +974,14 @@ function field_collection_field_presave($host_entity_type, $host_entity, $field,
+          $entity->updateHostEntity($host_entity);

That's quite a big change compared to the previous "the host cannot change". So I'm wondering, is that really necessary? Does not the host entity stay the same? *confused*

The patch is rather big, but seem to contain overall good stuff. I need to take a closer look once we've figured that update stuff out.

fago’s picture

Status: Needs review » Postponed (maintainer needs more info)
plach’s picture

Status: Postponed (maintainer needs more info) » Needs review

So I'm wondering, is that really necessary? Does not the host entity stay the same? *confused*

IIRC after submitting a form the host entity object and the one processed and passed around to hooks are different, due to serialization I think, hence we have an outdated host entity object. At least this is what I experienced while writing the patch.

jmuzz’s picture

I found that #53 caused some incompatability with workbench moderation. The problem is that when a field collection item doesn't exist on an entity's default revision getHostDetails will not set hostId but hostRevisionId instead. This can happen for example if you add an item to a new draft without publishing it yet. I modified the check in updateHost to handle this.

(Note this isn't the only change needed to make Field Collection work with Workbench Moderation, see #1807460: Field collection doesn't play nice with workbench moderation (patch) and #1781190: Field Collection saved on presave as well)

Status: Needs review » Needs work

The last submitted patch, field_collection-et-1344672-64.patch, failed testing.

jmuzz’s picture

Status: Needs work » Needs review
FileSize
1.15 KB
23.2 KB

Oh I see #1781190: Field Collection saved on presave has been applied, that's good news.

Here's a version of the patch that should be compatible.

Pere Orga’s picture

Status: Needs review » Needs work

I see an extra line in patch #66:

         'edit' => t('Edit'),
+        'translate' => t('Translate'),
+        'translate' => t('Translate'),
Pere Orga’s picture

I've been testing patch #45 and seems that is working fine with multiple values. I'm using:

Field collection 7.x-1.0-beta5+1-dev (latest dev)
Entity Translation 7.x-1.0-beta3+7-dev (latest dev)
i18n 7.x-1.10

I'm not using revisions though.

agoradesign’s picture

The anonymous function in the following line of the patch breaks PHP 5.2 compatibility:

<?php
uksort($operations, function($a, $b) use ($keys) { return $keys[$a] - $keys[$b]; });
?>

edit: just saw that comment #60 mentioned that already and explained the problem in a very detailled way

agoradesign’s picture

I've found a severe bug in the patch of #66. Actually, it was introduced in #45, and I'm wondering why nobody complained about this:

+  public function getLanguage() {
+    $langcode = $this->entity->langcode() ?: LANGUAGE_NONE;
+    // Use the field language as entity language. If the current field is

the second line must be of course:

$langcode = $this->entity->langcode() ? $this->entity->langcode() : LANGUAGE_NONE;

Actually, it is not real bug, but another PHP 5.3 construct, which is indeed not necessary to write this shorthand form

plach’s picture

I've found a severe bug in the patch of #66. Actually, it was introduced in #45, and I'm wondering why nobody complained about this

I guess because that line is perfectly fine in PHP 5.3 :)

I am sorry, I've not being using PHP 5.2 from years now...

jmuzz’s picture

Added suggestions from #60, #67, and #70.

About #60, is there some reason asort($operations) wouldn't work?

jmuzz’s picture

Status: Needs work » Needs review

Status: Needs review » Needs work

The last submitted patch, interdiff_66-72.patch, failed testing.

plach’s picture

Status: Needs work » Needs review
Pere Orga’s picture

Status: Needs review » Needs work

After further testing #45 (and #72) I've seen that cannot get it working properly. It seems to work fine if you save the node before adding new field collections, but if you translate a node and try to add new field collections before you save it, some of the existing field collections get lost. It's weird because I remember having this working before...

agoradesign’s picture

Caution! The patch from #72 is accidentially reverting this commit: http://drupalcode.org/project/field_collection.git/commit/0fd332e

agoradesign’s picture

I can confirm, that the patch basically works as expected for me. I did not dare to try adding a collection on an unsaved translation as mentioned in #76. I've just translated existing field collections, without having any problems so far.

There are two usability issues left, that are already mentioned in #59. Especially the "all languages" label is very confusing. But I'm glad to see the basic translation functionality working, so thumbs up for this :)

jmuzz’s picture

Whoops. Fixed #77.

I agree about the usability issues, they should be fixed as well.

mahmost’s picture

Status: Needs work » Needs review
jmuzz’s picture

I took a good look at how the UI stuff mentioned in #59. I don't think the user interface changes can be handled by field collection. If this patch gets applied then maybe some changes to entity translation could be accepted to solve #59.

#1282018: Improve UX of language-aware entity forms seems like the place to go for that.

If you want a quick way to force field collections to show up with the "Hide shared elements on translation forms" option enabled then you probably shouldn't do this because setting #access to true after something else makes it false is insecure.

function field_collection_form_alter(&$form, &$form_state) {
  _field_collection_show_translatable($form);
}


function _field_collection_show_translatable(&$element) {
  foreach (element_children($element) as $key) {
    if (!isset($element[$key]['#type'])) {
      _field_collection_show_translatable($element[$key]);
    }
    else { 
      $field_info = field_info_field($key);
      if ($field_info['type'] == 'field_collection') {
        $element[$key]['#multilingual'] = true;
        $element[$key]['#access'] = true;
      }
    }
  }
}
jmuzz’s picture

I've done some investingation about updateHostEntity and I have found that for me at least it is necessary. I suspect this may be related to workbench moderation and I haven't done tests without it, but what I found was that without the call to updateHostEntity the field collection item would not get saved with the correct revision. In particular I found this line was required:

$entity->{$this->field_name}[$this->langcode][$delta]['entity'] = $entity;

The one that sets $this->hostEntity didn't seem to make a difference.

I tried removing this line and creating a new draft of a node and adding an item to one of its field collections. The new field collection item appeared immediately on the published version of the node (it shouldn't) as that was the revision id that was entered into field_data_(my_field_name). It also seemed to appear on the draft of the node, but oddly when I went to the translation page for it in another language the new item was there, but all of its fields were blank instead of being populated by the English values as they should be.

The strangest thing is that field_collection_field_update seems to be getting called multiple times for each field collection item. I am using #1807460: Field collection doesn't play nice with workbench moderation (patch) since nothing gets done without it, and let me verify that it makes it past the extra check more than once during a save and does end up saving 2 revisions for a new field collection item. I haven't figured out why that happens, but I think I can verify that updateHostEntity is necessary to insure that field_data_ ends up pointing to the correct revision.

jmuzz’s picture

It won't let you add a translation to a node when the fields in field collection items are the only translatable fields on the node. The operations section on the translate tab has a message about 'No translatable fields' instead of the usual add link. Not sure if this can be fixed in Field Collection. As long as the node has another translatable field it is fine.

jmuzz’s picture

I made a patch for another issue: #2125017: New field collection item is incorrectly archived when created with a new revision

Testing with this seemed to clear up a lot of the things thatt I observed before and mentioned in #82. Just one thing remains. When saving nodes without the updateHost call existing field collection items do not get saved properly. Most of the data seems ok but their entries in the entity_translation table get changed to language = und when they should be language = (default language).

The call sequence that leads to this in field_collection looks something like $handler->getLanguage() calls $field_collection_item->langcode() calls $fci->delta calls $fci->hostEntity() calls $fci->fetchHostDetails which does an EntityFieldQuery() which returns no results. It makes sense that that would happen because the query is searching for a revision ID that hasn't finished saving yet.

I don't know that the extra code in updateHost is the best way to solve this, but it does work, and it doesn't seem unreasonable to me to add something like that to deal with the problems involved in trying to save a new revision of 2 entities at once that need to refer to each other.

jmuzz’s picture

Issue summary: View changes
Status: Needs review » Needs work

I found a case that the patch will break. I tested this with and without the patch it is definitely the patch that is breaking it.

- Create a node with a field collection item field 'x'
- Create a text field 'a' in the field collection 'x'
- Create a field collection item field 'y' in field collection 'x'
- Add a second instance of the text field 'a' to field collection 'y'
- Create a node with values for 'a' in both 'x' and the 'y' it contains
- Only values for 'a' in 'y' will appear, the ones in 'x' don't display, however they do seem to appear on the edit form

If you want to duplicate this make sure both text fields are instances of the same field. Also, I made all fields and field collections unlimited and added a few of them in my tests, though I don't think it would matter.

StephenN’s picture

In case it is of use to anyone else patch #72 broke the ability to revert with features. Applying the patch from #77 will fix this but requires manual database changes to drop the [field_name]_revision_id index from the field_data_[field_name] and field_revision_[field_name] tables for each field collection. Once this is done you can revert the feature and then re-export it.

jmuzz’s picture

Status: Needs work » Needs review
FileSize
880 bytes
25.21 KB

Here is a version of the patch that handles recursive field collections better. It fixes the problem mentioned in #85 as well as some other issues that spring up with nested field collections. A similar solution may be able to solve #1837394: Nested field collection content not showing in edit page.

ALSO

#72 and #79 reverted this commit:

http://drupalcode.org/project/field_collection.git/commit/a666cce9

If you applied either #72 or #79 then please also apply this commit. The patch I am including now does not have this issue, but the interdiff does not apply the fix for it if you had applied #72 or #79.

Status: Needs review » Needs work

The last submitted patch, 87: field_collection-et-1344672-87.patch, failed testing.

jmuzz’s picture

Same changes from #87 applied to unmodified 7.x-1.x

jmuzz’s picture

Status: Needs work » Needs review
jdanthinne’s picture

Patch #89 works fine for me.

Rhodungeon’s picture

jdanthinne can you tell the version of your modules (Entity Translation ect) and the output of the patching process of Field Collection? I have some problems, however I'll repeat the test on a brand new site.

jdanthinne’s picture

Entity API 7.x-1.2
Entity Translation 7.x-1.0-beta3+9-dev (2013-oct-25)
What do yo mean by the "output of the patching process"?

Rhodungeon’s picture

Thanks for your reply!

I meant the log after the patch command (I'm on a Mac)

I got this after applying patch #89

patching file field_collection.info
Hunk #1 succeeded at 4 with fuzz 2.
patching file field_collection.module
Hunk #1 succeeded at 47 (offset -9 lines).
Hunk #2 succeeded at 68 (offset -9 lines).
Hunk #3 succeeded at 359 (offset -9 lines).
Hunk #4 succeeded at 488 (offset -9 lines).
Hunk #5 FAILED at 975.
Hunk #6 succeeded at 969 (offset -33 lines).
Hunk #7 succeeded at 980 (offset -33 lines).
Hunk #8 FAILED at 1024.
Hunk #9 succeeded at 1143 (offset -31 lines).
Hunk #10 succeeded at 1179 (offset -21 lines).
Hunk #11 succeeded at 1242 (offset -21 lines).
Hunk #12 succeeded at 1275 (offset -21 lines).
Hunk #13 succeeded at 1306 (offset -21 lines).
Hunk #14 succeeded at 1336 (offset -21 lines).
Hunk #15 succeeded at 1375 (offset -21 lines).
Hunk #16 succeeded at 1502 (offset -21 lines).
Hunk #17 succeeded at 1545 (offset -21 lines).
Hunk #18 succeeded at 1725 (offset -21 lines).
Hunk #19 succeeded at 1785 (offset -21 lines).
Hunk #20 FAILED at 1816.
Hunk #21 succeeded at 1845 (offset -23 lines).
Hunk #22 succeeded at 1901 (offset -23 lines).
Hunk #23 succeeded at 1975 (offset -49 lines).
Hunk #24 succeeded at 2031 (offset -49 lines).
3 out of 24 hunks FAILED -- saving rejects to file field_collection.module.rej
patching file field_collection.pages.inc
patching file translation.handler.field_collection_item.inc

steinmb’s picture

All patches need to be applied against latest dev. version (7.x-1.x-dev), not latest stable.

Rhodungeon’s picture

Thanks!

Rhodungeon’s picture

Tested patch #89, the collection field is successfully translated, but it continues showing the untranslated version.
If I edit the node I can see the field correctly translated.
Anybody experiencing the same issue?

Darren Clark’s picture

Patch #89 works translating single level field collections. However this fails if there is a field_collection child contained.

Error is related to the clone of the field_state, the array parents need to be traversed in order to support.

thehyperlink’s picture

Duplicate nodes with fc/images + entity translation, anybody else?

I have an issue when creating a node that has an entity translatable field collection with an image field (single - unlimited items,does not matter); When I create the node and add an image to that node; The node is duplicated on first save/creation....

I am able to add images without duplicating by workaround though. By leaving the form empty the first time, and creating the source + translation with the an empty form, only supplying the title. And then, the second edit I am able edit the field collections without duplication of the node.

Does this patch resolve these issues? (#89)?

Versions used
drupal 7.23/7.24 core
Field collection beta 5

Steps to reproduce

Create content type X
-multilingual support enabled with field translation
-manage fields, add field, field collection type
-hide blank items leave checked
-field settings: number of values: 1?
-field translation: Users may translate all occurrences of this field: CHECKED
-widget type: embedded
- edit the field collection you just added
-add 1 image field
- number of values: 1
- users may translate all occurrences UNCHECKED

Create new node of type X
-supply title
-add a value to the field collection (upload image)
-Click save
-The node is created twice

Darren Clark’s picture

With Patch 89 applied when cloning a node and then saving this would produce the error when the field collection ws edited and saved that

"The host entity cannot be changed."

On debugging this check has been removed and so far.

- Translating a field_collection (as long as it doesn't contain a field_collection) is working
- Cloning a node which includes all the content and translations from the original.

Tests have been made editing content in each to confirm that their revisions and entities are separated and so far this is working.

Currently not working is the error with field collections inside of field collections caused via the field_collection_field_widget_embed_validate.

I'm attaching an update to patch 89 which includes the host entity updates as above.

jmuzz’s picture

@darren I don't think taking the check out is the right solution. Why should the new copy of the field collection's host entity need to be changed after the cloned node is saved? It sounds like it is getting saved with the wrong host when it is being cloned.

@thehyperlink If you are going to use a patched version of the module it would be best to start with the latest source from the repository. That's the code that the patch is made to be applied to.

jmuzz’s picture

Status: Needs review » Needs work
Darren Clark’s picture

@jmuzz I'm not sure either on this either however taking out the check at least means that the field collection fields within a cloned node can be edited after saving.

A better approach is to ensure that on the clone the host entity is set correctly.

Darren Clark’s picture

@jmuzz ok further testing has confirmed that unfortunately the clone references the original nodes entity so changing one alters both so the fix to correctly update the entity when cloning is needed.

areke’s picture

Issue summary: View changes
mcardin’s picture

Tested patch #89.

Tested patch #89, the collection field is successfully translated, but it continues showing the untranslated version.
If I edit the node I can see the field correctly translated.
Anybody experiencing the same issue?

In my case, views display the translated field, but Panels show blank fields. What I mean is the html markup is there, but fields are empty.

Darren Clark’s picture

I've now got the following working:

- Translating a field_collection now is a separate entity, updating does not affect the original
- Cloning a field collection works correctly
- Field collections inside field collections also is translating and cloning correctly.

When setting up the field collection for localisation do not set enable translation on all the fields inside the collection but only on the field collection itself.

A patch is attached in order to create I've used references from:

https://drupal.org/node/1316162
(Implemented https://drupal.org/files/field_collection-1316162-192.patch which is used for cloning nodes)

Translating fields issue (Martin's Blog):
http://theduttons.org/?p=7

Issues:
- On translating multi level field collection forms there can be warnings from field_widget_instance and field_widget_field, these have been suppressed for now however further investigation to clean this.
- Setting the item_id to empty causes an entity warning.
entity/includes/entity.controller.inc
To suppress then this needs modifications to change if ($entity->is_new) { to if (@$entity->is_new) {

jmuzz’s picture

@darren

The purpose of entity translation is to allow people to choose which fields in an entity can be translated, with the rest of them being shared so that updating them effects every translation. Creating separate entities for each translation is "node" or "content" translation. The thread you referenced is the place for getting node translation working. Please only post patches in this thread that help to get entity translation working.

Darren Clark’s picture

@jmuzz Apologies if I've cross referenced and produced a combined patch however this included the entity translation as well as handled the issue over node cloning.

I can separate this out however I felt it was useful to ensure that we have a combined version to fix both issues.

jmuzz’s picture

@darren Yes, it is good if we can fix the problem with node cloning, but I don't think we should make changes that add functionality to the patch in one way but remove it in another. If we did that, who knows if it would ever get done.

Maybe I'm not understanding this fully. You're saying it doesn't lose the entity translation functionality that was in place? I'm not sure how that can be if people would have to set the field collection itself to translatable and it will create a new entity for each translation. People were able to set some of the fields to translatable before and leave the other ones shared between translations.

Darren Clark’s picture

@jmuzz if you set an entity to translatable then you would expect that the individual translations be able to be updated directly and have different content. If however you set a field collection to be non translatable then this would be shared throughout the languages which to me seems the desired behaviour.

There was also an issue with translations that when this was created a field collection inside another field collection's data was lost. The patch I submitted resolved this as there was an issue with the reference to the element.

So far using the update I'm able to translate individually or set as non translatable so it's shared per field collection, as well as node cloning (not in this ticket agreed).

However what it's not doing is allowing for individual fields to be translatable within the entity itself so you can turn on and off translations and I agree that patch #83 should be revised to include these fixes which I'll review as soon as I can.

jmuzz’s picture

@darren I can understand why that would seem like the desired behavior. There are some UI issues surrounding this that have been discussed elsewhere in this thread, but setting the field collection's field to untranslatable definitely should allow translation of the fields inside the field collection. It would be nice to come up with a better way of representing this feature, but it may not be possible to do in field collection due to how Entity Translation functions (See #81).

Thanks for offering to preserve this functionality with your fixes. I depend on it for my use case and I'm sure I'm not the only one.

I do think it is a legitimate requirement for entity translation support in field collections. A field collection is an entity, and entity translation is supposed to support translation of individual fields in any entity. Field collections does make the UI surrounding this difficult though, since a field collection is both an entity and a field.

ddrozdik’s picture

Hi guys,

What status of this issue? I tried to use your patches with dev version of module but they don't work properly.

jmuzz’s picture

jmuzz’s picture

Did you try #89? It's the one I'd recommend. I've tested it myself and it seems to mostly work. The changes @darren made since then are an effort to get it working with node-clone and it breaks some of the functionality and removes some safety checks.

Darren Clark’s picture

@Dmitry The patch https://drupal.org/files/issues/field-collection-et-1344672-108.patch allows for translation of all the field collection item and when translating and cloning ensures that any child collections are also copied over. As per the discussion with @jmuzz this patch needs work to integrate the possibility of individual fields within the collection to be translated or shared as well.

The issue I had with #89 is that cloning or translating fields would lose all child collections as well as if the node was cloned the clone's edits would change the original which for my use case wasn't desired.

So for now if you don't use cloning or have field collections inside each other than #89 should work, or try the patch I submitted if you need cloning support.

mcardin’s picture

@Darren Clark

Thanks man. Unlimited field collection items are now translatable and everything is working as expected. Only problem (and I'm wondering if the patch is guilty...). I now get this notice when saving a node with a FC field :

Notice: Undefined property: FieldCollectionItemEntity::$is_new in EntityAPIController->save() (line 450 of ../modules/contrib/entity/includes/entity.controller.inc).

I tried to find out what causes this problem without success. The data is not affected, but the client won't like it :)

Field collection 7.x-1.0-beta5+8-dev
Entity translation 7.x-1.0-beta3+9-dev
Entity 7.x-1.1

Andrey Inkin’s picture

@Darren Clark

Patch #108 worked for me (thanks!), but same error as described @mcardin

Just inserting
$entity->is_new = FALSE;
right after
$entity->save(TRUE);
should do the trick.

Because 'EntityAPIController::save($entity)' unsets 'is_new' flag, it's ok to set it again (since we are in 'presave' hook and know that $entity->is_new will be used again).

egontinno’s picture

Patch #108 worked for me + #119 suggestion.

mcardin’s picture

Yes it works for me too. Patch #108 and #119 correction

mbe1980’s picture

Hi,

first of all: Big thank for this patch. It saved me a lot of time.

But I have the error described @#118 every time I save a node with nested field collections. I used the patch #108 and the #119 correction. Actually field_collection_field_insert looks like this:

function field_collection_field_insert($host_entity_type, $host_entity, $field, $instance, $langcode, &$items) {
  foreach ($items as &$item) {
    if (!empty($item)) {
      if ($entity = field_collection_field_get_entity($item)) {
        if (!empty($entity->is_new)) {
          $entity->setHostEntity($host_entity_type, $host_entity, LANGUAGE_NONE, FALSE);
        }
        $entity->save(TRUE);
        $entity->is_new = FALSE;
        $item = array(
          'value' => $entity->item_id,
          'revision_id' => $entity->revision_id,
        );
        if ($entity = field_collection_field_get_entity($item)) {
          if (!empty($host_entity->is_new) && empty($entity->is_new)) {
            // If the host entity is new but we have a field_collection that is not
            // new, it means that its host is being cloned. Thus we need to clone
            // the field collection entity as well.
            $new_entity = clone $entity;
            $new_entity->item_id = NULL;
            $new_entity->revision_id = NULL;
            $new_entity->is_new = TRUE;
            $entity = $new_entity;
          }
          if (!empty($entity->is_new)) {
            $entity->setHostEntity($host_entity_type, $host_entity, LANGUAGE_NONE, FALSE);
          }
          $entity->save(TRUE);
          $entity->is_new = FALSE; 
          $item = array(
            'value' => $entity->item_id,
            'revision_id' => $entity->revision_id,
          );
        }
      }
    }
  }
}

But the error described at #118 isn't gone.

Do you have any hints for me?

Thanks!

Rhodungeon’s picture

I've applied patch #89 and I can't modify a translated node with field collection fields.
The error that gives me is

Exception: The host entity cannot be changed

...
Now I would like to know if I have to apply patch #89-2 and #108 in order to get this working or not.
Can someone upload a temporary version of the field collection module solving this issue?

Thanks guys!

jmuzz’s picture

My version is just the latest repository source with #89 applied, nothing special. I haven't seen this error in any of my tests.

Are you using node clone? #89 is not compatible with node clone.

Other than that, I don't know why the host entity would be getting changed. You are using Entity translation and not Content translation right? Can you think of any reason it would be trying to change the host entity of the field collection item?

I don't think you should use #89-2. My understanding is that is just a previous version of #108.

You can try skipping the check, but I wouldn't recommend it. I don't think there is a good reason for the host entity of a field collection item to be changed.

Rhodungeon’s picture

Thanks for the tips!
It worked! I've applied patch 89-2 and later 108.

Thank you so much!

andrezstar’s picture

Me on the other hand still trying to apply those two patches ( with win7. 89-2 and then 108)

Tried:
-GNUwin32
-TortoiseSVN

and not working. Help plz?

Darren Clark’s picture

@Andrey Thank you for the entity updates to prevent the warning message.

I've incorporated this change into a new patch against 7.x-1.x:

https://drupal.org/files/issues/field-collection-et-1344672-108-v2.patch

In addition for anyone having issues applying the patch such as @andrezstar attached is the patched module:

https://drupal.org/files/issues/field_collection-1344672-108-v2.tar_.gz

andrezstar’s picture

thanks a lot darren,
but still same thing happening.

When I create a node of this content type with a field_collection image field and edit this node, this first time, the node aint fetching the image, so I have to edit it, upload it again and then I can see it.

weird tho

Darren Clark’s picture

@andrezstar Can you explain what is continuing to occur as issues with an image is not something which I've had an issue with? I've implemented both the default image field type and the media module without problems.

yaoweizhen’s picture

@Darren

Patch still doesn't work well, so I uploaded patched 89-2 and 108v2 module files.

Patch 89-2 lost includes/translation.handler.field_collection_item.inc file from 89. Patch 108v2 always failed. I compared and changed manually.

BTW, If you get error when node submit, please check this issue https://drupal.org/node/2141781

Nick Robillard’s picture

I've added the entire module in #130 (having removed old field collections and uninstalled the old module before installing new). I've added a Field Collection to a content type, and I've enabled the Field Collection option under "Translatable entity types" at /admin/config/regional/entity_translation. I've added fields to my Field Collection and set them to translatable.

Initially, when I loaded the node add or node edit form, I got a whitescreen with this error:
Fatal error: Call to undefined method EntityTranslationNodeHandler::addChild() in /home/nick/www/knoxportal/sites/all/modules/contrib/field_collection/field_collection.module on line 1588
I solved that by updating Entity Translation to the dev version.

However, I am still getting fatal errors when I submit node forms. IE: setEntityMalformedException: Missing bundle property on entity of type field_collection_item. in entity_extract_ids() (line 7670 of [...]/includes/common.inc)

Question: Am I suppose to make the Field Collections themselves translatable or just the fields within them? I've tried various combinations of both but I keep getting this error on node save. Are there any other setup gotchas that I should be aware of? Thanks!

jmuzz’s picture

The idea is to make the fields translatable, not the field collections themselves.

Making the field collection itself translatable should also work, but you would have to recreate the content for each language and it's not the solution that the patch is aiming at.

jmuzz’s picture

Try patch 89, that's the one I use.

I wouldn't recommend 89-2, that's a hack that was made to try to get it to work with some features from other contrib modules and it has known problems that the patches which come after it address.

Nick Robillard’s picture

Ah I see. Ok so I've made my field collections themselves not translatable. The fields inside them are translatable. Things seem to translate as expected via admin. And I can also export field collection data via /admin/config/regional/entity_translation/export and that looks right. Sweet.

I'm running into a problem when importing though. During the batch process I'm getting:

An AJAX HTTP error occurred. HTTP Result Code: 500 Debugging information follows. Path: /en/batch?id=2471&op=do StatusText: Service unavailable (with message) ResponseText: Exception: Unable to save a field collection item without a valid reference to a host entity. in FieldCollectionItemEntity->save() (line 553 of [...]/field_collection.module).

I've done some debugging around that and in FieldCollectionItemEntity->save() if I $skip_host_save, the import actually seems to work (I can see the updates on the node). However I see that $skip_host_save skips creation of revisions which is not a good thing, and the host entity is not set, although maybe that's ok because the host entity is already saved (since we're always dealing with existing data). I'm digging in deeper here and I'll post my results. I appreciate the help.

UPDATE: Ignore this error. It was being caused by orphaned field collections that were no longer attached to a node. Hence the lack of a host entity reference.

kumkum29’s picture

Hello,

Have you planned to include #89 and #108 patch in the next dev version?

Thanks.

jmuzz’s picture

#89 hasn't been properly reviewed yet, and last I heard Fago was conerned about some changes that had been made to the check that prevents the host entity from changing, so it won't likely be committed soon.

#108 removes the ability to do Entity Translation on field collection items from #89. With #108 you can still do Entity Translation on nodes that have field collection items, but field collection items are entities too and doing Entity Translation on them is an important part of what the patch should do. It also completely removes the check just mentioned.

The only known problem with #89 as I understand it is that it doesn't work with the node clone contrib module. If it can be reviewed and that check properly looked at (I did post some information about it) then it might get committed.

smithworx’s picture

donquixote’s picture

This works for me, but only with the latest entity_translation-7.x-1.x from 2014-Jan-22.

Instructions:
- Create a node type with a field_collection field.
- Enable entity_translation for the node type.
- The field_collection field itself should NOT have translation enabled.
- Visit admin/config/regional/entity_translation
- In "Translatable entity types", tick the checkbox for "Field collection item".
- Visit admin/structure/field-collections/*/fields(/*)
- Create some fields, and enable translation for some of them.

EDIT: Here is the link,
https://github.com/donquixote/drupal-field-collection/compare/7.x-1.x-en...

jmuzz’s picture

Sounds good. Does #138 change something, or is it like a reroll for the latest entity_translation ?

donquixote’s picture

@jmuzz:
The first commit is just #101. The second commit is something additional.
I did not look further than #101, because this was the last green patch.. maybe I missed something.

lukus’s picture

Hi - can anyone provide an update on this issue. I'd be happy to review any patches if necessary. Is patch #101 the latest?

Thx.

donquixote’s picture

There are some "solutions" on github. I used one of them for #138, but I don't remember which.
https://github.com/phreaknerd/drupal-field-collection
https://github.com/ribel/drupal-field-collection

It would be great if those people could get over here and help us out :)
But it would also be great if the Drupal community would stop doing patches and start doing pull requests.

jmuzz’s picture

Please review #89. As far as I know the only known issue with it is that it is not compatible with node clone, which could be a separate issue as node clone is not a core module. Also, it would be helpful to have a more convincing explanation about why the host check needs to be changed (See #61). I said some things in #82 but I don't think I was able to give a complete answer.

I do not believe that #101 or its continuation #108 are candidates to be committed because they remove the host entity check. Also, from #112: "what it's not doing is allowing for individual fields to be translatable within the entity itself." donquixote seems to think that part is actually working so I don't know if that's true any more, but any patch that might be committed does need to address the issue about the host entity check.

jussil’s picture

If you are using nested field collections with translatable first level field collection field, there is a strange issue which causes the inner field collection item to resolve it's language improperly. We are using patch #53.

This leads into following error and notices:

Fatal error: __clone method called on non-object in /var/www/mysite/sites/all/modules/contrib/field_collection/field_collection.module on line 1780
Notice: Undefined index: instance in field_widget_instance() (line 603 of /var/www/mysite/modules/field/field.form.inc).
Notice: Undefined index: field in field_widget_field() (line 578 of /var/www/mysite/modules/field/field.form.inc).
Notice: Undefined index: entity in field_collection_field_widget_embed_validate() (line 1780 of /var/www/mysite/sites/all/modules/contrib/field_collection/field_collection.module).

It seems that when new inner collection is being validated, element contains it's parent's language, so I had to do this type of language resolving in function.

function field_collection_field_widget_embed_validate($element, &$form_state, $complete_form) {
  if(($nesting_level = count($element['#parents']) / 3) > 1)
    $element['#language'] = $element['#parents'][$nesting_level * 3 - 2];
  // Continue normally
}
afi13’s picture

Hi guys,

What status of this issue?

jmuzz’s picture

Status: Needs work » Needs review

Hi jussil.

#89 addresses some issues related to nested field collections. I recommend that one over any of the others.

See #143 for some notes about the issue's status.

I had set this to needs work because somebody said that they were going to fix some issues with another patch version that they posted for compatability with a different contrib module. That was a while back so I'm going to put it back to needs review.

Please review #89.

Status: Needs review » Needs work

The last submitted patch, 127: field-collection-et-1344672-108-v2.patch, failed testing.

donquixote’s picture

@jussil (#144)

If you are using nested field collections with translatable first level field collection field, there is a strange issue which causes the inner field collection item to resolve it's language improperly. We are using patch #53.

I think we should agree on *one* supported way to make field collections field-translatable.
Imo, the field_collection field itself should *not* be ticked as field-translatable.
Instead, the fields on the field collection item entity should be field-translatable. Unless this field is again a nested field collection field.

E.g.
Node type "page":

  • field "body": text, translatable
  • field "image": image, translatable (if you really want)
  • field "boxes": field collection, NOT translatable.
    • field "box image": image, translatable (if you really want)
    • field "box link": link, translatable

If we constrain the scenario like this, we have an easier job testing and supporting this stuff.

jmuzz’s picture

Status: Needs work » Needs review
FileSize
25.22 KB

I don't know if this is the best way, but I will repost #89 so it will be tested.

I think both ways of translating will be necessary. Field collections are both fields in an entity and an entity themselves. Fortunately, I don't think that setting the field collection itself to translatable will be difficult to get working or test (it should be working AFAIK).

FreeAndEasy’s picture

#149 Patch field_collection-et-1344672-89.patch works for me with newly created nodes (not cloned).

dshields’s picture

From what I'm seeing, patch #149 (which is patch #89) works for single-value field collection fields.
If I add a second collection to the original node of an already translated pair, a second collection is not created on the translation

jmuzz’s picture

Status: Needs review » Needs work

Good point, dshields, it should create a new field collection on the translations as well.

jmuzz’s picture

Status: Needs work » Needs review
FileSize
27.47 KB
2.4 KB

New field collections will now copy their translatable fields into the languages its host has translations for.

jmuzz’s picture

jmuzz’s picture

FileSize
3.33 KB
26.68 KB

A better version that doesn't save the field collection item an extra time.

dshields’s picture

Sorry, jmuzz, but I'm seeing the very same behaviour.
For my content type, I've got multilingual support "Enabled, with field translation"
For the field collection field, I have translation disabled.
The fields inside the field collection have translation enabled.

When I add a second collection to the French or the English version of my node, that collection exists only on one translation.

Am I doing something wrong?

odegard’s picture

@dshields, it's not entirely clear to me what you're doing. Are you making a content type with a field collection X, then add a field collection Y inside field collection X?

If this is the case, it might work only with new content, not old. Just a hunch.

dshields’s picture

no.
just one field collection.

jmuzz’s picture

@dshields, I don't know why it wouldn't be working for you. I tested it a few times with the embedded form and with the separate form for making a new field collection item. The content is getting placed in all the languages when I add another field collection item. I'm using a field collection field with unlimited cardinality that just has a translatable text box in it.

Is there any chance that your field collection field itself is set to be translatable?

Are you using the latest repository version of all of the modules?

Are you using any modules other than field collections, entity translation, and their requirements? (In particular workbench moderation might cause problems.)

dshields’s picture

I am using workbench moderation, yes.
Maybe that's the issue..

jmuzz’s picture

I'd be surprised if you have gotten anywhere without this, but just in case, let me throw this out there... You are using the patch from #1807460: Field collection doesn't play nice with workbench moderation (patch), right?

I don't think we need to support workbench moderation for this translation patch. Perhaps we could leave it for another issue.

dshields’s picture

I hadn't seen that issue - thanks jmuzz - I'll report back after testing!

dshields’s picture

FileSize
27.55 KB

Thanks for all your help here, jmuzz

I've combined the patch from the issue you mentioned, https://drupal.org/node/1807460 with your patch and it works fine with workbench moderation enabled on the site.

Honza Pobořil’s picture

Patch #163 works for me but after save new translation it prints some notices:

Notice: Undefined index: field in field_widget_field() (line 578 of /Users/Bobik/Sites/mowapay/modules/field/field.form.inc).
Notice: Undefined index: field in field_widget_field() (line 578 of /Users/Bobik/Sites/mowapay/modules/field/field.form.inc).
Notice: Undefined index: instance in field_widget_instance() (line 603 of /Users/Bobik/Sites/mowapay/modules/field/field.form.inc).
Notice: Undefined index: instance in field_widget_instance() (line 603 of /Users/Bobik/Sites/mowapay/modules/field/field.form.inc).
Notice: Undefined index: field in field_widget_field() (line 578 of /Users/Bobik/Sites/mowapay/modules/field/field.form.inc).
Notice: Undefined index: field in field_widget_field() (line 578 of /Users/Bobik/Sites/mowapay/modules/field/field.form.inc).
Notice: Undefined index: instance in field_widget_instance() (line 603 of /Users/Bobik/Sites/mowapay/modules/field/field.form.inc).
Notice: Undefined index: instance in field_widget_instance() (line 603 of /Users/Bobik/Sites/mowapay/modules/field/field.form.inc).
mgifford’s picture

That should be easy to fix... The patch probably is just missing two checks to verify that $field & $instance are variables.

jmuzz’s picture

@dshields - That sounds useful for somebody who needs to apply a patch, but there is some controversy about that particular fix. We should let it be resolved in its own thread and not try to sneak it in here.

jmuzz’s picture

@Bobik - I was not able to reproduce this. I made a basic content type with a field collection that has a translatable text field, made a new instance of it, and added a translation to it. I tried it with #155, with #163 (no workbench moderation), and with #163 (workbench moderation enabled). Can you provide more specific steps for how to reproduce the errors?

colan’s picture

When nodes are language neutral before applying #155 (with the field-collection field not translatable, but its fields are), then I apply it, check that checkbox in the config, I can add translations, and the translatable child fields show up properly translated.

If, however, I already have translations for nodes (i.e. they're not language-neutral), then the edit form shows them as empty. They're still showing up on the "View" tab, but when editing both the original language and a translation, there's nothing populating those fields. If I save (with those fields showing up as empty), then the content really disappears. (I'm testing this with "Long text" fields, by the way.)

This is acceptable for my current project, as we're making the site multi-lingual when it wasn't before, but for sites that already have translated content, I don't think site maintainers are going to be happy losing content. ;) Is there something has to be done for already-translated content to make it show up properly? If this is a reproducible phenomenon, we need to account for it as well. Leaving as "Needs review" just in case I'm missing something here.

Let's forget about #163. Integration with other modules should be handled in separate issues. Within those, feel free to state that the patch here is a prerequisite.

jmuzz’s picture

Category: Bug report » Feature request
Status: Needs review » Needs work

I can confirm that language enabled nodes created before the patch is applied will break as described.

jmuzz’s picture

Status: Needs work » Needs review
FileSize
28.48 KB
3.75 KB

I've added an update script that should fix the fields inside field collections that were using entity translation before the patch.

jmuzz’s picture

Another report of the messages mentioned in #164:

#2206855: Field Collection, Field translation and image field breaks

It may be related to making the field collections translatable instead of the fields inside them. I didn't try that when I attempted to reproduce the messages.

fago’s picture

Status: Needs review » Needs work

Not really looked into the details, but here a first review: (mostly on style)

  1. +++ b/field_collection.install
    @@ -281,3 +281,30 @@ function field_collection_update_7004() {
    + * Update any fields inside field collections that were already set up to use
    + * Entity Translation before the patch for it was applied.
    

    There should be a one line summary.

  2. +++ b/field_collection.install
    @@ -281,3 +281,30 @@ function field_collection_update_7004() {
    +  $fc_results = array();
    

    variable names should always be readable, even if longer.

  3. +++ b/field_collection.install
    @@ -281,3 +281,30 @@ function field_collection_update_7004() {
    +      $item->copy_translations(LANGUAGE_NONE);
    

    Methods are named using CamelCase.

  4. +++ b/field_collection.module
    @@ -72,12 +77,49 @@ function field_collection_entity_info() {
    + * @param $entity_type
    + * @param $entity
    

    Useless params - either add descriptions or remove them.

  5. +++ b/field_collection.module
    @@ -326,6 +368,32 @@ class FieldCollectionItemEntity extends Entity {
    +    } else {
    

    Coding style - should start on new line.

  6. +++ b/field_collection.module
    @@ -472,7 +540,12 @@ class FieldCollectionItemEntity extends Entity {
    + ¶
    

    Whitespace.

  7. +++ b/field_collection.module
    @@ -472,7 +540,12 @@ class FieldCollectionItemEntity extends Entity {
    +   ¶
    

    Whitespace.

  8. +++ b/field_collection.module
    @@ -504,6 +577,29 @@ class FieldCollectionItemEntity extends Entity {
    +  public function copy_translations($source_language = NULL) {
    

    Should be camelcased (As said) and misses docs.

  9. +++ b/field_collection.module
    @@ -504,6 +577,29 @@ class FieldCollectionItemEntity extends Entity {
    +    foreach ($fields as $t_field) {
    +      foreach ($target_languages as $lang_code) {
    +        if (isset($this->{$t_field}[$source_language])) {
    +          $this->{$t_field}[$lang_code] = $this->{$t_field}[$source_language];
    

    Again readable varnames for t_field, $lang_code which usually is $langcode.

  10. +++ b/field_collection.module
    @@ -1271,6 +1385,37 @@ function field_collection_field_formatter_view($entity_type, $entity, $field, $i
    +  global $field_collection_operation_keys;
    +  return $field_collection_operation_keys[$a] - $field_collection_operation_keys[$b];
    

    This is weird - cannot that be done without a global?

hyscaler’s picture

Version: 7.x-1.x-dev » 7.x-1.0-beta7
Status: Needs work » Active

Latest patch i.e. `field_collection-et-1344672-170.patch` doesn't apply to the latest updated module i.e. 'field_collection 7.x-1.0-beta7'. Any idea if this issue has been fixed in the latest version?

The Release Notes do not mention about this issue. (https://drupal.org/node/2217293)

jmuzz’s picture

Version: 7.x-1.0-beta7 » 7.x-1.x-dev
Status: Active » Needs work
Issue tags: +Needs reroll

No it hasn't been fixed yet. The patch will need to be updated for the latest development version.

jackdaniel9’s picture

entity translation 7.x.-1.x-dev
field_collection 7.x.-1.x-dev

ok I think I managed to understand

Apply patch #163

+

Exception: The host entity cannot be changed. in FieldCollectionItemEntity->updateHostEntity() (line 397 of D:\wamp\www\praxar\profiles\orizonmedia\modules\contrib\field_collection\field_collection.module).

Apply patch #108

+

- Setting the item_id to empty causes an entity warning.
entity/includes/entity.controller.inc
To suppress then this needs modifications to change if ($entity->is_new) { to if (@$entity->is_new) {

+

you must recreate all nodes

/***/

i have insert
class EntityTranslationFieldCollectionItemHandler extends EntityTranslationDefaultHandler
in
entity_translation/includes/translation.handler_factory.inc

(i didn't create file translation.handler.field_collection_item.inc because i had a error)

jmuzz’s picture

Assigned: Unassigned » jmuzz
jmuzz’s picture

Assigned: jmuzz » Unassigned
Status: Needs work » Needs review
Issue tags: -Needs reroll
FileSize
28.27 KB

Rerolled and made the requested changes. Haven't done any testing other than the unit tests.

yingtho’s picture

Status: Needs review » Needs work

When i add a new content to translation it doesn't save the content and the warning messages below is shown but if i edit and save again the content gets updated.
Error messages:

Notice: Undefined index: field in field_widget_field() (line 578 of modules/field/field.form.inc).
Notice: Undefined index: field in field_widget_field() (line 578 of modules/field/field.form.inc).
Notice: Undefined index: instance in field_widget_instance() (line 603 of modules/field/field.form.inc).
Notice: Undefined index: instance in field_widget_instance() (line 603 of modules/field/field.form.inc).
Notice: Undefined index: field in field_widget_field() (line 578 of modules/field/field.form.inc).
Notice: Undefined index: field in field_widget_field() (line 578 of modules/field/field.form.inc).
Notice: Undefined index: instance in field_widget_instance() (line 603 of modules/field/field.form.inc).
Notice: Undefined index: instance in field_widget_instance() (line 603 of modules/field/field.form.inc).
MantasK’s picture

I applied #108 patch + some other patches some time ago and it worked for me. Until I've started using deploy module. In cloned entity uuid has to be unset otherwise new is not generated $new_entity->uuid = NULL;
not sure if it is need in new patches, maybe it is taken care automatically.

yingtho’s picture

I testede it some more and found out that it was only the field type of file (e.g. image) that is causing the problem. And only if if have more than one file image. It seems like the form state cache is not correctly updated because if i push the add more item button first and then makes the changes then it saves it correctly.

biswajeetparida’s picture

Issue tags: +field-collection, +translation

After using the field_collection 7.x-1.x-dev version and the latest patch 'field_collection-et-1344672-177.patch' the language translation not working for field collection fields. When edit/update the translation content the following error is showing.
Exception: The host entity cannot be changed. in FieldCollectionItemEntity->updateHostEntity()
The above error is showing for the $current_id and $received_id not return the same value in the updateHostEntity() method.

Please suggest.

biswajeetparida’s picture

Category: Feature request » Bug report
Priority: Normal » Major
keopx’s picture

Hi,

Using field_collection-et-1344672-177.patch works for me, but:

biswajeetparida07 said:

After using the field_collection 7.x-1.x-dev version and the latest patch 'field_collection-et-1344672-177.patch' the language translation not working for field collection fields. When edit/update the translation content the following error is showing.

Only success when edit/update. When we created new translation work fine.

Exception: The host entity cannot be changed. in FieldCollectionItemEntity->updateHostEntity()
The above error is showing for the $current_id and $received_id not return the same value in the updateHostEntity() method

Modules and commit versions:

  • entity translation 7.x.-1.x-dev Commit: d3eaec3ad415a8907d122d461734c56c038b2d7e
  • field_collection 7.x.-1.x-dev - Commit: eb28ebd5a443ef3db493f2376253a529f4fef920

Other thing:

When translate node doesn't pass values (field_collections translatable fields) for new fields on the node interface. I think this behavior isn't appropriate.

jannis’s picture

Patch 177 worked for me. I got a rejection of hunk 8. I manually applied and it works pretty well. (i'm using field_collection beta7). I am able to add a field collection to a content type (field collection is translatable, all fields contained are not seems to be the best way to get it to work)

1) the 'add' button only adds to the default language (not the current language). adding items to your field collection in any language adds them on the default language not the one your viewing.

2) there's no support for nested field collections.

I will be looking into solutions for both these issues and will provide what I can.

nice work on the patch jmuzz

jmuzz’s picture

Interesting point about the add button. The thing about entity translation is that any translated entity needs to exist in the default language before it can be translated. If your field collection field is not translatable but the field collection items inside it have translatable fields, then I don't know if there is a way around adding them to the default language.

jannis’s picture

Lingotek's newer versions of their module seems to support 'nested field collections' up to 10 levels deep. Lingotek

Looking into pulling some of their code into a custom module that adds that support

sylus’s picture

Status: Needs work » Needs review
FileSize
28.6 KB

Due to recent additions of hook_update_n in field_collection I had to update this patch to use field_collection_update_7007.

Setting to needs review to trigger testbot.

Heine’s picture

+   * Updates the wrapped host entity object.
+   */
+  public function updateHostEntity($entity) {

+    else {
+      throw new Exception('The host entity cannot be changed.');
+    }
+  }

Why the exception? This prevents saving the edit form of translatable entities that have an untranslatable field collection. Prior behaviour would update the field collection in the source entity.

jmuzz’s picture

It is analogous to the exception that can be thrown in setHostEntity, since we are adding a new operation that could potentially change the value of an entity's field, it's important to make sure that that entity is actually the one hosting the Field Collection, sort of a sanity check. Perhaps there is a bug in the check. As long as the source entity as you describe it is the same as the entity being translated the exception shouldn't get thrown.

stevieb’s picture

I get a WSOD using the patch in #187

dshields’s picture

@stevieb - what error messages are in your logs when the page delivers WSOD?

stevieb’s picture

when applied to the current dev the WSOD disappears - I'm still unable to translate field collections on a working site
I'll try it with a clean install over the weekend

dshields’s picture

@stevieb - any php errors that you can find in your logs would help diagnose the issue

mahalo13’s picture

#177 solved the Problem https://drupal.org/node/1281974 but all items have the same language (en) and not the language of the translation.

NWOM’s picture

Sadly #187 doesn't work. On the edit pages, it correctly shows the correct translated text. However, on the node pages, it only shows for my default language. The text for the other languages do not show at all.

Edit: This has been applied to the latest DEV.

trim108’s picture

FileSize
3.04 KB

Patch that works for me. I used field_collection-7.x-1.x-dev and entity_translation-7.x-1.0-beta3 modules.

Status: Needs review » Needs work

The last submitted patch, 196: field_collection_et.patch, failed testing.

mgifford’s picture

FileSize
3.36 KB

@trim108 - your patch is malformed. Not sure why. I think this is a fair representation of it based on the git repository though.

mgifford’s picture

Status: Needs work » Needs review

Status: Needs review » Needs work

The last submitted patch, 198: field_collection_et-2.patch, failed testing.

joseph.olstad’s picture

MGifford, thanks for this, your patch applies correctly to the 2014-Apr-16 dev branch.

mgifford’s picture

Should it have been built on another branch?

joseph.olstad’s picture

All the test result says is:
Added field value is shown. Other field_collection.test line 258

Is there any way to view field_collection.test to see what test name:

Field collection (FieldCollectionBasicTestCase) [Field types]

is doing?

Where can we get a copy of field_collection.test to see what this test is doing?

Line 258 seems to be referring to the test file because line 258 in the patched .module is empty.
? any idea how to find out what this test is doing?

bmad’s picture

with regards to the et-2 patch (#198)

I have installed the patch manually and still no joy on the translating of fields. I switch to french and it looks like the entry of the data when translating a node works fine, but when you try and modify it after it's created, it seems to look at the wrong version or something...

I am tryign to perform the patch on field_collection-7.x-1.x-dev and I have the entity_translation-7.x-1.0-beta3 module alongside.

HELP! is there a new field_collection module build in the works? we've got a publish dedaline ion several weeks and we can't enter the content on the French side

Scott Robertson’s picture

The latest patch seems to work correctly when editing a node that already has an entity translation, but not when I try to create an entirely new entity translation.

If I inspect the name of the input element in my test field collection, it is:

field_test_collection[fr][0][field_test_sub_collection][en][0][value]

I believe the 'en' key should actually be 'fr'; if I save the new translation, I don't have any value for the French version of the field.

RaulMuroc’s picture

If I go to admin/config/regional/entity_translation, I got the following:

Image

Don't should be able to be choosen 'Field collection Field'? Do I miss something?

I can mark in 'manage fields 'of my content type the 'Field collection' as 'Enable translatable' but is no way to translate them (or at least I don't find).

I applied the latest patch in latest field collection dev.

jmuzz’s picture

#196: This is much smaller than the previous patch. Are we really sure the rest of the changes that #187 made aren't necessary? The updates were removed, the translation handler was removed, there are many hardcoded references to LANGUAGE_NONE that are no longer being replaced...

It might be better to go back to #187 as a basis for future work on this.

Scott Robertson’s picture

I believe jmuzz is correct that more needs to be done than what is in #196. I was only able to start having more success with translations when I removed the hardcoded LANGUAGE_NONE references.

ciss’s picture

Are there any tests that define the expected outcome(s)? I've only seen manual tests being mentioned in several comments, but no evidence of a test suite that could further a test driven approach to the problem.

jmuzz’s picture

Status: Needs work » Needs review
Issue tags: -field-collection, -translation
FileSize
28.6 KB

Yeah I just tested it again and I really don't see what the problem is. To the people who are saying that it doesn't appear translated or it's just translating to english, make sure Field Collections are set to translatable in the entity translation module settings and that the fields are set up so the correct ones are translatable to achieve your desired results. For the WSOD, try doing a cache clear, the patch adds a file so the .info needs to be reread.

For the people looking for the test suite, field_collection.test is right there along with the rest of the field_collection.* files.

RaulMuroc’s picture

Field collection being translatable doesn't work fine with multiple values field, just with single value field.

RaulMuroc’s picture

Here the image related to the previous post.

As you can see there is a link "add" to add a new value to the Field collection but the fact is that I already added before and inserted a value. But it keeps asking again and when click on 'add' it says "Too many items" due to it really exists. If I go to 'edit' the node it offers to modify the first value of Field collection but not the second one (like if it doesn't exist) and I cannot do anything else from here on.

Somebody with similar situation?

jmuzz’s picture

@RaulMuroc I tried testing this. I made a content type with a field collection and a translatable text field. I made a text field inside the field collection and made it translatable. I made an instance of the content type with a single value in the field collection. I added another value to the field collection using the add link on the view page, and it worked. I translated the text field in the first value, and that worked too.

Are you using patch #187 / #210 ? That's the one that's closest to working and any help reviewing that patch would be appreciated.

RaulMuroc’s picture

Indeed I realised I had a site based on Content translation and I was trying to mix with Entity translation.

So finally I applied the other patchhere and everything is cool.

Sorry, I didn't notice at the beginning the mix of concepts.

BR

NWOM’s picture

The patch appears to need a re-roll. Also, when attempting to manually apply the patch, I get a WSOD.

Status: Needs review » Needs work

The last submitted patch, 210: field_collection-et-1344672-187.patch, failed testing.

jmuzz’s picture

Status: Needs work » Needs review
FileSize
28.26 KB

Here's a version that should apply to 7.x-1.x again.

Scott Robertson’s picture

Using the patch in #216, I'm having issues with a multi-value field collection that's within another field collection. My setup is as follows:

- Content type (with field translation enabled) with field collection field (field_a)
- field_a has another field collection field attached to it (field_b)
- field_b is set up to allow multiple values and has a regular text field attached to it (field_c)
- Field Collections are set up to be translatable in the Entity Translation settings
- field_a, field_b, and field_c are ALL configured to be translation

When trying to translate a node, the edit form looks fine. I can see the original values in each field, however when I submit the form, I receive the following error:

Notice: Undefined offset: 1 in field_collection_field_widget_embed_validate() (line 1877 of ....../wwwroot/sites/all/modules/field_collection/field_collection.module).

Which is this line here:

elseif ($form_state['values'][$field_state['array_parents'][0]][$field_state['array_parents'][1]][$element['#delta']]) {

After doing some debugging, it looks like $element['#delta'] is set to 1, however there is no such index in $form_state['values']['field_a']['fr'], there is only an index of 0.

Note that this ONLY occurs if there is more than one value for field_b (AKA I have hit "Add more items"). If there is only one instance of field_b on my node, I don't get any errors.

Carlos Miranda Levy’s picture

I get a WSOD when trying to edit nodes after applying the patch at #218.
My nodes have multiple values field, which is stated that the patch won't cover.
But just giving you a heads up because I wanted to use translation for a single value collection, but it shows WSOD when trying to edit any node that has a field collection.

I deleted the fields from the field collection and still get the WSOD, but nothing is written on the log.

Before removing the multiple value fields from the collection, I would get the following error when attempting to edit/add a node that included that field collection:

MESSAGE Notice: Undefined property: stdClass::$original in field_collection_field_update() (line 1040 of /xxxxxxx/sites/all/modules/field_collection/field_collection.module).
SEVERITY notice

I did clear cache via drush cc all at every step of my tests.

PaperWeight’s picture

Patching 7.x-1.0-beta7 with #218 results in Hunk #8 failing

patching file field_collection.info
patching file field_collection.install
Hunk #1 succeeded at 281 (offset -47 lines).
patching file field_collection.module
Hunk #8 FAILED at 1033.
Hunk #9 succeeded at 1043 with fuzz 2 (offset -14 lines).
Hunk #10 succeeded at 1054 (offset -21 lines).
Hunk #11 succeeded at 1098 (offset -21 lines).
Hunk #12 succeeded at 1215 (offset -21 lines).
Hunk #13 succeeded at 1241 (offset -21 lines).
Hunk #14 succeeded at 1304 (offset -21 lines).
Hunk #15 succeeded at 1337 (offset -21 lines).
Hunk #16 succeeded at 1368 (offset -20 lines).
Hunk #17 succeeded at 1398 (offset -23 lines).
Hunk #18 succeeded at 1429 with fuzz 1 (offset -24 lines).
Hunk #19 succeeded at 1556 (offset -28 lines).
Hunk #20 succeeded at 1599 (offset -28 lines).
Hunk #21 succeeded at 1779 (offset -29 lines).
Hunk #22 succeeded at 1839 (offset -29 lines).
Hunk #23 succeeded at 1870 with fuzz 2 (offset -29 lines).
Hunk #24 succeeded at 1901 (offset -29 lines).
Hunk #25 succeeded at 1957 (offset -29 lines).
Hunk #26 succeeded at 2057 (offset -29 lines).
Hunk #27 succeeded at 2113 (offset -29 lines).
1 out of 27 hunks FAILED -- saving rejects to file field_collection.module.rej
patching file field_collection.pages.inc
patching file includes/translation.handler.field_collection_item.inc

EDIT:

Applying patch to 7.x-1.0-beta6+13-dev worked

Thanks stevieb

stevieb’s picture

patch using the dev version

PaperWeight’s picture

I seeing the same issue as Carlos in #221 - I get the WSOD whenever I try to edit a node containing a field collection.

7.x-1.0-beta6+13-dev with the patch in #218

PHP error log shows:

PHP Fatal error: Call to undefined method EntityTranslationNodeHandler::addChild() in /path-to-www/sites/all/modules/field_collection/field_collection.module on line 1634

That relates to:

function field_collection_add_child_translation_handler($element) {
  $handler = entity_translation_get_handler($element['#host_entity_type'], $element['#host_entity']);
  $handler->addChild('field_collection_item', $element['#field_collection_item']);
  return $element;
}

EDIT: More info

To reproduce, I'm just adding a field collection to a content type and make it translatable. I don't even need to add fields to that collection to get the WSOD when I try to add content of that type. Removing the filed collection from the content type brings everything back.

fxfx’s picture

installed dev version with #218 patch no errors in patching and no error in pages, i can now save translated field collection fields but does not appear at all in the localized version of the node

jwilson3’s picture

Thanks for everyone's hard work on this issue -- amazing.

I have patch in #218 working with latest dev branch of the module, however, like comments #164 and #178, I am also receiving the following two warning messages (showing up multiple times for each group of fields in the field collection of the translated entity):

Notice: Undefined index: field in field_widget_field() (line 578 of /modules/field/field.form.inc).
Notice: Undefined index: instance in field_widget_instance() (line 603 of /modules/field/field.form.inc).

The messages are shown only once after saving the translation. Subsequent refreshes of the translated entity view page, cause no errors, which leads me to believe there is still some issue somewhere in some of the code that is introduced here.

mh86’s picture

I rerolled patch from #218 with a small fix in EntityTranslationFieldCollectionItemHandler::getLanguage()

The current logic in getLanguage() assumed that a translatable host entity always exists. In my case I have a profile2, which is not marked as translatable, with translatable field collection items on it. With this scenario the source language was always set to the site's default language, regardless in which language the user entered the data. The attached patch fixes this by checking whether the host entity is translatable, if not, it's going to use the default implementation that is configured via the Entity Translation module (admin/config/regional/entity_translation). I was also wondering why we look for the host entity's language at all and not use the default implementation?

mh86’s picture

FileSize
28.51 KB

Updated patch that fixes a PHP warning in the changes from my last patch.

Lukas von Blarer’s picture

I am having two issues with this patch:

1: When translating field collections that have translatable and untranslatable fields, the translatable ones have empty values and have to be re-entered.

2: Date fields inside multivalue field collection fields are not saved the first time when being translated except for the first value.

stewart.adam’s picture

Status: Needs review » Needs work

I downloaded the latest dev release of field_collection and the applied patch from #228. I have setup a multi-value field collection containing an image field and a text area. Field translation (via entity translation) was enabled on all three.

I see the same issue as #226 - PHP warnings on the first edit, subsequent edits do not display errors. However, viewing the translated versions results in an empty page. I've debugged this and determined it is because Drupal cannot retrieve any deltas for the fields; after looking in the database I can confirm this and it looks like a bug in the patch.

After initially translating a node, I see a second row in the field table being added but under the same language as the source node.

For example, this is the contents of the image field's table (this field is included in the field collection):
field_collection_item field_slideshow 0 16 20 en 0 51 english title 2592 1728
field_collection_item field_slideshow 0 17 22 en 0 51 2592 1728
The second row should have been added with a 'fr' code, and its text column is empty when it shouldn't be.

Similar story with the caption field's database (also included in the field collection):

field_collection_item	field_slideshow	0	16	20	en	0	english caption	NULL
field_collection_item	field_slideshow	0	17	22	en	0	french caption	NULL

And some very unusual results for the field collection table itself:

node	slideshow	0	99	99	en	0	16	20
node	slideshow	0	99	99	fr	0	17	21
node	slideshow	0	99	99	und	0	17	22

----------------
edit: I have some additional follow-up to testing above. I deleted all nodes and ensured the tables for the 3 fields mentioned above were empty, then I disabled translation on the image and text fields but left translation enabled on the actual collection. Creating a new node then translating it resulted in redundant rows in the field collection table:

node	slideshow	0	101	101	en	0	21	27
node	slideshow	0	101	101	fr	0	20	25
node	slideshow	0	101	101	und	0	20	26
node	slideshow	0	101	101	en	1	19	24
node	slideshow	0	101	101	und	1	21	28
fromtheindia’s picture

I am also facing the same issue. I am using field_collection with multivalue. No success with the patch #228...

pbuyle’s picture

The attached patch is a re-roll of patch form #218 so it apply on current dev.

pbuyle’s picture

The attached patch is a re-roll of patch from #218 so it apply on current dev.

pbuyle’s picture

The attached patch is a re-roll of patch from #218 so it apply on current dev.

alcroito’s picture

The patch in #234 isn't a proper one, because it does not include the includes/translation.handler.field_collection_item.inc file, from 218.

alcroito’s picture

Attaching re-roll against git head, of patch #228.

alcroito’s picture

Status: Needs work » Needs review
FileSize
29.47 KB
1.65 KB

Attaching a new patch that I think fixes some problems regarding saving the form for the first time, and the values not being there, by using getFormLanguage() instead of getLanguage().

It also adds a check when deleting a field collection, because sometimes invalid ids are returned, which gives a fatal error trying to call delete on a non-object. So there is an underlying problem that is still not solved, but at least it doesn't throw the error for now.

Another check is added to check that an original object exists in the host_entity (FFPs for example don't have by default an original object).

To test this you have to do the following steps:
1) Download and enable latest DEV field_collection and entity_translation.
2) Apply the patch.
3) Clear cache just in case.
4) Go to admin/config/regional/entity_translation and Enable Translateable types for Field Collection Item and Node.
5) Go to a Node type configuration form, and enable Field Translation for it.
6) Add a field collection to the node type, and add some fields into it (text fields, images).
7) Enable Field translation for both the Field collection field, and the fields inside of it.
8) Create a node in default language (was English for me) and populate the field collection fields, save the node.
9) Go to translate tab, and add a translation (Spanish for me), the old values should be present in the FC form, and if you modify them and save the form, the new values should appear.

Personally I did more testing with FPPs + Field collections, rather than Node + Field collection, but to make it work for FPPs there is significant additional code required to be added to the FPP module.

england9911’s picture

I've followed instructions in #237, but get an error when trying to create a node:

Fatal error: Class 'EntityTranslationFieldCollectionItemHandler' not found in /sites/all/modules/entity_translation/includes/translation.handler_factory.inc on line 93

I've seen earlier in this thread people suggesting clearing cache to fix this issue, but that doesn't seem to help.

Any ideas?

alcroito’s picture

Yes I have the same issue if applied in Drupal project, that is because the patch should be applied against root folder of field_collection. If applied in project root, for some reason the includes folder is created in Drupal root, rather than in the field collection folder.
So simply move the includes folder with the file, into the proper place under field_collection module.

england9911’s picture

the patch was definitely run against the root of field_collection. The translation.handler.field_collection_item.inc file was created there e.g:

field_collection/translation.handler.field_collection_item.inc

I've manually put it in:

field_collection/includes/translation.handler.field_collection_item.inc

And the error has gone away. Maybe this was a permissions problem - the patch file looks fine.

liquidcms’s picture

from #237 above, is this correct:

7) Enable Field translation for both the Field collection field, and the fields inside of it.

isn't the goal here to enable field translation for the FC (or not, depending on how the patch works) and the fields inside it WHICH REQUIRE TRANSLATING?

liquidcms’s picture

deleted

liquidcms’s picture

Status: Needs review » Needs work

my test:
- latest -dev
- patch from #237 (almost applied cleanly, 1 line i had to do manually)

node (set as ET)
- class (fc, field set as translatable)
-- timetable (textfield, set as translatable)
-- slot (fc, set as non translatable)
---- various fields all set as not translatable

- first thing i notice is that the non translatable fields within class no longer state "all languages"
- the non translatable fields seem to be fine, if i change 1, the change appears on both lang versions
- the translatable field does not work. it shows the latest entered value (from whichever lang ver) on the edit form for either lang and on the view of the node it shows on only the original language ver of the node

so basically, the 1 translatable field does not appear to be translatable and doesn't get created at all for the 2nd lang.

jmuzz’s picture

FileSize
27.54 KB

The updateHostEntity function was committed for #2013811: field_collection_field_update() saves old host entity and overwrites changes. This version of the et patch is the same except it doesn't add that function.

RaulMuroc’s picture

So this issue should be closed as duplicate?

jmuzz’s picture

No, that one function that was written for this patch had a use outside of adding entity translation and was needed to fix a critical bug. This issue still needs resolution for adding entity translation to field collections.

liquidcms’s picture

my bad..for #243.. i see now that the patch did not apply completely. the includes file does not get created. will create changes manually and retest.

- didnt help; will need to go through and apply whole patch manually to be sure other parts not missed.

xumepadismal’s picture

I've rerolled patch against latest dev.

jwilson3’s picture

+++ b/field_collection.module
@@ -1182,22 +1273,29 @@ function field_collection_field_formatter_settings_form($field, $instance, $view
   if ($display['type'] != 'field_collection_fields') {
+    $elements['add'] = array(
+      '#type' => 'textfield',
+      '#title' => t('Add link title'),
+      '#default_value' => $settings['add'],
+      '#description' => t('Leave the title empty, to hide the link.'),
+    );
     $elements['edit'] = array(
       '#type' => 'textfield',
       '#title' => t('Edit link title'),
       '#default_value' => $settings['edit'],
       '#description' => t('Leave the title empty, to hide the link.'),
+      '#access' => field_collection_item_is_translatable(),

Shouldn't the #access =>field_collection_item_is_translatable() be on the $elements['translate'] instead of $elements['add']

joseph.olstad’s picture

Yes jwilson3 is correct, patch from #248 should be updated, the #access =>field_collection_item_is_translatable() should be on the $elements['translate'] instead of $elements['edit']

We're currently using field_collection 7.x-1.0-beta6+8-dev
with these patches:
- http://drupal.org/files/issues/field_collection-et-1344672-187.patch
- http://drupal.org/files/issues/field_collection-field_collection_uuid-20...
- http://drupal.org/files/issues/migration_field_collection-2298877-01.patch

and in our environment the #access =>field_collection_item_is_translatable() is on $elements['translate'] , not $elements['edit']

Otherwise people not using entity_translation would not be able to 'edit' . However those using 'entity_translation' will want to have the option to translate.

this is what I understand after reading the function field_collection_item_is_translatable()

Thanks,
Thanks

RaulMuroc’s picture

STATUS

  1. Latest dev field collection.
  2. Applied patch #248
  3. Fixed applying changes on #249

PROBLEM

The original (so the first created) field collection is shown (for ex: german lang). But the translations of it are not shown (ex: slovenian, spanish, italian).

LOOK INTO THE CODE

In field_collection.module, line 1365 inside function hook_field_formatter_view , I apply dpm($display, "display type"), and the following is shown:

Original field collection
label (String, 5 characters ) above
type (String, 21 characters ) field_collection_list
weight (String, 1 characters ) 0
settings (Array, 7 elements)
module (String, 16 characters ) field_collection

For each translation field collection
label (String, 6 characters ) hidden
type (String, 21 characters ) field_collection_view
weight (String, 2 characters ) 21
settings (Array, 9 elements)
module (String, 16 characters ) field_collection

I don't understand why the "type" is different (that makes in this function to call different swith cases), and also why in translation 'label' and 'values' are hidden (but not empty, values are either here so in DB as well).

CONCLUSION

Looks like if it is a READ/UPDATE of view_mode problem, not CREATE problem (talking on CRUD terms) as the data exists.

Tried to fix but don't find the point (sorry about that).

sinasalek’s picture

Issue summary: View changes

STATUS
Latest dev field collection.
Applied patch #248
Fixed applying changes on #249

PROBLEM
I'm having the same problem as @RaulMuroc
I did a bit more investigation :
Upon saving the translation i encountered the following notice twice :

Notice: Undefined index: instance in field_widget_instance() (line 603 of /modules/field/field.form.inc).

Note that it does not happen when saving the node with the field collection items at the first place and only happens when saving the translation.

I check the content of $field_collection var inside field_collection_field_formatter_view, in my case the problem is that the translation language is the original language for each translatable field :

sinasalek’s picture

Seems that the following notice is unrelated :

Notice: Undefined index: instance in field_widget_instance() (line 603 of /modules/field/field.form.inc).

It's caused by link widget

sinasalek’s picture

More insight on the issue,
- Upon creation of new node, the field collection item is saved twice, one record for the active language and one as Undefined (und).
- When adding a translation for another language, upon saving two more records are added. again one for und and one for active language
For the last record the delta is 1, but for the rest is 0, which does not seem correct

node 	blog_post 	0 	16 	17 	en 	0 	6 	9
node 	blog_post 	0 	16 	17 	fa 	0 	7 	11
node 	blog_post 	0 	16 	17 	und 	0 	6 	10
node 	blog_post 	0 	16 	17 	und 	1 	7 	12

- The field collection field i created contains a single translatable text field.
And here is its contents, as you can see both records language is en which is incorrect, second record should be fa

field_collection_item 	field_stuff 	0 	6 	10 	en 	0 	dfgfsdg 	NULL
field_collection_item 	field_stuff 	0 	7 	12 	en 	0 	تست 	NULL

So why there are two und record for field collection? and why translatable fields language is always equals the source language?

Lets see what happens if we add a non translatable field to our field collection field.
The news field table although i entered value for it is empty! but when i edit the node,
it's filled! i check the revision table and there it was. a new revision was added
Also the non translatable field did not sync between translations and remained separate, how?
Two different records where added to revision table!

The patch needs a serious review

Note that, for translatable fields, the language gets corrected after editing the translation so the incorrect language issue happens on creation

jmuzz’s picture

Status: Needs work » Needs review

You need to choose between having a field collection with translatable fields and having the field for it in its host be translatable. It doesn't make sense to combine the two. Chances are you want the fields inside the collection to be translatable. Try making the field for it in the host entity untranslatable.

sinasalek’s picture

Well you may have a point there but i tried that too and still encountered several issues like three records.
I suppose according to what you mentioned there should be only one for each language

table of a field collection field : 
node 	blog_post 	0 	18 	19 	en 	0 	10 	16
node 	blog_post 	0 	18 	19 	fa 	0 	11 	17
node 	blog_post 	0 	18 	19 	und 	0 	11 	18

Also the translations are stored inside the field table and as you can see language of them both is en, which causes the translation not to appear on view and can probably cause problem for edit too when a third translation
is added.
According to what you said, the language should be und

table of a non translatable field inside a field collection : 
field_collection_item 	field_stuff 	0 	10 	16 	en 	0 	fffffffffffff 	NULL
field_collection_item 	field_stuff 	0 	11 	18 	en 	0 	شسیبشسیبشس 	NULL

Also the problem with this approach is that all fields inside a field collection will become translatable which is not the way that entity translation works. for example if i have an age number field, it does not need to be translated and therefore should be available for translation. at least that's the way entity translation module works.
So when i make a field collection translatable, it means that what's inside it is translatable because field collection itself does not contain any value it's only a container for another entities.

As far as i know the are two use cases :
- field collection records are the same and their fields might be translatable
- field collection records may vary for each language and their fields are language specific and therefore non translatable

For Nodes, we have several options which cover almost all cases :
- Enabled
- Enabled, with translation
- Enabled, with field translation
For field collection i think we need only the first and the last.
So when enabling translation for a field collection we can decide whether we want each language to show different items or the same but translated.
There are more complex use cases also like mixing cross language items and per language ones, but i think that's out of the scope of this patch.

sinasalek’s picture

Also the reason we may need another option on field collection settings is because entity translation automatically removes the non translatable fields from the translation pages because apparently there is no point in showing them. But for field collection it causes problem because it's a container and the field inside it might be translatable and removing it makes it impossible for the fields inside it to be translated.
A alteration here can probably for entity translation not to remove field collection fields from the translation pages

jmuzz’s picture

You can choose which fields in your field collection are translatable if you make the field corrosponding to it in its host untranslatable. If you make its field in its host translatable then there will be a separate copy of the field collection (or group of field collections if it is a multiple entry field) for each language and in that case all of the fields in it will be translatable and the translation options you have set for the fields inside the field collection will not work and probably cause problems if some of them are translatable, so you have to choose one or the other, you can't have both the fields inside the field collection translatable and also the field corrosponding to the host in the field collection translatable.

Most likely scenario is you want to have the same data in each translation but with different text. In that case you want to make the field for it in the host untranslatable. There will just be one field collection item (or one group if it is a multiple entry field) in the host and it will have 'und' language. The fields inside the field collection will have 'und' for the untranslatable fields and separate entries for each language in the case of the translatable fields.

You will need to turn off the option to hide untranslatable fields if you want to do it using the embedded widget. Another option is to use the form pages for the individual field collection items linked from the "field collection" formatter or "links to field collections" formatter.

jmuzz’s picture

I think I understand the previous comment better. There's been an outstanding issue with this patch where the embedded widget will put the (all languages) clue on every subfield in a field collection item if the field for it in its host isn't translatable. It should still function correctly despite the hints.

Here's a version of the patch that makes an attempt to get those hints set correctly.

sinasalek’s picture

Tx alot for the quick update i'll test test patch
If i want to the field collection items to be the same all languages but the fields inside them translatable. Do i still need this patch?

jmuzz’s picture

Yeah definitely, that's mostly what the patch is for.

If you want the field for it in its host to be translatable instead then a simpler solution might work. I think #108 was only trying to get that working.

sinasalek’s picture

I tried you suggestion with and without the patch but it doesn't work. Even though the fields inside the host are translatable and field collection is set to non translatable, still when i save the node and its translation the values are the same and the change on all translations.

jmuzz’s picture

Status: Needs review » Needs work

Thanks sinasalek.

Both ways should work before the patch is committed.

sinasalek’s picture

You're welcome, you can count on me to review and test the patches quickly :)

jmuzz’s picture

Status: Needs work » Needs review
FileSize
30.06 KB

I wasn't able to duplicate the behavior described, but I did make a change to stop the extra LANGUAGE_NONE field collection item from getting created.

If it's still happening, can you give details about how to duplicate it from a clean install?

sinasalek’s picture

Sure, i'll get back to you with more accurate insight

sinasalek’s picture

Here is the first insight :
- Fresh Drupal install
- i18n + entity translation
- Enabled locale module and added two languages
- Language detection for both interface and content set to URL
- field collection dev with patch applied
- Created a content type :
- Enabled, with field translation
- Skills : field collection field is set to non translatable
- Name text field : translatable
- Years integer field : non-translatable
- Created a new content in english
- Added one items to skills
- saved and added a translation for Persian language.
- Entered translation for Skill item , name field
- Saved

Issues :
- When viewing the created node in English, the skill name field appears as translated! and the original value is overwritten after saving the translation
- In node translation page, near the label of Skill Name field it's written (all languages)!
- When viewing the translation , the skill name does not appear as if it's empty
- In database tables of field collection and years field show only one und record which is correct but for skill name tables, there is only one en record. but there should be one record for each language.

Ok now test it with translation field collection host :
- The only problem i encountered was that, i created a translation for the node, and removed the skill item added previously upon creating the node and saved. but on node translation view, the items was shown.
I edited the translation, and nothing was there! so i added an items saved it (new items appear), edited the original node , removed the skill item and saved. Now the item i added for translation appeared!

Note that database records where correct, it seems that there is a problem with field collection view

jmuzz’s picture

You tested the case where the field in the host is not translatable, and there are translatable fields in the field collection first, right? You need to set field collection items as one of the translatable entity types at /admin/config/regional/entity_translation before that will work.

Before testing the case where you make the field in the host translatable make sure none of the fields inside the field collection are translatable.

chipway’s picture

Tested this patch on dev.

Node type page with a translatable field collection field_block (title untranslatable, type untranslatable, body untranslatable).

Previous errors :
1) When we added a translation we got undefined language on field_blocks attached to the translated node.
2) Then, when we saved an edited field_block, it added a duplicate (und language) item for the updated item. And the original item was not updated but displayed in view.

After applying the patch, we can add a translation for our field collection host node, and get all field_blocks saved. During the translation, we can remove some field_block item or add new ones.

field_collection-et-1344672-265.patch works, for our use case.

sinasalek’s picture

@jmuzz, thanks for the explanation. now it works. However the behavior is still not entirely correct.
- When i remove a field collection item on any translation or even the original one, it is not removed from the rest of them and still appears. Only the translation is remove, making it show for example the translation value for the original language. When i edit the node add a new item, it does not appear for translations which makes it impossible to translate the new item via node UI.
- When the source language of the node and also the field collection item is set, it still shows (all languages) near translatable field inside field collection. however it's fine on translations when adding them for the first time but when editing, again it shows (all languages)

alcroito’s picture

I believe I have found the problem related to why (all languages) appears for all fields in the field collection widget, related to what @sinasalek mentions in comment #271, point 2.

It is indeed correct to set the '#multilingual' property on the field collection widget element, but it is also necessary to set the property on all the translate-able field widgets inside the FC widget. This is usually done automatically by the entity_translation module in the "entity_translation_field_attach_form()" hook, specifically line ~1220, where it does this check.


// Handle fields shared between translations when there is at least one
    // translation available or a new one is being created.
if (!$handler->isNewEntity() && ($new_translation || count($translations->data) > 1)) {
      $shared_access = $handler->getSharedFieldsAccess();
      list(, , $bundle) = entity_extract_ids($entity_type, $entity);
      foreach (field_info_instances($entity_type, $bundle) as $instance) {
        $field_name = $instance['field_name'];
        $field = field_info_field($field_name);
        // If access is not set or is granted we check whether the user has
        // access to shared fields.
        $form[$field_name]['#access'] = (!isset($form[$field_name]['#access']) || $form[$field_name]['#access']) && ($field['translatable'] || $shared_access);
        $form[$field_name]['#multilingual'] = (boolean) $field['translatable'];
      }
    }

The problem is, the conditional fails, because count($translations->data) will return == 1, if you have for example only English and Spanish, whereas to pass the conditional it has to be at least two.

I assume it works for nodes for example, because the original "English" is also considered a translation, so the count equals 2.
If you look at the comment it says that at least one translation has to be available, so maybe this is a bug in entity_translation, and the check should actually be "count($translations->data) >= 1".

Alternatively we could copy the same code which entity translation does, and execute it in a hook_attach_form (or somewhere), specifically for field collections only.

Regarding point 1 in comment #271, I cannot reproduce this case, if I delete one FC item, it is also removed from the translations as well.

For me, applying the latest patch in #265, actually fixes both use cases: when the FC is not translateable, and the fields in it are, and second case when the FC is translateable, and the fields inside are not.

It seems like the patch got to the point where it's mostly usable.

alcroito’s picture

Attaching patch with proposed fix to reimplement entity_translation behavior, for setting the '#multilingual' property for FC widgets.
That is the only change from the # 265 patch. This should make the labels (all languages) appear only for non-translateable fields.

Alternatively, you can try and use the patch I've posted against entity_translation, here -> #2371065: Translation "Shared Fields Handling" check is not correct

xumepadismal’s picture

#273 works well for me. Shared labels is OK now.

I have a question though. #237 changed ::getLanguage() logic to use ->getFormLanguage() instead of ->getLanguage(). I believe there IS a reason of doing that, but I'm experiencing a bug related to this change. I have non-translatable FC field with multilingual fields in it. This FC is attached to the node type with 'embedded' widget. And when I trying to add translation to the Node, that translation is OK, but for all other languages it shows 'Translation unavailable' message for FC field. However, when I click 'Edit', I can see all the values in the form for all languages.

Changing ->getFormLanguage() back to ->getLanguage() fixes this problem nicely, but I have no idea what bug(s) it can (re-)introduce.

alcroito’s picture

@274
I've changed the getLanguage() to getFormLanguage() because of an issue how values were saved when adding a translation, and on a subsequent edit, didn't show the stored values. Like you I'm not certain if that was a cause of the error, or a symptom of something else.

We can try to re-roll the latest patch without the getFormLanguage() call, and see if we have any regressions, when people review the patch.
But personally, I did not encounter your problem.

Did you make sure that after applying the patch, you enabled entity translation FC translation handler, and that the handler was in the proper folder after applying the patch, and not in drupal root?

xumepadismal’s picture

@Placinta, yes I applied patch properly in the FC folder and the handler is enabled.

However, I will install clean Drupal with ET & FC and come back with all steps to reproduce the bug.

xumepadismal’s picture

So, I figured out that this problem appear only with disabled language fallback in ET settings. Here are the steps:

  1. Drupal 7.33 + ET-dev + FC-dev + #273-patch
  2. Add few languages and configure detection and selection
  3. Content type 'Article' translation: enabled, with field translation
  4. Add FC field 'field_gallery' (image + description) to the 'Article' node type as embedded widget
  5. ET settings: enable translation handler for 'field_collection_item' entity type.
  6. ET settings: disable language fallback
  7. Make these fields translatable: node:article:body; field_collection_item:field_gallery:description
  8. Add new article in e.g. EN
  9. Add translation to e.g. Swedish
  10. View english version (I see 'translation unavailable' message in place of field_gallery)
  11. If I edit this english translation, it would appear, but then I see 'translation unavailable' on the Swedish translation

And here is the cause/guess: \EntityTranslationDefaultHandler::saveTranslations deletes ALL records for the current entity from 'entity_translation' DB table and then inserts all available translations. So \EntityTranslationFieldCollectionItemHandler::getLanguage is called for each translation of the node. Hence we can't rely on getFormLanguage() here because it returns the same language for all translations which is not correct.

Meanwhile, I'm not experiencing any degradation on using ->getLanguage() so far. So it would be great to modify it and let people to review, as you mentioned above :)

alcroito’s picture

Yes, I can reproduce your issue, and indeed changing getFormLanguage to getLanguage fixes it.

But sadly it introduces the regressions I've encountered before, specifically:

If the FC field is not translatable, and the fields are inside are translatable / non-translatable, everything works fine.
If the FC field is set to translatable then:
- non-translatable fields inside the FC work fine
- translatable fields inside the FC do not work properly.

What doesn't work for the last case:
- When adding a translation for the first time, any values you enter in the translatable fields in the FC, are lost upon save. Aka after adding the translation, and editing it, the value will not show up in the widgets. If you enter the values a second time, and save the translation, it will save the values. But,
- Some funky stuff happens in the database. The actual values on the first save are not lost, but are saved with an improper languages set ( the original language). When you save the translation a second time, the values are saved with the proper translation language.
- When you delete the node / node translation, the created FC entities for translations are not removed, neither from the fields tables, nor from the field_collection_item table.

So I'm not sure what's the best course of action here. If we change getFormLanguage() to getLanguage(), we lose the ability to use the second use-case of FC translation:
FC field is translatable, as well as the fields inside.

sinasalek’s picture

Can't we decide which one to use depending on field collection language settings ?
for example if the field collection is translatable using getFormLanguage

alcroito’s picture

We can try doing that, but the issue with language fallback that @xumepadismal mentioned, will probably still be present.

xumepadismal’s picture

It rather strange but it seems that I can see all problems discribed in #278 regardless of using ->getLanguage() or ->getFormLanguage() :/
@Placinta, could you check this please?

jagilpe’s picture

Hi! I'm working in a project where we are using the field_collection module in a multilanguage site translated using Entity Translation. We had to develop a patch for field_collection in order to support the entity translation in the use cases that we have in our project.
We have tested the patch uploaded in #273, to see if it works in all our use cases but we have found two where it doesn't work as we expected. Specifically:

  1. If we have a translatable field in a field_collection it's not shown when viewing the node/entity the field collection belongs to.
  2. We need to support translatable fields in field collections because we may need to add a field that is already used in another entity type, where it needs to have entity translation enabled. This is a field-wide configuration and therefore we can not disable it only for the field collection case.

  3. If we add a translation programmatically the field collection item of the original language is deleted.
  4. We are working in a module that tries to ease the translation workflow in an multilanguage environment with complex content structures, and we need to support the creation of translation, not only with the normal translation edit form, but also programmatically.

We have also written tests for different use case and scenarios.
Attached is this patch against the latest dev version.

seanr’s picture

@jagilpe - your reroll is missing includes/translation.handler.field_collection_item.inc and the reference to it in field_collection.info. What happened there?

jagilpe’s picture

The patch was written from the latest dev version of the module, and before the patch of #265 was uploaded, and therefore is not this file in the patch. We used a language callback instead of an EntityTranslationHandler to return the language of the entity.
I have modified our code starting from #273 to include the EntityTranslationHandler.
Now all our test pass, with the exception of one of them. When a new field_collection item is added programmatically the translatable field is not saved.

seanr’s picture

I'm attempting to test that patch, but after configuring everything I now get Maximum function nesting level reached no matter how high I set the option (even 800 gets hit). Are there any configurations that could cause this or would we be looking at a code issue? It's getting caught in a loop with these three functions called over and over:

[Mon Nov 17 16:31:57.477048 2014] [:error] [pid 69498] [client 127.0.0.1:52869] PHP 797. EntityTranslationDefaultHandler->setFormLanguage() /Volumes/Macintosh HD/Users/robertson/Sites/wweglobal/html/sites/all/modules/contrib/entity_translation/includes/translation.handler.inc:484, referer: http://wweglobal.localhost/en/node/26675653/translate
[Mon Nov 17 16:31:57.477058 2014] [:error] [pid 69498] [client 127.0.0.1:52869] PHP 798. EntityTranslationDefaultHandler->notifyChildren() /Volumes/Macintosh HD/Users/robertson/Sites/wweglobal/html/sites/all/modules/contrib/entity_translation/includes/translation.handler.inc:1045, referer: http://wweglobal.localhost/en/node/26675653/translate
[Mon Nov 17 16:31:57.477066 2014] [:error] [pid 69498] [client 127.0.0.1:52869] PHP 799. call_user_func_array() /Volumes/Macintosh HD/Users/robertson/Sites/wweglobal/html/sites/all/modules/contrib/entity_translation/includes/translation.handler.inc:484, referer: http://wweglobal.localhost/en/node/26675653/translate
loopduplicate’s picture

I had similar issues to #285. I couldn't get the patch in 284 to work. 273 seems to be ok for the project I'm working on but I still need to test more to be sure.

seanr’s picture

This is actually happening on all nodes with field collections, even with types not set to be translatable.

seanr’s picture

Something is still very wrong here with the patch from 273. Translating to the first language after the source language works, but then when you try to add a third language, all translatable fields end up blank. Furthermore, when you go to the direct URL for translating that field collection item (i.e. http://example.com/en/field-collection/field-poll-options-collection/264...) you see the second language showing as the source language and the original shows as untranslated. When I go to the entity_translation table in the database, there is only one record for the item, with the language listed as french (which was actually the second language - it was originally set to english). If I actually do save the third translation, I then end up with two records, one set to the third language with the second as the source, but then the previous language is actually set to what it originally was (WTF?!?!?). Here's the status of the entity_translation table after these shenanigans:

entity_type	entity_id	language	source	uid	status	translate	created	changed
field_collection_item	26462223	de	fr	26000667	1	0	1416415155	1416415155
field_collection_item	26462223	en		26000667	1	0	1416259399	1416259399
seanr’s picture

Furthermore, I'm noticing that new nodes created with field collections don't appear to be saving their field collection items at all right now.

seanr’s picture

OK, second problem is specific to that site's codebase. Doesn't do that on a clean install, but the first bug mentioned in #288 does happen. Interestingly, if you go back and save the source language after adding a translation, the source language record gets saved correctly and then adding the third language will work. So we're not saving the record correctly when creating a new field collection or setting one as translated for the first time (still only in source language, but no longer und).

seanr’s picture

@jagilpe - what's going on here in your patch from #284?

+          // This is the source form for a translation with field translation, therefore we must clone the field collection item
+          $new_entity = clone $field_collection_item;
+          $new_entity->item_id = NULL;
+          $new_entity->revision_id = NULL;
+          $new_entity->is_new = TRUE;
+          $field_state['entity'][$delta] = $new_entity;
+          $new_entity->setHostEntity($element['#entity_type'], $element['#entity'], 'de', FALSE);
+
+          $new_entity->check = 'delta_' . $delta;
+
+          $field_state['entity'][$delta] = $new_entity;
+          field_form_set_state($field_parents, $field_name, $language, $form_state, $field_state);
+          field_attach_form('field_collection_item', $new_entity, $element, $form_state, LANGUAGE_NONE);

Specifically this seems very wrong:

$new_entity->setHostEntity($element['#entity_type'], $element['#entity'], 'de', FALSE);

I'm pretty sure that's the cause of the infinite loop in your patch. Also, why the hardcoded 'de'?

seanr’s picture

Here's an updated patch which fixes the issue for me, but I'm not sure this is the right way to handle this. Would very much like some thoughts on this. I've attached my patch as well as an interdiff between this and 284 to facilitate review.

seanr’s picture

Incidentally, the important part of that is the last hunk in the interdiff (the rest was getting 273 into a working state). Basically, updateTranslations() calls setOriginalLanguage() which for reasons I simply cannot understand runs $translations->data[$langcode] = $translations->data[$translations->original]. What's the purpose of replacing the current language data with the original language data? It works with nodes which have their own language property (which always seems to be the source language), but it breaks field collections pretty badly.

fxfx’s picture

Hi Sean did u get ET work with ur last patch #292 ?

My setup is a CTYPE with a Field, (FIELD Collection) Translation Enabled and than inside field collection enabled translation for a DESCRIPTION FIELD

i started from the latest dev 04 Nov. i applied patch #292 directly i tried to enable also FC as tralatable entity but in all cases i get the handler ERROR

Can you tell me how should i proceed to get the FC work with ET?

opdorp’s picture

Hi, i had the problem with ET that the host entity had 2 languages with the same Field Collection item.
I started with the patch from #265 and added these 2 lines.

I gave the right langcode to the set the host entity so it wouldn't make an unused LANGUAGE_NONE field collection entity.

Status: Needs review » Needs work

The last submitted patch, 295: field_collection-et-1344672-295.patch, failed testing.

The last submitted patch, 228: field_collection-et-1344672-228.patch, failed testing.

fxfx’s picture

ok So i need to apply your #295 from a clean instal of the dev version?

seanr’s picture

fxfx, you should apply the .patch file (not the interdiff) from 292 to a clean copy of the dev version. The patch from 295 I believe would apply on top of that.

opdorp, please reroll that as a complete patch including the changes from the previous patch so it can be tested more easily.

sarath.rajan’s picture

Can anybody help me to translate a Field Collection field using Entity translation?

seanr’s picture

Updating shown files - #295 was only a partial patch (I think a patch against a patch?) so hiding it from the main list. Also hiding some older patches that have been superseded.

seanr’s picture

Status: Needs work » Needs review

Also, moving back to Need Review (since the needs work was generated by the aforementioned erroneous patch).

james.williams’s picture

The attached patch is the one from comment 292, plus the change from comment 295's interdiff (if I've understood it correctly). This has not been tested (sorry!), but has been put together for the convenience of those looking to move this issue forward.

seanr’s picture

That patch seems to be missing includes/translation.handler.field_collection_item.inc.

maxplus’s picture

Hi,
patch from #304 applied OK on the current dev version for me.
I uploaded to my live site and it works

Thanks!

colan’s picture

Status: Needs review » Needs work

Updating status based on #305.

emasclans’s picture

I currently have:
Field collection 7.x-1.0-beta6+21-dev
Entity Translation 7.x-1.0-beta3+21-dev
Internationalization 7.x-1.11

I apply the patch and I get this error when creating new Field collection field...

EntityMalformedException: Missing bundle property on entity of type node. in entity_extract_ids() (line 7766 of ...includes\common.inc).

Any idea?

Eugeni

jwilson3’s picture

Status: Needs work » Needs review
FileSize
59.59 KB
1.99 KB

Added back translation.handler.field_collection_item.inc

alcroito’s picture

Tested latest patch in #309 using Nodes and Fieldable panel panes. Used latest DEV version of FPP and Entity Translation and Field Collection with this patch.

Node with 1 untranslatable unlimited-value FC (but with translatable fields inside it) works.
FPP with 1 untranslatable unlimited-value FC (but with translatable fields inside it) works.

Node with 1 translatable unlimited-value FC (and with translatable fields inside it) partially works.
When deleting the node, some stale values for FC fields remain in the DB.

FPP with 1 translatable FC (and with translatable fields inside it) partially works.
On first save / insert field collection values are not saved. On second save they are saved.
When you add a translation from English -> Spanish, the old FC values are not copied over, so you get an empty widget.
But once you add the values again, it seems to work properly.

Also sometimes a LANGUAGE_NONE entry for the FC fields is created.

Bottom line, untranslatable FC (with translatable fields inside them) seem to be usable.
Translatable FCs (with translatable fields inside them) still needs some work.

seanr’s picture

It would seem to me the FPP should be tested after we ensure the base functionality with nodes is working correctly - it might even resolve itself at that point, or prove to be an issue with FPP.

Also, can someone explain to me the specific use case in which you'd want the FC field on the host entity to be translatable as well as the fields within the FC? Wouldn't that be redundant, and maybe even conflicting? How would you ever see or edit the translated values of the FC's fields if the host FC field was itself translated? I'm wondering if the patch should actually prevent you from enabling both at the same time - force it to be an either-or thing.

sinasalek’s picture

@seanr I also don't think that having both Host and fields translatable has any use case. Preventing the user from setting it saves us lots of incorrect bug reports

alcroito’s picture

@seanr I can give you an example when that happens.

Say you have Node type Slideshow, and an unlimited value FC called field_slide_fc, sou can create a slideshow, with multiple FCs serving as slides.
Now, in case if the FC is untranslatable, but the fields inside it are translatable, that means that all language versions will have the same number of slides, and the only thing you can control is changing the contents of the slide, so you're stuck to 3 slides on all languages of the node.

If the FC is translatable, that means you get separate FC ids for each field collection, which means Language A can have 4 slides, whereas language B has 7 slides.

Now how can it happen that there are also translatable fields inside the translatable FC? Simple, if you re-use fields in multiple content types, like the Title field, you want to enable translation for the title field. And you add the title field to the slide FC so you each slide has a title, and bam -> translatable field in translatable FC.

Of course someone will come along and say, just create another title field that is untranslatable, but that defeats the purpose of re-using fields, which IMO is a good practice.

Regarding to "how can you see / edit the translatable field inside the FC", currently in the DB both fields are saved and loaded with the same lang code, so that's how you see and edit. E.G:
ID1 FC langcode EN
- title_field langcode EN

ID 2 FC langcode ES
- title_field langcode ES.

The widget code loads the same language codes for both the FC and fields inside it.

jmuzz’s picture

Status: Needs review » Needs work
FileSize
56.55 KB

Untested reroll for latest dev.

@placinta makes a good point it should be possible to reuse an existing translatable field in a field collection referred to in a translatable field since it is possible to reuse translatable fields in content types that are not translatable.

jmuzz’s picture

#314 was missing required changes to field_collection.entity.inc .

jmuzz’s picture

Status: Needs work » Needs review

What exactly is the problem with translatable field collection items with translatable fields in them? I tried the example described but it seemed to work ok and after deleting the node no values from it were left in the field_data tables for the field collection item field or the fields in it.

jmuzz’s picture

Status: Needs review » Needs work

Created an untranslatable content type with a field collection nested in a field collection. The deeper field collection contains a text field. No fields are translatable but the patch is applied and entity translation is activated for field collections. When creating a new node of this content type it mostly works but immediately after saving this notice appears:

Notice: Undefined property: FieldCollectionItemEntity::$language in field_collection_field_insert() (line 479 of /home/jmuzz/devel/local.d7.com/sites/all/modules/field_collection/field_collection.module).
jmuzz’s picture

Status: Needs work » Needs review
FileSize
59.67 KB

That notice should be fixed.

alcroito’s picture

Haven't tested the patch yet, but one thing to keep in mind is that the added tests in the patch are not executed by the test bot. Probably because test_dependencies[] = entity_translation wasn't set?

Also the tests to do not enable translation of field collections at 'admin/config/regional/entity_translation', which is required to make translation work properly.

jmuzz’s picture

Thanks @Placinta.

Can you take a look at #316 because I really do not understand what the issue was.

jwilson3’s picture

jmuzz *please* attach interdiffs, its quite hard to see whats changing between versions.

jwilson3’s picture

FileSize
628 bytes
3.08 KB
jwilson3’s picture

Status: Needs review » Needs work

NW per #319.

jmuzz’s picture

I still don't get in what way translatable fields inside translatable field collections aren't working correctly.

alcroito’s picture

Haven't been able to test the latest patch yet, maybe over the weekend.

But I wanted to point out, that the entity translation tests still aren't running for some reason.

jmuzz’s picture

Status: Needs review » Needs work

Another problem with nested field collections. I have an unlimited cardinality field collection with an unlimited cardinality field collection inside it and a text field inside that. No fields are translatable and the content type is not translatable, but entity translation is active for field collections. I can "Add another item" on one level of the embedded form (child or parent field collection) as many times as I want, but then when I try to add another item on the other level it seems to have an infinite recursion causing a function nesting level error. Here is a part of the trace:

0.1121   24379664  23. EntityTranslationDefaultHandler->notifyChildren() /home/jmuzz/devel/local.d7.com/sites/all/modules/entity_translation/includes/translation.handler.inc:1045
0.1121   24380440  24. call_user_func_array() /home/jmuzz/devel/local.d7.com/sites/all/modules/entity_translation/includes/translation.handler.inc:484
0.1121   24380776  25. EntityTranslationDefaultHandler->setFormLanguage() /home/jmuzz/devel/local.d7.com/sites/all/modules/entity_translation/includes/translation.handler.inc:484
0.1121   24381240  26. EntityTranslationDefaultHandler->notifyChildren() /home/jmuzz/devel/local.d7.com/sites/all/modules/entity_translation/includes/translation.handler.inc:1045
0.1121   24382136  27. call_user_func_array() /home/jmuzz/devel/local.d7.com/sites/all/modules/entity_translation/includes/translation.handler.inc:484
0.1121   24382472  28. EntityTranslationDefaultHandler->setFormLanguage() /home/jmuzz/devel/local.d7.com/sites/all/modules/entity_translation/includes/translation.handler.inc:484
0.1121   24382936  29. EntityTranslationDefaultHandler->notifyChildren() /home/jmuzz/devel/local.d7.com/sites/all/modules/entity_translation/includes/translation.handler.inc:1045
0.1121   24383712  30. call_user_func_array() /home/jmuzz/devel/local.d7.com/sites/all/modules/entity_translation/includes/translation.handler.inc:484
0.1121   24384048  31. EntityTranslationDefaultHandler->setFormLanguage() /home/jmuzz/devel/local.d7.com/sites/all/modules/entity_translation/includes/translation.handler.inc:484

It keeps going like that.

jmuzz’s picture

It may have something to do with translation handler IDs being reused. They should probably be unique, but since they are generated by separate AJAX requests the counter gets reset. I replaced "self::$newId++" in translation.handler_factory.inc with "rand()" as a quick test and the error no longer occurs.

wla_g’s picture

There is an error in the field_collection.info file. The translation handler is not in the includes subdirectory (that doesn't exist) and from that I've got the error "PHP Fatal error: Class 'EntityTranslationFieldCollectionItemHandler' not found". After fixing the .info file the error vanished.

jmuzz’s picture

@wla_g A couple of times an incomplete version of the patch that didn't include these files got uploaded but the most recent version of the patch should create the directory and the file. It is the last thing in the patch file if you want to see it. You can add the file manually from that if applying the patch doesn't work.

jmuzz’s picture

Status: Needs work » Needs review

I'm no longer able to duplicate the infinite loop I was seeing before.

jmuzz’s picture

FileSize
1.25 KB
61.08 KB

Oh yeah I actually fixed the infinite loop. I am not sure if this is the best way, as I don't understand why reusing these IDs would cause the loop in the first place, but it seems to work.

Soul88’s picture

Status: Needs review » Needs work
FileSize
462.79 KB

Hello, Joel. I've tried your patch, but unfortunately the content of the field_collections disappear from the node edit form after I apply your patch and run update.php. (You can still see the content on the node view page)

In order to try to reproduce it you would need to download and enable the following modules:
drush en admin_menu devel module_filter -y
drush en smartling -y
drush en smartling_reports -y
drush en smartling_demo_content -y

And I attach my test DB

P.S. You can ping me on skype if you need mode info - skype: soul-dreams
Scencerely yours,
Kostya

ciss’s picture

@jmuzz: Since misconfiguration can be a source for false error reports, do you think you could create a feature (or a db dump) of your testing installation (configuration, fields, node types etc) and provide a list of the module versions/revisions you're using?
That would allow others to reproduce your results and determine errors that get introduced by other modules or misconfiguration.

(On a side note: I can also imagine that some people have thoroughly screwed up their installations by now by applying some of the intermediate patches in production.)

jmuzz’s picture

Status: Needs work » Needs review
FileSize
61.08 KB
596 bytes

Thanks @Soul88, fixed a bug in the update that was preventing it from doing anything.

@ciss I wipe my test installation regularly, and as far as I know I'm using the latest version of everything. In any case that is what the target should be, not necessarally the versions that I happen to have right now.

I agree about the misconfiguration problems, I will try to add some information to the README to address them.

jmuzz’s picture

FileSize
63.23 KB
2.15 KB

README updated.

Soul88’s picture

Unfortunately I've got error on the same DB:

The following updates returned messages

field_collection module

Update #7007
Failed: EntityMalformedException: Missing bundle property on entity of type field_collection_item. in entity_extract_ids() (line 7766 of D:\OpenServer\domains\smartling.loc\www\includes\common.inc).

:(

daro.pl’s picture

I've got following notices

Invalid base path defined for entities of type Field collection item: matching menu item not found for field_collection_item/%field_collection_item
Invalid view path defined for entities of type Field collection item: matching menu item not found for field_collection_item/%field_collection_item
Invalid edit path defined for entities of type Field collection item: matching menu item not found for field_collection_item/%field_collection_item/edit
Invalid translate path defined for entities of type Field collection item: parent menu item not found for field_collection_item/%field_collection_item
The entities of type Field collection item do not define a valid path scheme: it will not be possible to translate them.

Soul88’s picture

Status: Needs review » Needs work
jmuzz’s picture

Can anybody provide steps to reproduce these errors from a clean install?

Georgique’s picture

Sorry, requested retest of an old patch just by occasion.

Georgique’s picture

What this line in EntityTranslationFieldCollectionItemHandler::getLanguage() means?
$handler = $this->factory->getHandler($host_entity_type, $host_entity);
Seems that factory is an undefined property...

jmuzz’s picture

You will have to look at the relevant classes in the entity translation module to understand that line.

How did you get it to give you an undefined property error?

Can anybody provide the steps to reproduce any of these reported error messages from a clean install?

Georgique’s picture

I'm not reporting any errors yet. :)
That was just my code where I create field collections programmatically, it worked with unpatched FC module, and became buggy with patched one. Now seems I fixed it, no errors. Update also was fine.

Georgique’s picture

You will have to look at the relevant classes in the entity translation module to understand that line.

I've rechecked and can now say following:

  1. Class EntityTranslationFieldCollectionItemHandler uses "factory" property in getLanguage() function. This property is not defined in this class.
  2. This class extends EntityTranslationDefaultHandler class which also does not have factory property defined.

When this line is executed I always have an error about undefined property. I have a node which is translatable. When I try to create field collection for this node which is not translatable, that is when the line is executed.
I'm pretty sure there is a bug here.

jmuzz’s picture

@Georgique Are you using the latest version of entity translation? EntityTranslationDefaultHandler should have a factory property.

Georgique’s picture

@jmuzz Just got ET beta4 update, now I see factory property.
We should add version requirement to dependencies in FC module.
Will test the patch further.

jmuzz’s picture

Status: Needs work » Needs review

I'm going to put this back to needs review. Please don't change it to needs work unless steps can be provided to reproduce any problem behavior.

Seems like it is mostly working now. It might make sense to commit it and save any remaining issues for future tickets. Thoughts?

ciss’s picture

@jmuzz: I wholeheartedly agree. This issue has become a mixed monster that's hardly maintainable anymore.
Someone who's deeply familiar with the problem should probably take a second look (e.g. Placinta). Beyond that, I'd vote for commit and close.

Georgique’s picture

I can confirm it works for me. So I'm also +1 to commit.

sinasalek’s picture

Since without this patch, field collection is unusable for entity translation, as long as it does not cause problem in normal usage which it doesn't it seems, i think it would be a good idea to do a final review and commit it. if there was any reproducible problem, they can be taken care of separately.
I'm always against big patches, keeping up with the dev wastes lots of energy

jmuzz’s picture

Status: Needs review » Needs work

Soul88 actually did provide the test data (#332) used to generate the error (#336) he reported.

omarlopesino’s picture

I applied the patch and i can translate a field collection, but i found several bugs.
I was using entity_translation in the development version.

1) I can't translate the fields of the field collection separately. In addition, if i have an entity with a field collection, and only i enable translation for one field of the field collection, i can't add translations.

2) When i'm adding the translation, if i have to change the image, i can't. When I click the remove button it doesn't happen anything. I have to save the translation and edit the translation again.

Georgique’s picture

Status: Needs work » Needs review
FileSize
63.21 KB
1.77 KB

My five cents:
1. Removed blank string.
2. Removed line where we retrieve translation handler which will never be used.
3. ET setting "Show shared labels" was not respected. Fixed this.

alcroito’s picture

Status: Needs review » Needs work

Tested latest patch in #355 using Nodes and Fieldable panel panes. Used latest DEV version of FPP and Entity Translation and Field Collection with this patch.

Node with 1 untranslatable unlimited-value FC (but with translatable fields inside it) works.
FPP with 1 untranslatable unlimited-value FC (but with translatable fields inside it) works.

Node with 1 translatable unlimited-value FC (and with translatable fields inside it) partially works.

The previous issue "When deleting the node, some stale values for FC fields remain in the DB." is still present, here is how to reproduce.
0) Have a node CT with 1 translatable unlimited-value FC (and with translatable fields inside it)
1) Add a node in English language with 1 field collection item.
2) Click translate to Spanish, and save the translation node.
3) Click edit for the translation node, and then click Delete translation.
4) Click edit for the original node, then click delete node.
Now check the database, and you should have stale values in the field_data/revision of fields inside FC, as well as in field_collection_item/revision tables.
Note that if you don't delete the translation first, but delete the original node (which deletes all translations), the issue does not happen.

There is another issue which I stumbled upon.
0) Have a node CT with 1 translatable unlimited-value FC (and with translatable fields inside it)
1) Add a node in English language with 4 field collection items.
2) Then click translate to Spanish.
3) Click "Add another item" once, the 4 previous FC items will be removed, and only 2 will remain, with the original data in them.
4) Click "Add another item" one more time, and a third item will appear, which is empty, and does not contain the original data.
I suppose it is somehow related to the fact that the FC item count is considered to be equal to 1 on the translation add page.

FPP with 1 translatable FC (and with translatable fields inside it) partially works.

On first save / insert field collection values are not saved with a proper language code, which means on view you see the values, but when editing, the widget is empty. On second save they are saved properly.
Also a LANGUAGE_NONE entry for the FC fields is created, which is linked to the problem described above.

You cannot delete an FPP translation, only the original FPP entity, together with all other translations.

One more usecase that I tested, I will use indentation to show fields inside other fields:

Article Node CT
- title_field - title field (translatable)
- field_fc - Field collection (translatable) unlimited
   - title_field - title field (translatable)
   - field_text1 - text (translatable)
   - field_fc_inner - Field collection (translatable) unlimited
      - title_field - title field (translatable)
      - field_text1 - text (translatable)

So every field is translatable. Now to the use-case.

1) Add a Node in English with some text added in fields, and at least two field collection items (both inner, and outer), save it.
2) Click translate to Spanish, just click Save, and I get a fatal error.

( ! ) Fatal error: __clone method called on non-object in /d7ml_fpp/sites/all/modules/field_collection/field_collection.module on line 1383
Call Stack
#	Time	Memory	Function	Location
1	0.0000	302064	{main}( )	../index.php:0
2	0.0134	2306680	menu_execute_active_handler( )	../index.php:21
3	0.0135	2307616	call_user_func_array:{/d7ml_fpp/includes/menu.inc:517} ( )	../menu.inc:517
4	0.0135	2308552	entity_translation_add_page( )	../menu.inc:517
5	0.0135	2310640	_entity_translation_callback( )	../entity_translation.module:690
6	0.0135	2310784	call_user_func_array:{/d7ml_fpp/sites/all/modules/entity_translation/entity_translation.module:701} ( )	../entity_translation.module:701
7	0.0135	2311208	node_page_edit( )	../entity_translation.module:701
8	0.0136	2311808	drupal_get_form( )	../node.pages.inc:14
9	0.0136	2312864	drupal_build_form( )	../form.inc:130
10	0.0149	2952304	drupal_process_form( )	../form.inc:385
11	0.0597	4829512	drupal_validate_form( )	../form.inc:889
12	0.0597	4830200	_form_validate( )	../form.inc:1183
13	0.0607	4840464	_form_validate( )	../form.inc:1345
14	0.0607	4840944	_form_validate( )	../form.inc:1345
15	0.0657	4874184	_form_validate( )	../form.inc:1345
16	0.0659	4877136	_form_validate( )	../form.inc:1345
17	0.0659	4877616	_form_validate( )	../form.inc:1345
18	0.0659	4878232	_form_validate( )	../form.inc:1345
19	0.0662	4889728	field_collection_field_widget_embed_validate( )	../form.inc:1459

Note that with the same structure, and making the inner and outer FC untranslatable (but the fields inside translatable), then everything works properly, and no errors occur.

Sorry for the wall of text.

alcroito’s picture

On an unrelated node, I'm not against committing the patch as-is because it does seem to solve the simple use case when the FC is untranslatable, and the fields inside are.
And then close this gigantic issue, and open new issues for the other use-cases.
Although I am afraid that once the issue is closed, we will lose traction and interest in fixing the other smaller issues.

Soul88’s picture

It seems also that in the current state of a patch - we are about to break "by nodes" translation. Cause what I can see on my install is the following:
We have a node with language = en. All its fields have language = "und" including FC field. But if this FC has one more FC among its fields - this field will have language = "en" instead of "und".

jmuzz’s picture

FileSize
7.44 KB

There are problems applying the update to nested field collections. Soul88 provided some good data to test this with in #332. I haven't figured out exactly what is going on yet but I can say it is in the area of copyTranslations, field_collection_field_update, and deleteRevision. Here is an interdiff that I -think- is closer to working, though the update still ends in an error and data is lost from the field_collection_item and some of the field collection tables when it is run.

joseph.olstad’s picture

We've been successfully using patch 187 for quite some time on field_collection revision ae778f2 from 2014-04-16. Is there anyone else successfully using a newer patch on a more recent build of field_collection? If so, please commit the latest working patch so that any remaining items can be dealt with in a new issue.

jmuzz’s picture

It looks like the update can destroy data when applied to nested field collections so I don't think it should be committed yet.

bartvig’s picture

I had problems installing patch 284 on the latest dev version, so I applied the changes to the latest dev version and that patch works for me.

bartvig’s picture

Wrong file name in previous post fixed.

joseph.olstad’s picture

Status: Needs work » Needs review

Marking to needs review, hoping that the testbot catches #363

joseph.olstad’s picture

Testbot doesn't seem to be awake, renamed patch from 363 to adhere to naming convention.

**EDIT** ok, testbot woke up and tests all-green

asamant6’s picture

The patches for filed_collection module are not working properly. If user wants to translate fields, the content of translated fields are replicated into the main content. We have working on this module to develop a patch from TCS, JNJ team to make this module supported for multilingual system.

jmuzz’s picture

Status: Needs review » Needs work

Latest version of patch is #355, which still has issues with the upgrade mentioned in #359.

I don't understand why a reroll of #284 was put up for review. Several issues with #284 have already been found and fixed. If you need to run tests you can set up the test module locally.

sylus’s picture

Placinta has said he wouldn't be against committed the patch in #355 and then tackling the smaller issues separately. I am personally having a hard time following this issue. If the only major blocker at this point is an issue with nested field collections can that not be pushed into a separate issue and tackled separately?

I fear this issue is getting very much out of hand and will not be closed otherwise as we will never reach a 100% acceptable state. In my experience it is often easier tackling a smaller subset of problems in clear defined issues.

jmuzz’s picture

The issue with nested field collections is not really a smaller issue. People with nested field collections may see their data be deleted when they run the update in this patch.

ciss’s picture

I'd like to make a bold proposal: In my opinion the size and complexity of this patch goes beyond what is managable in a patch based workflow, when there are no tools around to review and comment on patches.
Github on the other hand allows each line of a commit to be commented. I therefore propose this:

  1. Fork field_collection to Github.
  2. Create either a commit or merge request for the latest patch.
  3. Provide comments and questions in their specific code context by using the code comment feature.
  4. Post a summary of the conversation and findings in here.
  5. Rinse and repeat.

This should make it a lot easier to provide background information on certain key parts / design decisions of a patch.

Status: Needs work » Needs review

Status: Needs review » Needs work

The last submitted patch, 365: field_collection_patch_284_applied_to_dev-1344672-365.patch, failed testing.

ciss’s picture

I went ahead and created branches and pull requests for the patches in #331, #334, #335, #355 and #359. I left out everything after since @jmuzz already stated that these were obsolete.

Pull requests can be found, reviewed and commented on at github.com/cisso/field_collection. The commit each patch was based on was determined with the help of this script.

I'm hoping that his will help everyone who wants to get involved to get more familiar with the issue and the underlying code.

ciss’s picture

Reviewing #359 against 7.x-1.x (pull request):

field_collection.entity.inc

FieldCollectionItemEntity::setHostEntity, line 205

if ($create_link) {
  $entity->{$this->field_name}[$this->langcode][] = array('entity' => $this);
}

​This is the only place left where ->langcode doesn't get sanitized. ->setHostEntity() gets called in several places – can we be sure that langcode will already be clean?

FieldCollectionItemEntity::langcode(), line 350

if (empty($this->langcode) || ($this->langcode != LANGUAGE_NONE && (!module_exists('entity_translation') || !entity_translation_enabled('field_collection_item')))) {
Shouldn't be necessary, as field_collection_entity_language() already defaults to LANGUAGE_NONE. Imo the overzealous sanitization could even make other problems go by unnoticed.​

FieldCollectionItemEntity::copyTranslations(), line 460

foreach ($fields as $translatable_field) {
  foreach ($target_languages as $langcode) {
    if (isset($this->{$translatable_field}[$source_language])) {
      $this->{$translatable_field}[$langcode] =
        $this->{$translatable_field}[$source_language];
    }
  }

Shouldn't there be a call to field_info_field() with a check on $field['translatable']? Edit: Looks this patch marks all fields of a translatable FC as translatable (in field_collection_field_attach_form()).

FieldCollectionItemEntity::copyTranslations(), line 467

if ($source_language == LANGUAGE_NONE && count($this->{$translatable_field}) > 1) {
  $this->{$translatable_field}[$source_language] = NULL;
}

​Why is this necessary?

includes/translation.handler.field_collection_item.inc

EntityTranslationFieldCollectionItemHandler::getLanguage(), line 39

$langcode = $this->entity->langcode() ? $this->entity->langcode() : LANGUAGE_NONE;

If I'm not mistaken then $this->entity->langcode() will never return an empty value (already defaulting to LANGUAGE_NONE).

field_collection.module

field_collection_item_delete(), line 361

if (!empty($fci)) {​

​Unrelated bugfix? If so, it should probably be committed right away.

field_collection_field_update(), line 516

foreach ($items as $delta => &$item) {

​$delta is not used. Should it still be kept?

field_collection_field_update(), line 541

if (!empty($entity->is_new)) {
  $entity->setHostEntity($host_entity_type, $host_entity, $langcode, FALSE);
}
else {
  $entity->updateHostEntity($host_entity);
}

Is this block only required for entity_translation? Otherwise it should probably be commited right away.​

field_collection_field_update(), line 560

if ($field['translatable'] && module_exists('entity_translation') && entity_translation_enabled($entity_type)) {
"$entity_type" should be "$host_entity_type" here.

field_collection_field_delete(), line 591

if ($ids = field_collection_field_item_to_ids($items)) {

​Why is checking field_info_field($field['field_name'] no longer required?

field_collection_field_formatter_settings_form(), line 733

$elements['add'] = array(
  '#type' => 'textfield',
  '#title' => t('Add link title'),
  '#default_value' => $settings['add'],
  '#description' => t('Leave the title empty, to hide the link.'),
);

​Another change that appears to be unrelated to entity_translation.

field_collection_field_formatter_settings_form(), line 744

'#access' => field_collection_item_is_translatable(),

Looks like this line actually belongs to $elements['translate'].​

field_collection_field_widget_form(), line 1066

$field_collection_item->entity_translation_handler_id = 'field_collection_item' . '-' . (!empty($id) ? 'eid-' . $id . '-' . $revision_id : 'new-' . rand());

This should probably use uniqid() instead of rand().

field_collection_field_attach_form(), line 1151

// If FCs are translatable, make sure we mark any necessary sub-fields in the
// FC widget as translatable as well.
if ($entity_type == 'field_collection_item'
    && field_collection_item_is_translatable()
) {
  foreach (field_info_instances($entity_type, $form['#bundle']) as $field_name => $instance) {
    $field = field_info_field($field_name);
    if (isset($field['translatable'])) {
      $form[$field_name]['#multilingual'] = (boolean) $field['translatable'];
    }
  }
}

I'm not sure about this one. Wouldn't the sub fields actually have to be shared across languages?

field_collection_item_set_host_entity(), line 1598
 

$langcode = field_is_translatable($entity_type, $field) ? field_collection_entity_language($entity_type, $wrapper->value()) : LANGUAGE_NONE;

Again, defaulting should already be covered by field_collection_entity_language().

field_collection_item_is_translatable(), line 1663

return (bool) module_invoke('entity_translation', 'enabled', 'field_collection_item');
entity_translation_enabled() is not a hook implementation. This is abusing module_invoke(). function_exists() or module_exists() should be used instead.

What's left

I haven't yet reviewed field_collection.install, field_collection.pages.inc, field_collection.test and the functions field_collection_entity_translation_delete() and field_collection_entity_translation_insert().
Also, this was merely a code review. I didn't perform any functional tests.

Additional thoughts

I noticed that there are three places where field collection items get cloned. Especially with properties referencing other objects this may have unexpected results. I'd suggest to implement FieldCollectionItemEntity::__clone() to make the process more transparent (and reduce duplicate code).
 

jmuzz’s picture

"there are no tools around to review and comment on patches." ?

You have got to check this out:

https://dreditor.org/

It integrates directly with the interface of drupal.org.

ciss’s picture

OK, done for the moment (my brain needs a break). I've updated my previous comment.

It integrates directly with the interface of drupal.org.

@jmuzz: True, although I like the possibilities Github offers, like pulling in more context, direct responses and comparing different patch branches. Also, a lone interdiff like in #359 can make things even more difficult, especially with a patch of this size.

ciss’s picture

@jmuzz: Did you get a chance to review my review? Were you able to take away anything useful from it?

jmuzz’s picture

It's a nice review, but unless I'm missing something it doesn't address the problem with the update deleting data. That's the last known thing that's keeping this from being committed and any remaining changes moved forward to other issues.

MXT’s picture

I would try patch in #355 (because of #367) but it doesn't apply on latest dev of field_collection 7.x-1.0-beta8+11-dev (2015-Mar-26):

git apply -v field_collection-et_support-1344672-355.patch
Checking patch README.txt...
Checking patch field_collection.entity.inc...
Hunk #1 succeeded at 385 (offset 1 lines).
Hunk #2 succeeded at 402 (offset 1 lines).
Hunk #3 succeeded at 433 (offset 1 lines).
Checking patch field_collection.info...
Checking patch field_collection.install...
Checking patch field_collection.module...
error: while searching for:
 */
function field_collection_item_delete($id) {
  $fci = field_collection_item_load($id);
  $fci->delete();
}

/**

error: patch failed: field_collection.module:302
error: field_collection.module: patch does not apply
Checking patch field_collection.pages.inc...
Checking patch field_collection.test...
Hunk #1 succeeded at 641 (offset 63 lines).
Checking patch includes/translation.handler.field_collection_item.inc...

Do I'm testing the correct patch and FC version?

Thank you for answering me

ciss’s picture

@MXT: #355 + #359 is the latest and needs to be rerolled against HEAD. You can find branches with the patches applied and an overview of where they diverged from 7.x-1.x in this github repo: Field collection patches

saniyat’s picture

I am getting this warning message when translating

Notice: Undefined index: field in field_widget_field() (line 582 of /var/www/computer-generated-solution-new/modules/field/field.form.inc).
Notice: Undefined index: instance in field_widget_instance() (line 607 of /var/www/computer-generated-solution-new/modules/field/field.form.inc).

using patch of #335. Any idea to solve ?

hswong3i’s picture

Re-roll with latest dev based on #365

ciss’s picture

@hswong3i: Unfortunately you've rerolled the reroll of an old patch. #355 + #359 are the current patches.

This issue already has gotten quite messy, so please be sure to read at least the most recent comments after the patch you're rerolling. #365, #363 and #362 are rerolls of an old patch in #284, as stated in at least two comments after.

MXT’s picture

I've tested the following branch:

https://github.com/cisso/field_collection/tree/patch/1344672-359

I've found this issue:

field collections are lost or re-attached to the wrong language of the original host when you add a translation or edit an existing node.

Steps to reproduce:

  1. Take your content type and add a field_collection field and leave it untranslatable.
  2. Add a title_field (provided by title module) and another field (e.g. a description) to the above field_collection. Be sure to make all this "sub" fields translatable with entity_translation
  3. Make the above content type and field_collection translatable at Admin -> Config -> Regional -> Entity Translation
  4. Always at Admin -> Config -> Regional -> Entity Translation set both for node and field_collection the following settings:
    • default language -> current language;
    • "Exclude Language neutral from the available languages" checked
    • "Hide shared elements on translation forms" checked
  5. Now add a node and fill some field_collection fields. Save it.
  6. Viewing the node you can see correctly the node content with field_collections fields
  7. Now TRANSLATE the node and save
  8. Notice the bug: all existings field_collections are re-attached to the new translation of the node (wrong). Indeed if you switch language to view the node in the original language source, field collection fields are now missing.
  9. But if you re-save the original source language of the node, field collections are now re-associated here.
  10. So NOW you can translate each field_collection (click on translate at the bottom of each field collection).
  11. Translated field collections are correctly associated to the node translation host.
  12. But NOW if you re-save the node translation the bug re-appear: field collections are missing

Thank you very much for resolving this

hswong3i’s picture

Status: Needs work » Needs review
FileSize
67.8 KB

Re-roll with latest dev based on #355 + #359

jmuzz’s picture

Status: Needs review » Needs work

Thanks for the reroll!

The issues with data deletion still haven't been addressed so I'm setting the status back.

adriaav’s picture

Same issue as #384, have patched #385 and still not working. Any help would be appreciated! Thank you!

adriaav’s picture

Seems like I could go on enabling translation for fieldset collection and disabling translation for its sub-fields. I have no need for translating subfield labels, just it's content, so this works for me.

I've just came across another issue,.. Have a multivalue fieldset collection that has a one value text subfield and a one value image subfield. While creating content everything goes as expected but when translating it I get an AJAX error, this happens when the multivalue fieldset collection has more than 1 image field value. Structure looks like described next:

ingredients (unlimited values field collection fieldset)
- ingredients text (first value, one value limit)
- ingredients image (first value, one value limit)
- ingredients text (second value, one value limit)
- ingredients image (second value, one value limit)

Second value for ingredients image doesn't show and if trying to remove/save AJAX error appears.

Have looked for this issue but didn't find anything, if it's duplicated/... please tell me.

Thank you!

LiamPower’s picture

#385 worked for me with keeping the content in the node, but it seems to always be being saved as 'en' even when the node is German/French/Italian

JOINSO’s picture

Hi, LiamPower!

I can confirm your test.
In my case, fields of the field collection are always stored as "en", without taking care of the node language.

In details, my field collection is untranslatable, but all the files inside are translatable.

When i view the node it show correct, if I see under "en", but not in another languages.

I think that the problem is inside field_collection_field_update and the choice of the correct language, but I don't make a deep code study...

krisgraham’s picture

Fixed a small typo in hswong3i's patch #385 (line 563 of field_collection.module was referring to a non-existent variable, $entity_type instead of $host_entity_type).
I haven't yet done extensive testing, but this seems to be working for me so far.
Using:
Drupal 7.36
Entity API 7.x-1.6
Entity Translation 7.x-1.0-beta4

New patch attached.

JOINSO’s picture

Hi!

I tested the last patch (#391) and it doesn't work.

Translations of Fields in field collection still saved in "en".

JOINSO’s picture

Hi!

I do some testing with patch #391.

The initial conditions are:

Node with a field collection untranslatable.
The fields in the field collection are translatable.

A node is created in English.

The fields in the collection are stored in English.

When we make the translation in another language (Spanish), fields are stored in English.

Doing some debug, I find this:

field_collection_field_insert and field_collection_field_update are called.
The first function, get "es" in field_collection_entity_language call, but in the second one, field_collection_field_update, get this values:

langcode(param): und
field_collection_entity_language: en

And then langcode becomes "und", and setHostEntity is called wiht langcode "und".

Perhaps this info can helps someone to find the issue.

JOINSO’s picture

Hi!

Until we have a solution for fields stored in English (language source of original node) rather thant the translation language, here is a quick solution:

1) If you edit the node, there is no problem and you will see the values but we now that is going to be stored in language source of original node.
2) In node view, field collections items are going to be hidden where you are viewing in the translation language.
Then someone can do this to see the data:

Create a module, and implement this function (can be improved, I know....):

function YOUR_MODULE_field_collection_item_view($field_collection_item, $view_mode, $langcode)
{
if ($field_collection_item->field_name == "YOUR_FIELD_COLLECTION_NAME")
{
if($langcode!='en') // EN IS YOUR SOURCE LANGUAGE. THIS CAN BE IMPROVED CHECKING LANGUAGE INSIDE FIELDS ....
{
$field_collection_item->content['ANY_FIELD_INSIDE_COLLECTION] = array('#markup' => $field_collection_item->ANY_FIELD_INSIDE_COLLECTION['en'][0]['filename']); // IN THIS CASE WE ARE RENDERING A FILE
}
}

joseph.olstad’s picture

@JOINSO , it sounds like your configuration may be the problem in your case. Are you using the entity_translation module? Is it enabled? What are your content type translation settings? Are you doing node translation or field translation? Far as I know this patch is for field translation for nodes using the entity_translation settings rather than node translation. Please confirm.

JOINSO’s picture

Hi, joseph.olstad!

This is my config:

A content type with translation enabled.
One the fields is a field collection with Field translation disabled, but with every field inside are translatable.

And Entity Translation is enabled.

However, I think that the fields inside field collections must be saved under the language of their instance, no?

Regards,
JOINSO

seanr’s picture

@JOINSO - do you have at least one other field on the node type with translation enabled? Node should be enabled with field translation, there should be one translatable field on the node (but not the FC field) and then fields with translation enabled within the FC.

JOINSO’s picture

Title and body.
FC with translation disabled, but fields inside have translation enabled.

jkuma’s picture

Hello there,

The last patch 391 is working like a charm for my project. Thank you guys for your hard work.

jkuma’s picture

Hello,

I've just updated the patch to avoid Drupal installation to break. Indeed, the module_load_include at the top of the install file breaks the module dependencies check during a new website installation. That include is only needed by the last hook update (field_collection_update_7007), that's why I've moved it inside that function.

jkuma’s picture

The previous patch introduces a bug when using drush make command. This new patch fixes this up.

MXT’s picture

@goldorak: what's about your field collection configuration?

Is like described here:

The common use case is to leave the field collection field untranslatable
and set the necessary fields inside it to translatable. There is currently
a known issue where a host can not be translated unless it has at least
one other field that is translatable, even if some fields inside one of
its field collections are translatable.

(Like mine described here: https://www.drupal.org/node/1344672?page=1#comment-9815261)

Or like the following:

The alternate use case is to make the field collection field in the host
translatable. If this is done it does not matter whether the inner fields
are set to translatable or not, they will all be translatable as every
language for the host will have a completely separate copy of the field
collection item(s).

This is an essential piece of information to see if this patch is working at all.

JulianVJ’s picture

Hi JOINSO,
I have the same problem.
I've noticed that this only ocurr when I have 'Enable language fallback' unchecked, if it's checked it works OK.

I don't know if is related with this but reviewing database information I have seen that when I make a translation a new line to 'entity_translation' table is not added, it overwrites the initial line so entity translation don't find source language correctly.

@MXT, making the field collection field in the host translatable is not an option, at least in my case, because a memory limit error appears when I try to translate.

wroxbox’s picture

+      // Add the subform
       field_form_set_state($field_parents, $field_name, $language, $form_state, $field_state);
-      field_attach_form('field_collection_item', $field_collection_item, $element, $form_state, $language);
+      $entity_langcode = entity_language('field_collection_item', $field_collection_item);
+      field_attach_form('field_collection_item', $field_collection_item, $element, $form_state, $entity_langcode);

In my findings $entity_langcode is emtpty/null and the subform fields get wrong langcode.

Node is entity translatable
Node has translatable field (field_short_description)
FC is translatable (field_deployment)
FC items are translatable
inside FC I reuse field_short_description as translatable field too.

I have master language FI and translating entity as SV.
By

field_attach_form('field_collection_item', $field_collection_item, $element, $form_state, $entity_langcode);

gives forms
form-type-textarea form-item-field-deployment-sv-0-field-short-description-fi-0-value

Changing to

field_attach_form('field_collection_item', $field_collection_item, $element, $form_state, $language);

gives form as

form-type-textarea form-item-field-deployment-sv-0-field-short-description-sv-0-value

And now all data is saved property to database and editing works fine.

joseph.olstad’s picture

Status: Needs work » Needs review
FileSize
67.51 KB
1.07 KB

This patch might fail as I re-enabled a portion of a test said to have known to fail. However it might also succeed as I made the change suggested in comment #405 by wroxbox.

In addition I removed the preceeding call to entity_language as it is no longer used in that said function.

See interdiff

If this fails I'll restore the original field_collection.test asap, otherwise if it works, then great.

jmuzz’s picture

Status: Needs review » Needs work

Thanks for the update!

The issues with data deletion still haven't been addressed so I'm setting the status back.

joseph.olstad’s picture

Hi Jmuzz, actually according to the field_collection.test it does address the data deletion.

See this line in field_collection.test from the patch in 406
$this->assert(empty($fc_items), t('The field collection item has been removed from the database.'));

I activated this assertion and it passed according to SimpleTest.

What other data deletion might you be referring to? If the test is missing, can you please add it?

Lendude’s picture

Basically #405 rolled into the patch. For me it was that when adding a new translation the default values were null instead of the values in the original host entity.

I opted to take the language of the host entity, which sounds logical to me, but not really into this issue enough to be sure that it is. But it did solve the issue for me.

Sorry, no time to write a test for this at the moment.

Lendude’s picture

And now with the new file added to the patch....

Looks like joseph.olstad tried to do this too in #406, but the changes in that interdiff don't appear to be in the patch?

colan’s picture

Status: Needs work » Needs review

Still works well for adding new content/translations, but we need reviews on everything else.

jmuzz’s picture

Status: Needs review » Needs work

The patch can destroy data during the update in field_collection.install .

See #359 and #361 for an explanation and a reference to some test data that can be used to reproduce.

kedramon’s picture

Hi all,

Found an issue,
basic setup:
drupal (7.37)
entity_translation (7.x-1.0-beta4)
field_collection (7.x-1.0-beta8)

Add field collection to node, with unlimited values, and enable translation for field collection. Filed collection fields: some name (text), term auto-complete (term_reference), not translated.
Create node with any content, add minimum two field collection item. After save, create translation, try to add or edit field collection, as result

An AJAX HTTP request terminated abnormally.
Debugging information follows.
Path: /system/ajax
StatusText: n/a
ResponseText: 
Error  
Error message
Notice: Undefined index: field in field_widget_field() (line 578 of /var/www/clean/example/modules/field/field.form.inc).
Warning: Invalid argument supplied for foreach() in taxonomy_autocomplete_validate() (line 1761 of /var/www/clean/example/modules/taxonomy/taxonomy.module).
PDOException: SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '))' at line 2: SELECT base.tid AS tid, base.vid AS vid, base.name AS name, base.description AS description, base.format AS format, base.weight AS weight, v.machine_name AS vocabulary_machine_name
FROM 
{taxonomy_term_data} base
INNER JOIN {taxonomy_vocabulary} v ON base.vid = v.vid
WHERE  (base.name LIKE :db_condition_placeholder_0 ESCAPE '\\') AND (base.vid IN  ()) ; Array
(
[:db_condition_placeholder_0] =&gt; test es
)
in DrupalDefaultEntityController-&gt;load() (line 198 of /var/www/clean/example/includes/entity.inc).
The website encountered an unexpected error. Please try again later. 

this happens in second item of field collection.
Anyone have this issue?

Regards,
Vova

hwasem’s picture

I was able to get patch 410 to Mostly work for me. There were error messages about translation.handler_factory.inc after clearing running update.php, but clearing the cache seemed to fix that.

Entity Translation - 7.x-1.0-beta4
Field Collection - 7.x-1.0-beta8+11-dev (2015-Mar-26) + patch in #410

My config:
Content type that is translatable with a mix of fields that are translatable and non-translatable
Field Collection that is untranslated
-- title sub field - translatable
-- node reference - untranslated
Entity Translation config - admin/config/regional/entity_translation
- under Translatable Entity Types - enabled Field Collection items

I was able to translate a node (english is default) into two languages. The title subfield is correctly saved in each language and is not overwriting other language values. This is huge.

The only thing not working is when I EDIT a node, the field content for the source language is not consistently being displayed when I edit a Spanish node, for example. This is not always missing and I'm not sure when it does and when it doesn't work. The display view of the same Spanish node IS showing the English content, it is just not always carrying that English text through to the edit screen.

maxplus’s picture

Hi,

Thanks for the effort.

I'm also running:
Entity Translation - 7.x-1.0-beta4
Field Collection - 7.x-1.0-beta8+11-dev (2015-Mar-26) + patch in #410

When I try to translate a node containing a translatable field collection, I get a memory error:

Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 130968 bytes) in .../httpdocs/includes/common.inc on line 7809

omarlopesino’s picture

Patch #410 worked for me in most case except when i tried to delete items from a multiple field collection.

I used this versions of field collection and entity translation:
Entity Translation - 7.x-1.0-beta4
Field Collection - 7.x-1.0-beta8+11-dev

I used it with a content type which has a field collection non translatable with translatable fields.

I can create values when the field collection item was multiple, but i can't delete the items.
Reading the message I saw that is a nesting problem.
Attach message:

1	0.0000	266776	{main}( )	../index.php:0
2	0.0728	3147576	menu_execute_active_handler( )	../index.php:21
3	0.0729	3148608	call_user_func_array ( )	../menu.inc:519
4	0.0729	3149320	entity_translation_edit_page( )	../menu.inc:519
5	0.0730	3151352	_entity_translation_callback( )	../entity_translation.module:546
6	0.0730	3151496	call_user_func_array ( )	../entity_translation.module:701
7	0.0730	3151832	node_page_edit( )	../entity_translation.module:701
8	0.0731	3152488	drupal_get_form( )	../node.pages.inc:14
9	0.0731	3153488	drupal_build_form( )	../form.inc:130
10	0.0759	3618344	drupal_process_form( )	../form.inc:385
11	0.1194	4465792	form_execute_handlers( )	../form.inc:903
12	0.1194	4471912	node_form_submit( )	../form.inc:1513
13	0.1288	4477640	node_save( )	../node.pages.inc:460
14	0.1485	4554760	field_attach_update( )	../node.module:1178
15	0.1485	4554920	_field_invoke( )	../field.attach.inc:991
16	0.1488	4557328	field_collection_field_update( )	../field.attach.inc:209
17	0.3842	4852416	FieldCollectionItemEntity->updateHostEntity( )	../field_collection.module:582
18	0.3959	4880312	FieldCollectionItemEntity->langcode( )	../field_collection.entity.inc:234
19	0.3986	4880984	field_collection_entity_language( )	../field_collection.entity.inc:360
20	0.3988	4880936	EntityTranslationFieldCollectionItemHandler->getLanguage( )	../field_collection.module:134
21	0.3988	4881168	FieldCollectionItemEntity->langcode( )	../translation.handler.field_collection_item.inc:39
22	0.4008	4881840	field_collection_entity_language( )	../field_collection.entity.inc:360
23	0.4009	4881840	EntityTranslationFieldCollectionItemHandler->getLanguage( )	../field_collection.module:134
24	0.4009	4881840	FieldCollectionItemEntity->langcode( )	../translation.handler.field_collection_item.inc:39
25	0.4029	4882536	field_collection_entity_language( )	../field_collection.entity.inc:360
26	0.4031	4882536	EntityTranslationFieldCollectionItemHandler->getLanguage( )	../field_collection.module:134
27	0.4031	4882536	FieldCollectionItemEntity->langcode( )	../translation.handler.field_collection_item.inc:39
28	0.4050	4883232	field_collection_entity_language( )	../field_collection.entity.inc:360
omarlopesino’s picture

I debugging and i think i found a solution for being able to delete items in a multiple field collection.

I attach the patch.

omarlopesino’s picture

Status: Needs work » Needs review
omarlopesino’s picture

jmuzz’s picture

Status: Needs review » Needs work

The patch can destroy data during the update in field_collection.install .

See #359 and #361 for an explanation and a reference to some test data that can be used to reproduce.

omarlopesino’s picture

I've seen the issue related with nested field collection and i did a fix in field_collection_field_update.
When the items of a field collection are updated they are removed when they are unused, but don't check if currently the same item is being used in other languages.

I attach the patch.
I attach too the database i've used with a content type which contains a field collection nested (field_collection_tests) multilanguage.

@NOTE: i do the interdiff over #410 because i commit a mistake in my latest patch.

omarlopesino’s picture

Status: Needs work » Needs review
omarlopesino’s picture

Johnny vd Laar’s picture

I'm testing the patch from #423 and also #410 with this setup:

Node with translatable FC (unlimited) and untranslatable fields. So each translation gets a new FC id. When I create a new node all works well and the FC gets the right language. When I create the translation then I get an infinite loop because the field collection cannot seem to find it's language:

1	0.0000	249632	{main}( )	../index.php:0
2	0.0168	1983016	menu_execute_active_handler( )	../index.php:21
3	0.0168	1983952	call_user_func_array:{/home/johnny/workspace/quadrupal7/includes/menu.inc:519} ( )	../menu.inc:519
4	0.0168	1984888	entity_translation_add_page( )	../menu.inc:519
5	0.0169	1986976	_entity_translation_callback( )	../entity_translation.module:690
6	0.0169	1987120	call_user_func_array:{/home/johnny/workspace/tdh/modules/contrib/entity_translation/entity_translation.module:701} ( )	../entity_translation.module:701
7	0.0169	1987544	node_page_edit( )	../entity_translation.module:701
8	0.0170	1988144	drupal_get_form( )	../node.pages.inc:14
9	0.0170	1989200	drupal_build_form( )	../form.inc:130
10	0.0185	2316056	drupal_process_form( )	../form.inc:385
11	0.0337	3243952	drupal_validate_form( )	../form.inc:889
12	0.0337	3244640	_form_validate( )	../form.inc:1183
13	0.0345	3253112	_form_validate( )	../form.inc:1345
14	0.0346	3253592	_form_validate( )	../form.inc:1345
15	0.0346	3254208	_form_validate( )	../form.inc:1345
16	0.0348	3265512	field_collection_field_widget_embed_validate( )	../form.inc:1459
17	0.0350	3269768	EntityTranslationDefaultHandler->entityFormLanguageWidgetSubmit( )	../field_collection.module:1428
18	0.0350	3269880	EntityTranslationDefaultHandler->getFormLanguage( )	../translation.handler.inc:1480
19	0.0350	3270112	EntityTranslationFieldCollectionItemHandler->getLanguage( )	../translation.handler.inc:1127
20	0.0350	3270280	FieldCollectionItemEntity->langcode( )	../translation.handler.field_collection_item.inc:39
21	0.0350	3271304	field_collection_entity_language( )	../field_collection.entity.inc:368
22	0.0351	3271304	EntityTranslationFieldCollectionItemHandler->getLanguage( )	../field_collection.module:134
23	0.0351	3271304	FieldCollectionItemEntity->langcode( )	../translation.handler.field_collection_item.inc:39
24	0.0351	3271352	field_collection_entity_language( )	../field_collection.entity.inc:368

When I set the field collection as single instead of unlimited, all works fine.

Johnny vd Laar’s picture

Also seems that setting it to 5 values works as well. So the problem is only for unlimited. Switching off "Hide blank items" doesn't influence this.

Johnny vd Laar’s picture

I had a problem in the upgrade path of my nodes. I have a node with a field collection. The fc is not translatable it has 2 fields 1 translatable and 1 not translatable. The data of the untranslatable field was gone after update hook 7007. This is caused because the copyTranslations function does not check if the field is translatable. Attached patch fixes this. Patch is based on #421.

Status: Needs review » Needs work

The last submitted patch, 426: field_collection_field-1344672-426.patch, failed testing.

Johnny vd Laar’s picture

Status: Needs work » Needs review
FileSize
68.94 KB

Hmm... perhaps this works.

irowboat’s picture

Initial testing says #428 is solid on a site with entity translation.

Patches clean dev version fine, but database update does not work.

This line is the only one regarding translation.handler.field_collection_item.inc:

+files[] = includes/translation.handler.field_collection_item.inc

edit:
Manually adding the file and getting content for it from #426 makes database update work.

Error on database update: "Unable to save a field collection item without a valid reference to a host entity."

Johnny vd Laar’s picture

Indeed that file is not in the patch. I'll add it again.

subhojit777’s picture

#430 is working for me. I have not tested thoroughly (using views, etc.), but I can enable translation for field collection field and create translation for nodes.

omarlopesino’s picture

Testing the usages of the field collection translatable, I've seen something that I don't understand.

Having one field collection untranslatable and field collection entity translation activated, when I save the host entity (translatable node),in the entity_translation table which stores translatable entities saved, the field collection is saved in that table only with the current language when normally is saved in the languages which the entity is saved.

@NOTE: the content type which belongs the field collection have set current language as default language, I don't know if it can influence.

drclaw’s picture

The patch in comment #430 applies cleanly and appears to work. I was having some trouble initially with the db update as well (mentioned in comment #429 by @irowboat), getting the "Unable to save a field collection item without a valid reference to a host entity." error. It was only happening on one of my field collection types. For some reason the host entity wasn't being attached properly to the field collection item. I thought maybe it had something to do with the fields on the field collection type being translatable before applying the patch, so I disabled translation on them and ran the update again and it worked. However, I had other field collection types that also had translatable fields before the update so I can't really tell you why this fixed it... I wish I could offer some more insight but that's all I have for now.

robin.ingelbrecht’s picture

When I try to translate a node containing a translatable field collection, I get a memory error.

Fatal error: Allowed memory size of 1073741824 bytes exhausted (tried to allocate 130968 bytes) in /var/www/website/includes/common.inc on line 7835

My content type consists of field collections in field collections.
I already upped the memory to 1024 MB, still the same error.

subhojit777’s picture

I am updating database and am getting this error:
PHP Fatal error: Call to undefined method FieldCollectionItemEntity::copyTranslations() in /Applications/MAMP/htdocs/mysite/sites/all/modules/contrib/field_collection/field_collection.install on line 355

nicrodgers’s picture

The patch in #430 applied cleanly for me, and I no longer get errors when trying to translate nodes with field collection fields with multiple values. DB update worked fine, too.

Thanks!

das-peter’s picture

Just found a possible recursion in EntityTranslationFieldCollectionItemHandler::getLanguage(). Currently the method calls $this->entity->langcode(), which subsequently calls EntityTranslationFieldCollectionItemHandler::getLanguage(), and this calls $this->entity->langcode(), which subsequently calls EntityTranslationFieldCollectionItemHandler::getLanguage() ...
You get the idea ;)

@robin.ingelbrecht Please try the updated patch.

Anonymous’s picture

The patch from #430 doesn't apply properly for me. It creates a new directory called 'includes' outside the drupal root directory. The new 'includes' directory contains one file: translation.handler.field_collection_item.inc

I used PHPStorm to apply the patch. When I try to apply the patch with git, it appears to work but doesn't change anything.

daniel.nitsche’s picture

@douglasgough are you patching against dev? Seems ok to me. I ran this:

drush dl field_collection --dev
wget -P field_collection https://www.drupal.org/files/issues/field_collection_field-1344672-430.patch
cd field_collection; patch -p1 < field_collection_field-1344672-430.patch

If it's still not working for you, I'd suggest pasting in the exact commands you ran.

Anonymous’s picture

Thanks daniel.nitsche. It appears that PHPStorm doesn't apply this patch properly. I followed your instructions and the patch applied properly.

kallehauge’s picture

Our override of the getLanguage() method in translation.handler.field_collection_item.inc can create a loop where it will keep calling itself. That made me actually look at the method. Why do we even need it? We get the correct language code from the original getLanguage() method and are only creating extra overhead/complexity for ourself by maintaining it ourselves. – It's introduced in #45 if you want to look at the source of the override.

Edit: I figured why we need it. When translating directly (/admin/field-collection/field-right-column/xxx/edit/...), we only get the original language of the entity it belongs to, but the method still fetched it "wrong" and it could cause a loop. So our main problem atm is language detection. – Should we fetch it from the URL? Might seem like our only solution, and then default to ::parent ?

entendu’s picture

Nested field collections are not translating properly when the highest-level FC is 'unlimited' cardinality and more than one instance exists.

On a fresh D7 install, I set up FCs like this on the Article type:

  • Top level FC - unlimited cardinality, contains 1 field which is:
    • Bottom level FC - Limited (1) cardinality, contains two text fields:
      • Text 1 (unlimited)
      • Text 2 (unlimited)

When translating a node that has only ONE "Top level" FC instance, it works. But, if I "add another", it chokes with these messages when saving a new translation:

Notice: Undefined index: entity in field_collection_field_widget_embed_validate() (line 1415 of sites/all/modules/field_collection/field_collection.module).


Notice: Undefined index: field in field_widget_field() (line 578 of modules/field/field.form.inc).

Notice: Undefined index: instance in field_widget_instance() (line 603 of modules/field/field.form.inc).

[22-Jul-2015 17:15:01] PHP Fatal error:  __clone method called on non-object in sites/all/modules/field_collection/field_collection.module on line 1415

I configured entity_translation to translate fields, etc etc. Enabled modules in this list. Using field_collection patch in #437. I am including a DB dump (drupal login is admin/admin) and the sites/all/modules directory from my test environment, see attachments.

entendu’s picture

FWIW, it seems my issue might be the same as https://www.drupal.org/node/1344672?page=1#comment-9560475

entendu’s picture

Issue summary: View changes

Updating summary.

tim.plunkett’s picture

+++ b/README.txt
@@ -13,11 +13,11 @@ field collection item may also be viewed and edited separately.
-   the usual "Manage fields" interface provided by the "field ui" module of
-   Drupal, e.g. "Admin -> Structure-> Content types -> Article -> Manage fields".
+    the usual "Manage fields" interface provided by the "field ui" module.
+    e.g. "Admin -> Structure-> Content types -> Article -> Manage fields".
...
-   the created field collection.
+    the created field collection.

+++ b/field_collection.entity.inc
@@ -385,7 +391,12 @@ class FieldCollectionItemEntity extends Entity {
-      throw new Exception("Unable to create a field collection item without a given host entity.");
+      throw new Exception('Unable to create a field collection item without a given host entity.');

There are a lot of unrelated changes here. Can they be removed please?

I don't know multilingual stuff well enough to really review the rest. :(

idebr’s picture

+++ b/field_collection.entity.inc
@@ -428,16 +440,48 @@ class FieldCollectionItemEntity extends Entity {
+    $host_et_handler = entity_translation_get_handler($this->hostEntityType(), $this->hostEntity());

On a Drupal installation without entity_translation installed this results in a fatal error 'Call to undefined function entity_translation_get_handler()' when updating.

colan’s picture

I took #437 and fixed #445 and #446.

Are #420 and #441 still issues?

joseph.olstad’s picture

Status: Needs review » Reviewed & tested by the community

After a careful review I confirm that Colans fixes for #445 and #446 are good.

Can we commit this please and open new issues for #420 and #441 (if necessary).

RTBC+

Soul88’s picture

Guys, has anyone tested this patch for "by nodes" translation? Some previous patches were breaking it and I do not have time to properly test it right now.

If it is still the case, I don't think it should be commited as this type of translation is already used by many sites in prod, and so we can't let them break with the update.

joseph.olstad’s picture

Hi Soul88, in response to your comment#449, I suggest we commit this to a 7.x-2.x branch instead of the 1.x branch.

Then if someone likes they could backport this to 1.x later or just push forward on 2.x

Soul88’s picture

Well, I'm not a field_collection module maintainer, but I still don't like the idea of trading support of one translation type for another. If that's the case.

joseph.olstad’s picture

Soul88 , this will work with node translation, no need to copyTranslations in that case (because each node will has it's own field collection with its own entity_id when using node translation).

For field translation using entity translation (ET) is really what colan fixed.

In the case that entity translation is NOT enabled, copyTranslations returns null because $host_et_handler will be null or else entity_translation is not enabled and it will return null which makes perfect sense when using node translation because each field collection will use language undefined when using node translation.

When field translation is enabled and the $host_et_handler is set (ET is configured) the fields will be copied using the copyTranslations function

@colan , *EDIT* thanks to "Scott Robertson" for clarifiying this I noticed issue with the latest code, a drupal code standards issue, copyTranslations is using caMel case, drupal coding standards tells us to change the copyTranslations to copy_fc_translations would probably be better as this is a public function and we don't want to step on other function names just in case copy_translations is already used by another contrib or core module copy_fc_translations would be a more specific name (less chance of name space issue). We might want to run a quick code sniffer and "coder review" on the patch before committing just to clean up some minor issues.

Scott Robertson’s picture

@joseph.olstad, are you referring to the method name (copyTranslations) itself? If so, class methods are supposed to be named using lowerCamel:

https://www.drupal.org/node/608152#naming

nadine_cz’s picture

I've tested with #447, and ran into a small problem (I was using #187 (with wetkit) prior and it had the problem as well).

My use case: Create a node and field collection (with translations) programmatically.
Issue: The copyTranslations overrides the translations I've passed in.
Fix (?): By checking that the translation is set and not overriding...my use case now works.

(line 492 ish - field_collection.entity.inc)

 if(!isset($this->{$translatable_field}[$langcode])) {   //if set, don't override with source lang 
   $this->{$translatable_field}[$langcode] =  $this->{$translatable_field}[$source_language];
 }
colan’s picture

Status: Reviewed & tested by the community » Needs work

Let's get that additional check added, and then we should be good to go.

joseph.olstad’s picture

@nadinecz, I was going to take your word as gold and do as you say but your code snippet comment doesn't make sense to me.

you've written:

if(!isset($this->{$translatable_field}[$langcode])) {   //if set, don't override with source lang

but the code in the snippet says: if(!isset(BLAH)) {

your comment says //if set
so what do you think the code should be? if set or if is not set?

patch 487 gives this on line 492:

  public function copyTranslations($source_language = NULL) {
   
  //SNIP .....

    foreach ($fields_instances as $translatable_field) {
      if ($fields[$translatable_field]['translatable'] == 1) {
        foreach ($target_languages as $langcode) {
          if (isset($this->{$translatable_field}[$source_language])) {
            $this->{$translatable_field}[$langcode] =
            $this->{$translatable_field}[$source_language];
          }
        }
        if ($source_language == LANGUAGE_NONE && count($this->{$translatable_field}) > 1) {
          $this->{$translatable_field}[$source_language] = NULL;
        } //line 492
      }
    }
  }

so what are you proposing at line 492? it looks like you're proposing to do the same thing as "if isset()" on the else ?

nadine_cz’s picture

hey @joseph.olstad

The struggle with being coherant…it’s real.

My comment is misleading (apologies). I’m trying to say: if I’ve already set the translation for the FC field, please don’t override it with the source language. If you do, I’m stuck…..

Maybe a bit more background would help (?)

I have a case where I’m creating a node with a field collection programatically…. The node is language_none, but I have a field in the FC that’s multilingual. So, a “section” (node) with “questions” (fc) – the question field is displayed in EN or FR )

Please note, if this is too specific a use case, I can patch it locally and move on – no worries. Alternatively, I can open another ticket independent of this one so that the #447 patch can move forward as there are changes in there that shouldn’t be held back by this use case.

If it does get included, feel free to drupalize that comment….

  public function copyTranslations($source_language = NULL) {

  SNIP
	
    foreach ($fields_instances as $translatable_field) {
      if ($fields[$translatable_field]['translatable'] == 1) {
        foreach ($target_languages as $langcode) {
          if (isset($this->{$translatable_field}[$source_language])) {

            if(!isset($this->{$translatable_field}[$langcode])) {   //if the target is not set then copy the translation 
              $this->{$translatable_field}[$langcode] =  $this->{$translatable_field}[$source_language];
            }
          }
        }
        if ($source_language == LANGUAGE_NONE && count($this->{$translatable_field}) > 1) {
          $this->{$translatable_field}[$source_language] = NULL;
        }
      }
    }
joseph.olstad’s picture

Status: Needs work » Needs review
FileSize
1.01 KB
69.75 KB

@nadinecz, here is the updated patch with your code with the interdiff, I added some descriptive comments.

The interdiff will show you the differences.

@nadinedz, @colan, can you please review?

nadine_cz’s picture

Looks good @joseph.olstad - thanks!

colan’s picture

Someone needs to test nested field collections, as per #359 to see if there's still data loss, and I'm afraid I don't have an environment set up for that right now. This shouldn't be turned green RTBCed until we can confirm that this is no longer a problem.

idflood’s picture

Maybe this is not related to the patch in #459 but I've some issues when translating the field collection. To reproduce:

- Create an unlimited field collection with multiple fields.
- The fields inside the collection are not translatable but the field collection is. This way i could have 2 items in english and 3 different one in german for instance.
- Create a node and make 3 items of the collection.
- Translate the node, remove the second item of the field collection.

The problem is that it also remove the third item of the collection, and i have the following notices:

Notice: Undefined index: field in field_widget_field() (line 578 of /drupal/modules/field/field.form.inc).
Notice: Undefined index: instance in field_widget_instance() (line 603 of /drupal/modules/field/field.form.inc).
Warning: preg_replace(): Compilation failed: range out of order in character class at offset 14 in number_field_widget_validate() (line 389 of/drupal/modules/field/modules/number/number.module).
Only numbers and the decimal separator () allowed in .

edit: Reproduced the error on a clean install and copied the new notices and warning. The error about numbers is because I'v added a float subfield with a min/max. The value I entered is valid but when creating a new translation if I remove the field collection items and add new one the validation seems to be buggy.

joseph.olstad’s picture

@idflood, I've re-read your use case a few times, I'll have to try to reproduce your steps myself, maybe we can write a simple test for it.

Is it safe to assume that you've applied the patch 459 to the latest dev from march 2015?

joseph.olstad’s picture

Hello @idflood, I installed a recent dev version of a distribution of Drupal that I use often and upgraded field_collection to the latest dev and applied patch 459, then I repeated your steps verbatim with the unlimited field collections, I could not reproduce the errors that you mentioned.

Seeing as the errors you observed came from drupal core I suggest that you upgrade your entity_translation module and make sure to upgrade your drupal core to the latest version and then install field_collection the latest dev and apply patch 459. There may be some other contrib module that you may want to upgrade, I suggest also upgrading your ctools module to the latest stable version. Once you do this your error should go away.

from my perspective this is
RTBC +1

idflood’s picture

@joseph.olstad thanks for the quick response. Maybe it's a small configuration difference since I a did a clean install with the following:

- Drupal 7.39
- ctools 7.x-1.9
- i18n 7.x-1.13 (Content translation, Field translation, Internationalization, Multilingual content, String translation enabled)
- Field collection, cloned 7.x-1.x from git today and applied patch in #459
- Entity API 7.x-1.x (dev version)
- Entity Translation 7.x-1.x (dev version)

- Added a second language and in the "Detection and selection" tab enabled the UI method for both UI and Content language detection.
- In Basic page content type add a new field collection with "Embedded" widget, unlimited values and the field translation checkbox checked.
- when editing the content type I "Enabled, with field translation" in Publishing options >Multilingual support.
- in the field collection added one simple text field and a float field with min 0, max 100 and made it required. For both fields the "Users may translate all occurrences of this field" is not checked.

- created a page in english with 3 items in the field collection, saved.
- clicked the translate tab, and added a translation.
- clicked the remove button from the 2nd item. No errors but the third item is removed too.
- clicked "Add another item" and entered valid values.
- clicked save, the errors shows up and the translation is not saved.

edit: I tested again this morning but still have the same issue. This time I cloned the latest version of entity and entity_translation from git but the error is still the same.

I also tried to enable the field translation on the collection AND the subfields. The result is a little different, the subfield content isn't copied when translating but I still have the same errors.

Also the issue happens only if the FC has unlimited values. With a fixed number of items it seems to be working fine.

joseph.olstad’s picture

Hi @idflood, ok, I confirm, I can reproduce the issue.

using a float as you did got the same error as you, then I removed the float from the collection and changed it to an integer.

replacing float with integer field I get some Undefined index warnings from core, but the functionality works everything works as expected.

Heres the warnings:
Notice : Undefined index: field in field_widget_field() (line 578 in modules/field/field.form.inc).
Notice : Undefined index: instance in field_widget_instance() (line 603 in modules/field/field.form.inc).
Notice : Undefined index: field in field_widget_field() (line 578 dans modules/field/field.form.inc).
Notice : Undefined index: instance in field_widget_instance() (line 603 in modules/field/field.form.inc).

Here's what the database says at this time:

select entity_type, bundle, entity_id, language, field_fc_value, field_fc_revision_id from field_data_field_fc;

|entity_type| bundle |entity_id |language|field_fc_value|field_fc_revision_id|
|node | basic_page| 6 | en | 18| 93|
|node | basic_page| 6 | fr | 21| 96|
|node | basic_page| 6 | en | 19| 94|
|node | basic_page| 6 | fr | 22| 97|
|node | basic_page| 6 | en | 20| 95|
|node | basic_page| 6 | fr | 23| 98|

select entity_type, entity_id, revision_id, bundle, language, field_text_value from field_data_field_text;

|entity_type |entity_id|revision_id| bundle |language|field_text_value
|field_collection_item| 18| 93| field_fc| und |test en 3 first field collection
|field_collection_item| 19| 94| field_fc| und |test en 3 second field collection
|field_collection_item| 20| 95| field_fc| und |test en 3 third field collection
|field_collection_item| 21| 96| field_fc| und |test fr 3 premier field collection
|field_collection_item| 22| 97| field_fc| und |test fr 3 deuxième field collection
|field_collection_item| 23| 98| field_fc| und |test fr 3 troisième field collection

select entity_type, entity_id, revision_id, bundle, language, field_integer_value from field_data_field_integer;

|entity_type |entity_id |revision_id |bundle |language |field_integer_value |
|field_collection_item | 18 | 93 |field_fc |und | 3 |
|field_collection_item | 19 | 94 |field_fc |und | 4 |
|field_collection_item | 20 | 95 |field_fc |und | 5 |
|field_collection_item | 21 | 96 |field_fc |und | 3 |
|field_collection_item | 22 | 97 |field_fc |und | 4 |
|field_collection_item | 23 | 98 |field_fc |und | 5 |

looks good in the backend, and then I remove the second field collection, it only removes the second, this is good, I think your issue with the float field is because of the failed validation on floats (integer fields don't have the validation problem).

Going back to the float issue, core validation prevents us from saving the translated field collection with the float field, the warnings and validation issue is comming from core. We need to isolate the issue, it's not obvious if its our patch that is causing it (if so, where?) or if it's something up in the "entity" module. I'll see if I can try one more test and try to isolate the issue more.

joseph.olstad’s picture

For someone else that wants to debug this, have a look in field_collection.module
function field_collection_field_widget_embed_validate

this line should be removed:

$instance = field_widget_instance($element, $form_state); 
/* (approx line 1401 with patch 459 and some other non related patches applied)*/

the variable $instance is never used in this function so remove it, useless call.

Then the next line,
$field =
this variable isn't used until much further down in the function but is used.

The function that is called on this line calls a drupal core api field_widget_field() , this core api doesn't like what we're passing into it.

This is where I ran out of time.

At this point we should commit the patch and deal with this use case in a new issue? Or do the maintainers suggest we keep plugging away on this mega-issue?

*EDIT* the warnings in the test from the previous comment when using "integer" instead of "float" field likely provide us with clues that may help figure out the "float" issue (when unlimited fc values with translation turned on on the fc, but not on the fields inside the fc).

idflood’s picture

I continued to dig a little more inside the error and it seems that the problem may be with an "invalid" form state. The field_widget_field will look for something like this in the form state: $form_state['field']['#parents']['field_collection_name']['lang']['index']['#fields']['subfield']['lang'].

When the error happen the $form_state looks like this:

As you can see the second field collection item only has 'array_parents' defined but the first one has also 'field', 'instance', ...

joseph.olstad’s picture

@idflood, the closest similar issue to what we're observing with an unlimited field_collection fc translation enabled that contains a float field (field translation disabled) where the 2nd, 3rd or Nth field collection float value fails validation is this:

Cannot add entity with decimal or float numbers

In this case the solution was a patch titled "allow form_state to be altered"

I tried to add two and two together here but have not yet come up with a solution.

The bottom rectangle below is what core (field.form.inc line 578) is failing to validate . The top rectangle is the first float that IS correctly validated. The Nth float (after the first) always looks like the bottom rectangle.
screenshot

scotwith1t’s picture

Sorry if this is at all off-topic, but I came here from #1999802: Related source suggestions for field collections, which essentially deals with translations of field_collections in the tmgmt module. Using the latest dev with the latest patch and the dev versions of both entity_translation and tmgmt, I was able to export a node with the field_collection entities as part of the XLIF translation file. When I got the translation back and imported it, the translations are in the instance table but not showing up on the node at, for example, /es/node/1. Looking in the devel tab for the node, they are not in the field's array keys, only have 'en' as a key, no 'es' (translation file was for en > es). Not sure if this is a problem in tmgmt (likely) or just in the field_collections translatability overall.

joseph.olstad’s picture

@scotself , after reading your comment it's unclear what steps were made to reproduce your use case.

For instance, you mentioned; Using the latest dev with the latest patch and the dev versions of both entity_translation and tmgmt

but it was not mentioned what version of field_collections you were using. This issue is concerned with field_collections so it's important that we know what version of field_collections you were using and what patch you were using (the latest patch for entity translation support on field_collections is patch #459).

Also, if you could be so kind as to provide steps to reproduce your issue with a description of the configuration of your fc and fields inside your fc and also what sample data you used and what translation options you used and your content type configuration.

This patch is almost ready, I believe that @idflood has identified one of the few remaining edge cases that we'd like to solve before committing this patch. This issue is getting rediculously long so we'd like to really focus on the remaining work.

scotwith1t’s picture

Sure. Latest dev with latest patch means latest dev of field_collections (as of the moment of my comment, pulled down the dev snapshot) and the latest patch being the last one posted, namely yours in comment 459.

Our setup is as follows:
A simple content type with a field collection, which consists of an image field and a body field.
Exported a single node, including field collection entities attached to it.
Export worked great, import seemed to work fine but no field collections were on the translated node.

Looked around in the DB and found that my field_data_field_collection_img and field_data_field_collection_body fields as well as the revision fields for both were indeed populated but there were no entries for the field_data_field_collection field itself, which contains the 2 fields above.

I don't know if I'm describing this sufficiently or not. It may not even be a problem with field_collections translations specifically anyway, it could be with entity_translation or with tmgmt. No idea.

joseph.olstad’s picture

@idflood,
I suspect we should run your test use case and debug this section of code starting at line 1400 (latest dev with patch 459 applied) of field_collection.module

function field_collection_field_widget_embed_validate($element, &$form_state, $complete_form) {

debug this function , I believe the answers lie in there.

to be continued...

joseph.olstad’s picture

We really need to finish this issue. I just looked through the patch again and the opportunity to solve the remaining issue outlined by @idflood definately lies in the following section of the patch:

@@ -1234,7 +1405,28 @@ function field_collection_field_widget_embed_validate($element, &$form_state, $c
   $language = $element['#language'];
 
   $field_state = field_form_get_state($field_parents, $field_name, $language, $form_state);
-  $field_collection_item = $field_state['entity'][$element['#delta']];
+
+  // We have to populate the field_collection_item before we can attach it to
+  // the form.
+  if (isset($field_state['entity'][$element['#delta']])) {
+    $field_collection_item = $field_state['entity'][$element['#delta']];
+  }
+  elseif ($form_state['values'][$field_state['array_parents'][0]][$field_state['array_parents'][1]][$element['#delta']]) {
+    $field_collection_item = clone $field_state['entity'][0];
+    foreach ($form_state['values'][$field_state['array_parents'][0]][$field_state['array_parents'][1]][$element['#delta']] as $key => $value) {
+      if (property_exists($field_collection_item, $key)) {
+        $field_collection_item->{$key} = $value;
+      }
+    }
+  }
+
+  // Handle a possible language change.
+  if (field_collection_item_is_translatable()) {
+    $handler = entity_translation_get_handler('field_collection_item', $field_collection_item);
+    $element_values = &drupal_array_get_nested_value($form_state['values'], $field_state['array_parents']);
+    $element_form_state = array('values' => &$element_values[$element['#delta']]);
+    $handler->entityFormLanguageWidgetSubmit($element, $element_form_state);
+  }

re-run @idflood use case and debug the above lines of code. (use devel with dpm() or debug() statements)

would be nice to have a simpletest for this use case but the @idflood steps are easy enough to follow and I was able to duplicate them.

Who is going to be the hero and put this into the end-zone?

joseph.olstad’s picture

Status: Needs review » Needs work

setting this back to "needs work", while patch 459 does pass all simpletest tests we still need to fix the use case scenario outlined by @idflood , once this is done we should be able to commit this patch (for the love of a higher power, please alien master, have pity on us earthlings and send some alien brain power down to finish this off)

joseph.olstad’s picture

Ok, debugged @idfloods' use case pretty hard,
in the case that the field_collection is using multilingual with field translation but the items inside are not

the solution looks to me now like in field_collection_field_widget_form

I was able to get the correct value for the language using this:

$form_state['entity_translation']['form_langcode'];

however now its a matter of figuring out when this language value should be used in place of what is in

$element['#language']; 

however its a bit tricky because the initial values we want are actually the ones from the source language , (to populate the text fields for data entry) , but we want them to save into the correct language value array structure. I'll have to do more debugging to figure this out.

I did some tests but they all failed so far, need to spend a bit more time on this, I think I'm pretty close to finding a solution , to be continued.

Sergii’s picture

Hi!

I'm testing related issue #1281974: Missing bundle property on entity - related to translations. The latest fix #1281974-110: Missing bundle property on entity - related to translations developed in there included into the latest patch here #1344672-459: Field Collection: Field translation (entity_translation) support.:

  // We have to populate the field_collection_item before we can attach it to
  // the form.
  if (isset($field_state['entity'][$element['#delta']])) {
    $field_collection_item = $field_state['entity'][$element['#delta']];
  }
  elseif ($form_state['values'][$field_state['array_parents'][0]][$field_state['array_parents'][1]][$element['#delta']]) {
    $field_collection_item = clone $field_state['entity'][0];
    foreach ($form_state['values'][$field_state['array_parents'][0]][$field_state['array_parents'][1]][$element['#delta']] as $key => $value) {
      if (property_exists($field_collection_item, $key)) {
        $field_collection_item->{$key} = $value;
      }
    }
  }

Still, nested field collections are failing when I add new translations and the original collection field has more more than one item.
I debugged this a little – and it turns out that sometimes $entity argument passed to entity_extract_ids() function passed from field_attach_form_validate( ), field_collection.module:1428 is NULL. It happens when the both if and elseif clauses (see above) are FALSE so $field_collection_item (which later passed as $entity to entity_extract_ids()) never gets set.

Hence the error:

EntityMalformedException: Missing bundle property on entity of type field_collection_item. in entity_extract_ids() (line 7844 of /var/www/dev.dosomething.org/html/includes/common.inc).

Shouldn't there be a final else somewhere? Or is there a logic error in retrieving $field_collection_item from the form state?

With best regards,
Sergii

joseph.olstad’s picture

Hi sergii, see my comment #476 about the language value, in the case of unlimited fields, the second field fails to work correctly in the translation because the logic isnt expecting what the form gets populated with on page load . Debugging showed me the problem, just havent yet had time to code a solution, a bit tricky because we need logic to kick in for second field of unlimited fields but yet still work for first field value. I would love to have a solution this weekend, we shall see. Review my last comment and this will get us on the same page.

twistor’s picture

+++ b/field_collection.module
@@ -493,9 +557,14 @@ function field_collection_field_update($host_entity_type, $host_entity, $field,
+  if ($field['translatable'] && module_exists('entity_translation') && entity_translation_enabled($host_entity_type)) {
+    unset($host_entity->{$field['field_name']}[LANGUAGE_NONE]);
+  }

So this seems wrong. Even if translation is enabled, it's still valid for the language to be set to LANGUAGE_NONE.

joseph.olstad’s picture

I spent a few hours testing out unlimited field collections and debugging.

now I'm zero'ing in on logic ran after checks for field cardinality, this handles the "unlimited" capability
$field['cardinality'] == FIELD_CARDINALITY_UNLIMITED

so far all I can tell is when you first press "add" translation for a node with unlimited field collections (in my case 3 or 4) I did a lot of dpm looking up, the first field_collection parent has the second language (in my case 'fr') language code.

in the subsequent field_collection parent it is back to 'en'

For whatever reason the second field_collection isn't handled correctly in the translation whereas it is handled correctly in the original language.

to fix this, focus on the sections of code where FIELD_CARDINALITY_UNLIMITED is checked, like right after.

That is all. The related code is in field_collection.module .

BTW, patch 459 still applies cleanly to the latest dev build and newest release.

thinkingcap’s picture

As @twistor pointed out in #479, the following code in field_collection_field_update()

  if ($field['translatable'] && module_exists('entity_translation') && entity_translation_enabled($host_entity_type)) {
    unset($host_entity->{$field['field_name']}[LANGUAGE_NONE]);
  }

results in data loss when editing and saving, with the host_entity set to LANGUAGE_NONE.

I've commented out this code for the time being and things are working. What is the purpose of this?

GaëlG’s picture

I can confirm that #479 and #482 are right:
7.x-1.0-beta10 + #459, when using an optional translatable infinite-valued host field with untranslatable collection fields, I get this :
* create a node in "en" with a field collection filled : OK
* create a node in "en" with no field collection and then edit it to add a field collection : OK
* create a node in "und" with a field collection filled : OK
* create a node in "und" with no field collection and then edit it to add a field collection : BUG the field collection isn't added at all

If I comment out what thinkingcap mentioned in #482, I get OK for these 4 scenarios. I'll do some more tests with other scenarios.

GaëlG’s picture

FileSize
1.34 KB
69.78 KB

I found another bug. Here's the scenario, but the bug might also exist with a simpler one.

  1. Create a "und" node with two field collections
  2. Update it to change the language from "und" to "fr"
  3. Add an "en" translation, with updated subfields (translated text for example)

You'll get the same content in the two english collections. I guess it only applies for a multivalued host field, because of the empty collection which is added in the form by default.

And here's the patch (it also includes #482). I'll do more tests with my config (optional translatable infinite-valued host field with untranslatable collection fields) to see if I can still find bugs with this new patch applied.

Probably still needs work to handle the "float bug" (#467)

JuliaKoelsch’s picture

@GaelG,

I tried applying your patch to the latest dev version. It applies cleanly, but I am getting an error:

PHP Fatal error: Call to undefined function field_collection_is_empty() in ...field_collection.module on line 1405

I don't see that this function is defined in the source code. Can you provide some guidance? Prior to your version of the patch, things were working well for me.

Thanks,
Julia

pierregermain’s picture

@GaelG,

applied your patch to beta-10 of Field Collection and still get these kind of messages when adding a language to a Content Type that uses Field Collection:

Warning: array_filter() expects parameter 1 to be array, string given in field_collection_item_is_empty() (line 591 of /sites/all/modules/contrib/field_collection/field_collection.module).

I would also like to know what kind of patches we need to make Fiel Collection work(around) in multilang.

My situation is as follows:

I create a Content Type with Field Translation that has a Field Collection
- I create a node in Spanish of that Content Type
- I translate the node to English, the data of the Field Collection in Spanish gets lost
- I again enter the data of the Field Collection in Spanish and English. Seems to get updated but with the error posted before in this post.

GaëlG’s picture

FileSize
893 bytes
70.11 KB
4.11 KB

@Spry_Julia Yes, there is an error in my patch, sorry. It's field_collection_item_is_empty(), not field_collection_is_empty(). Looks like pierregermain figured it out on his own.
Here's the correct patch. I tested it against scenario #484, both with beta10 and latest dev. I also join my test file for Firefox Selenium IDE, so that anyone can adapt it to its website.

@pierregermain I'll try to reproduce your bug.

GaëlG’s picture

FileSize
4.02 KB

@pierregermain I could not reproduce your bug on 7.x-1.x + #487, when using an optional translatable infinite-valued host field with untranslatable collection subfields. Here's my Selenium test.
You might be using another configuration?

GaëlG’s picture

FileSize
69.78 KB
1.35 KB

Oops, I just find out that I forgot to add #482 in #487.

DO NOT USE THIS PATCH OR PREVIOUS PATCHES OF MINE (see #502 for why)

pierregermain’s picture

Hello GaëlG,

Thank you for your time. I use 2 Fields on my Field Collection, both translatable and infinite (but I have done some test putting an limit also).

I will try your last patch then. Should I use an other patch before applying patch #489 ?

pierregermain’s picture

I have just used patch #489 ... seems to work when:
- using groupings for the fields
- let the last grouping field in the hierarchy without translation.

Oops, I just seen that when saving the content for the first time the information of the "father" gets lost.

GaëlG’s picture

joseph.olstad’s picture

looks like 1344672-489.patch is worth reviewing.

joseph.olstad’s picture

Status: Needs work » Needs review
joseph.olstad’s picture

Status: Needs review » Needs work

I repeated the use case , translate unlimited collection with float

it resulted in:

Notice: Undefined index: field in field_widget_field() (line 578 of d7/modules/field/field.form.inc).
Notice: Undefined index: instance in field_widget_instance() (line 603 of d7/modules/field/field.form.inc).
Warning: preg_replace(): Compilation failed: range out of order in character class at offset 14 in number_field_widget_validate() (line 389 of d7/modules/field/modules/number/number.module).
Only numbers and the decimal separator () allowed in .

then red boxes around the second, third and fourth translation of unlimited collection. Cannot save the translation of second, third, fourth unlimited collection

sumachaa’s picture

Auto population for field_collection fields is not working for 3rd language.

Below steps were used to replicate this

  • Enable translation with 3 languages; say English, Spanish, French
  • Create a content type with field_collection (address) having 2 fields (state, city) with translation enabled
  • Create new node in the first language - say English - add values for the field_collection fields
  • Translate the above node to the second language - say French - the field_collection fields gets auto populated from the original language
  • Translate the node to the third language - say Spanish - the fields_collection fields are not auto populated

Testing was done with patch #489

This is working fine if the field_collection field (address) is having translation enabled.
Is this the correct way of resolving this issue?

GaëlG’s picture

@sumachaa I don't know if it's THE correct way to do, but that's the way I and many others use.

mErilainen’s picture

I'm having problems updating field collection values. I can add for example three field collections fine, but when I update content and change field collection values, all the field collection references seem to be the same after update. So I have the same values three times.

GaëlG’s picture

@mErilainen Are you sure you enabled translation on subfields?
Don't mind, I read and spoke too fast.

mErilainen’s picture

I have been trying to debug this and I think it happens in field_collection_field_widget_embed_validate() because of

$field_collection_item = clone $field_state['entity'][0];

Using

$field_collection_item = entity_create('field_collection_item', array('field_name' => $field['field_name']));

works better, but the field collection values seem to be empty when editing content again.
Further investigation needed...

betoscopio’s picture

I tried the patch in #489 and I found the following problems:
When I run update.php (with drush) I got this messages:

Do you wish to run all pending updates? (y/n): y
Unable to save a field collection item without a valid reference to a host entity.      [error]
Performed update: field_collection_update_7007                                                    [ok]
'all' cache was cleared in self 

The changes seems not fully applied (because the error), if I run the update script two more times I got the same error.
If I run the script a fourth time I see no error messages and changes are not pending. I checked this in two copies of the website, the behaviour was the same.

After apply the patch and activate field_collection as a translatable entity I have the following behaviour:
- In a field collection with 2 fields (one translatable and one not) with a fixed number of 8 items
- Before run multiple times the update.php I had problems becuase some values were empty (the translatable field)
- After run update.php for fourth time (no more error messages) I have no problems with this field.

GaëlG’s picture

Do not use my last patch! It happens to work in many cases when node revision is enabled (which was the case in all my tests), but the data gets corrupted.
It's hard to find a use case where a bug happen, but if you add a new collection to an existing node, you get a node referencing the same collection with two different revision ids, which is wrong and could lead to data loss, even if the data do not seem corrupted in the interface.

I have no idea what the hell can happen if node revisions are disabled, but this is probably what happened to some of you lately.

I'm working on it again...

GaëlG’s picture

Hum... And now it looks like I cannot reproduce the bug #483 when using latest dev+#459+#482. Conclusion: #489 is not only buggy and risky, it's also useless... This issue will make me mad.

sylus’s picture

joseph.olstad’s picture

according to the automated testing settings, 7.x issue testing is currently disabled, we'll have to get a maintainer or co-maintainer to enable automated testing for 7.x if we want to test patch #504 against head.

joseph.olstad’s picture

Status: Needs review » Needs work

Ok I ran the tests in simpletest by enabling the simpletest module and going to
admin/config/development/testing

Expand field ui
and test field_collection

Field collection
Tests creating and using field collections.
140 passes, 0 fails, 0 exceptions, and 31 debug messages

Field collection content translation
Tests using content under translation.
26 passes, 0 fails, 0 exceptions, and 9 debug messages

Field collection entity translation
Tests using content under translation with Entity Translation.
211 passes, 2 fails, 1 exception, and 45 debug messages

Notice:
Undefined index: de Notice field_collection.test 1144 FieldCollectionEntityTranslationTestCase->getFieldValues()


Other:

Value NULL is equal to value 'Translatable DE Mod'. Other field_collection.test 1195 FieldCollectionEntityTranslationTestCase->testEntityTranslation()

The field collection item has been removed from the database. Other field_collection.test 982 FieldCollectionEntityTranslationTestCase->removeTranslationForm()

joseph.olstad’s picture

Repeated use case based on what was described by idflood

gives the following message when adding translation of unlimited fc :

Notice: Undefined index: field in field_widget_field() (line 578 of /modules/field/field.form.inc).
Notice: Undefined index: instance in field_widget_instance() (line 603 of /modules/field/field.form.inc).
Warning: preg_replace(): Compilation failed: range out of order in character class at offset 14 in number_field_widget_validate() (line 389 of /modules/field/modules/number/number.module).
Only numbers and the decimal separator () allowed in .
Notice: Undefined index: field in field_widget_field() (line 578 of /modules/field/field.form.inc).
Notice: Undefined index: instance in field_widget_instance() (line 603 of /modules/field/field.form.inc).
Warning: preg_replace(): Compilation failed: range out of order in character class at offset 14 in number_field_widget_validate() (line 389 of /modules/field/modules/number/number.module).
Only numbers and the decimal separator () allowed in .

Kristen Pol’s picture

I have confirmed that nested limited (e.g. max=5) field collections are working with the patch but unlimited is not. I see similar errors to #507 when the nested field collections are unlimited.

Kristen Pol’s picture

We are looking for someone to get this patch over the finish line. I've contacted a couple people directly but didn't get any response. If you are willing and able to get this patch working asap (paid consulting), please contact me through my profile page. Thanks.

chrisdarke42’s picture

So one issue that doesn't get resolved by the previous patches, seems to be the depth issue,
field_collection_field_widget_embed_validate only seems to work to a certain depth, and I have cases where nested field collections within other field collections just cause errors on translation.

This adds an implementation of drupal_array_get_nested_value to get the correct field collection regardless of depth for the validation.

Kristen Pol’s picture

We have a new patch that is working for us that @loopduplicate and @chrisdarke42 fixed. We'll try to get that up very soon.

loopduplicate’s picture

We are having luck using the patch from #510 combined with the patch from #6 in https://www.drupal.org/node/2339315#comment-10848466 .
With these two patches, everything works for our set up. The structure is:

* A translatable node
* A translatable field collection in the node
* A non-translatable field collection in the field collection

None of the fields in the field collections need to be set to translatable.

Hope this helps.

Regards,
Jeff

joseph.olstad’s picture

RTBC+1 as described by loopduplicate

GREAT WORK EVERYONE! Been waiting for this day to say RTBC+1 for quite some time.

I am using patch #510 from this issue
and
patch #6 in #2339315: Source language prepopulated values should be also included in $form_state['field']
as described in comment#512

I retested the use cases, looks like the real key here is the patch to entity_translation , this should also be getting our attention.

joseph.olstad’s picture

see related issue.
Great work once again everyone!

Just to clarify, our unlimited field collections are now properly translating using entity_translation.

mrchristophy’s picture

This is great news! Just to be clear, which versions of Field Collection and Entity Translation should we be using for these patches?

Kristen Pol’s picture

We are using versions:

  • Entity Translation - 7.x-1.0-beta4+10-dev
  • Field Collection - 7.x-1.0-beta10+1-dev (afraid to update to beta11 right this second :)

and patches:

  • Entity Translation - entity_translation-prepopulate-form-state-2339315-6.patch
  • Field Collection - field_collection_field-1344672-510.patch

Cheers!

loopduplicate’s picture

@Kristen you wrote, "Field Collection - 7.x-1.0-beta10+1-dev (afraid to update to beta11 right this second :)"

Actually, 7.x-1.0-beta10+1-dev is the same as 7.x-1.0-beta11... we aren't afraid :) http://cgit.drupalcode.org/field_collection

wroxbox’s picture

Here is long tests with screenshots from both admin and public site + some database tables:

Our setup:

projects[field_collection][download][url] = git://git.drupal.org/project/field_collection.git
projects[field_collection][download][branch] = 7.x-1.x
projects[field_collection][download][revision] = "ec024e5cfb5308bce4d10756683a8cd3fa881b8f"
projects[field_collection][patch][] = "https://www.drupal.org/files/issues/field_collection_field-1344672-510.patch"

projects[entity_translation][patch][] = "https://www.drupal.org/files/issues/undefined_property_menu-2511966.patch"
projects[entity_translation][patch][] = "https://bitbucket.org/!api/2.0/snippets/tierakehitys/g9kXM/c8945329eee9992c7d5d0bbabe115cc44c2dbc7e/files/et-i18n_taxonomy-1661348-24.patch"
projects[entity_translation][patch][] = "https://www.drupal.org/files/issues/entity_translation-prepopulate-form-state-2339315-8.patch"

core: 7.42
Nodetype: Service_card (Revisions enabled, entity translation)

field_short_description (Enabled field translation)
field_deployment (Field collection with field translation enabled, unlimited values)
- field_short_description (enabled field translation, same field as in node)

This works:

  1. create node (default lang en)
  2. add data to short description
  3. add data to short description inside field collection item
  4. save

This does not:

  1. Open node to edit
  2. Click translate (target language fi)
  3. Add FI text in short description field
  4. Add FI text in short description field inside Field collection
  5. save

What happens. The original english value inside field collection is visible in form as the translated too, but their revisions are mixed as the original entity translation data:

Node field & Entity Translation + Field collection field & Entity Translation

INSERT INTO `field_data_field_short_description` (`entity_type`, `bundle`, `deleted`, `entity_id`, `revision_id`, `language`, `delta`, `field_short_description_value`, `field_short_description_format`)
VALUES
	('node', 'service_card', 0, 26511, 137594, 'en', 0, 'Short description field', NULL);

INSERT INTO `entity_translation` (`entity_type`, `entity_id`, `language`, `source`, `uid`, `status`, `translate`, `created`, `changed`, `revision_id`)
VALUES
	('node', 26511, 'en', '', 1, 1, 0, 1456237982, 1456237982, 26511);


INSERT INTO `field_collection_item` (`item_id`, `revision_id`, `field_name`, `archived`)
VALUES
	(38776, 150159, 'field_deployment', 0);


INSERT INTO `field_data_field_short_description` (`entity_type`, `bundle`, `deleted`, `entity_id`, `revision_id`, `language`, `delta`, `field_short_description_value`, `field_short_description_format`)
VALUES
	('field_collection_item', 'field_deployment', 0, 38776, 150159, 'en', 0, '<p>Short summary of short description field inside field collection</p>\r\n', 'full_html');

INSERT INTO `entity_translation` (`entity_type`, `entity_id`, `language`, `source`, `uid`, `status`, `translate`, `created`, `changed`, `revision_id`)
VALUES
	('field_collection_item', 38776, 'en', '', 1, 1, 0, 1456237982, 1456237982, 38776);

Above is the data from the first saving

-----------------
Add translation
-----------------

INSERT INTO `field_data_field_deployment` (`entity_type`, `bundle`, `deleted`, `entity_id`, `revision_id`, `language`, `delta`, `field_deployment_value`, `field_deployment_revision_id`)
VALUES
	('node', 'service_card', 0, 26511, 137595, 'en', 0, 38776, 150161),
	('node', 'service_card', 0, 26511, 137595, 'fi', 0, 38777, 150160);

INSERT INTO `field_collection_item` (`item_id`, `revision_id`, `field_name`, `archived`)
VALUES
	(38776, 150161, 'field_deployment', 0),
	(38777, 150160, 'field_deployment', 0);


INSERT INTO `field_data_field_short_description` (`entity_type`, `bundle`, `deleted`, `entity_id`, `revision_id`, `language`, `delta`, `field_short_description_value`, `field_short_description_format`)
VALUES
	('field_collection_item', 'field_deployment', 0, 38777, 150160, 'fi', 0, '<p>FI-Short summary of short description field inside field collection</p>\r\n', 'full_html'),
	('field_collection_item', 'field_deployment', 0, 38777, 150160, 'en', 0, '<p>Short summary of short description field inside field collection</p>\r\n', 'full_html'),
	('field_collection_item', 'field_deployment', 0, 38776, 150161, 'en', 0, '<p>Short summary of short description field inside field collection</p>\r\n', 'full_html');

INSERT INTO `entity_translation` (`entity_type`, `entity_id`, `language`, `source`, `uid`, `status`, `translate`, `created`, `changed`, `revision_id`)
VALUES
	('field_collection_item', 38776, 'fi', '', 1, 1, 0, 1456237982, 1456237982, 38776),
	('field_collection_item', 38777, 'fi', '', 1, 1, 0, 1456237982, 1456237982, 38777);

Now the entity translation table has two same language items, as the original (38776) should be en.

Also the field inside FC got third line in database mixing revision and language.

By removing Revisions from node the setup works perfect.

https://dl.dropboxusercontent.com/u/775110/ss/settings-for-field-collect...
https://dl.dropboxusercontent.com/u/775110/ss/1-translatable-field.jpg
https://dl.dropboxusercontent.com/u/775110/ss/2.1-field-collection-item.jpg
https://dl.dropboxusercontent.com/u/775110/ss/2.2-field-short-descriptio...
https://dl.dropboxusercontent.com/u/775110/ss/3-translated-node-field-co...
https://dl.dropboxusercontent.com/u/775110/ss/3.1-original-field-collect...
https://dl.dropboxusercontent.com/u/775110/ss/3.2-modify-field-collectio...
https://dl.dropboxusercontent.com/u/775110/ss/3.3-field-collection-trans...
https://dl.dropboxusercontent.com/u/775110/ss/3.4-field-collection-field...
https://dl.dropboxusercontent.com/u/775110/ss/3.5-field-items-inside-fc-...

joseph.olstad’s picture

Hi wroxbox, I tested my use case with revisions by enabling revisions (basic page with unlimited field collection of float with description) and everything seems to work on my end.

I'm using:
entity_translation:
version 7.x-1.0-beta4
only one patch for entity_translation:
entity_translation-prepopulate-form-state-2339315-6.patch
#2339315: Source language prepopulated values should be also included in $form_state['field']

field_collections
version: 7.x dev hash number ec024e5cfb5
from Thu Oct 22 16:51:03 2015
with patch number 510 from this issue

I suspect there to be a problem with your heavily patched entity_translation module suggest re-testing your use case with a new copy of entity_translation 7.x-1.0-beta4 with the patch from #2339315: Source language prepopulated values should be also included in $form_state['field'] , I'm successfully using patch 6.

The aforementioned config with revisions enabled OR disabled is working for me.

wroxbox’s picture

Hi Joseph

I tested your setup and removed the heavily patched entity translation. No success. Our patches were fixing Entity translation over taxonomy terms and also using latest dev of ET.

Created completely new content type with only one field collection (unlimited, field translation enabled) with one field inside (translatable) and the same issue remains.

joseph.olstad’s picture

wroxbox, I forgot to mention, I'm using D7 core 7.39, not sure if that makes a difference.

and I'm not using workbench in my test environment. its pretty barebones aside from i18n and the entity_translation.

perhaps my use case is different enough than yours but I'm hoping maybe we can get some more people testing and sharing their test results as I'm very pleased with the progress.

idflood - can you retest your use case with the new patch for entity_translation and field_collection? this'd help a lot. anyone else, please?

Stevel’s picture

I've tested the patches (from #1344672-510: Field Collection: Field translation (entity_translation) support. and ET #2339315-9: Source language prepopulated values should be also included in $form_state['field']) on Drupal 7.43, translatable node, untranslatable field collection containing some translatable fields.

Everything seems to work as expected, but some tests are still failing in our deployment workflow (same as in #1344672-506: Field Collection: Field translation (entity_translation) support.).

achap’s picture

I have tested the patch at #510 along with the related patch mentioned in that comment from entity_translation #6. It is working for me. Drupal core 7.41, Field collection 7.x-1.0-beta11 and entity_translation 7.x-1.0-beta4. I set the field collection itself (rather than the field collections fields) to translatable.

badrange’s picture

@joseph.olstad, @wroxbox - I may be clutching for straws here, but could the differences you experience be caused by having different settings for Field collections under "Translatable entity type" at/admin/config/regional/entity_translation?

wroxbox’s picture

iamfredrik’s picture

I get this error when running updb after applying the latest patch:

"Unable to save a field collection item without a valid reference to a host entity. "

How to fix this?

dewalt’s picture

There is an issue with field validation - invalid values reported by hook_field_validate() causes 500 error on site. The issue exists for patches from #248 to #510. Other patches weren't checked.

Behaviour to reproduce:
1. Create node type, configure entity_translation handler.
2. Add untranslatable entity_collection field.
3. Configure entity_translation handler for field_collection entity.
4. Add translatable field to field collection. (I used link field)

Steps to reproduce
1. Go to node creation form (/node/add/)
2. Fill invalid URL in "URL" input of link field.
3. Submit form.
Expected: form is shown with validation errors
Actual: 500 error page is shown

Propose to fix
The error takes place because language of the field in field collection item entity is changed by EntityTranslationHandler::entityFormLanguageWidgetSubmit() before field is validated. And field validation expects, that validating field value has the same language, as used to built form element.
See screenshots.
Source code

Dump
Mooving field_attach_form_validate() before entity is processed by translation handler fixes the problem.

I created patch with the fix, based on #510 one.

loopduplicate’s picture

Here's an interdiff between 510 and 527. I didn't have time to review 527 but I figured that an interdiff would help.

loopduplicate’s picture

Well, crap. The interdiff shows that the patch in #510 no longer applies right. The #510 patch used hook_update_N, 7007 but the latest dev version of field_collection added 7007 as well.

loopduplicate’s picture

Here's an updated patch for 510. This doesn't include the change made in #527. I'm uploading two interdiffs: 510 vs 530 and 510 vs 527.

The patch in #527 seems to mess up field_collection.install by adding two 7007 updates.

*edit* Please do not use the patch in this comment. Use one of the patches in #531. If you just want a reroll of what was in #510, use the patch "field_collection-entity_translation_support-1344672-531-without-527.patch". If you want to incorporate the changes that were suggested in #527, use "field_collection-entity_translation_support-1344672-531-with-527.patch" . -loop

loopduplicate’s picture

ugh. The patch in #530 is missing includes/translation.handler.field_collection_item.inc . Sorry about that. Anyway, here's two updated patches. Each patch addresses the hook_update_N issue. One of the patches incorporates what was done in #527 and the other is basically a reroll of #510.

loopduplicate’s picture

wizonesolutions’s picture

Are the issues in the issue summary still a problem? I would like to update the issue summary to include some steps to reproduce/review or a description of what the patches to be reviewed add, if anything needs to be configured, etc....but I lack information. @loopduplicate?

loopduplicate’s picture

Hi @wizonesolutions,

I'll answer your questions one at a time.

"Are the issues in the issue summary still a problem?"
The summary is very out of date. For example, it says the patch to use is from #437 but that's not true anymore. The remaining tasks section says, "Update hook may delete existing data". I'm not sure if update hooks delete existing data because I originally tested on a new site and never had the need to run updates.

The best help I can give right now is to give you the 'recipe' that got all this working for my particular use case. There still needs to be tests written. Once the tests are written, it should be clear what is still broken and what works.

Recipe:

Use this patch from #531:
field_collection-entity_translation_support-1344672-531-without-527.patch

Use this patch from https://www.drupal.org/node/2339315#comment-10884422
entity_translation-prepopulate-form-state-2339315-8.patch

Set up your fields like this:

* A translatable node
* A translatable field collection in the node
* A non-translatable field collection in the field collection

None of the fields in the field collections need to be set to translatable.

Regards,
loopduplicate

joseph.olstad’s picture

Hi @loopduplicate , nice work, just ran the built-in simpletests for "field" using the following scenario and got these detailed results ;

Scenario:

enable the "simpletest" module

go to: admin/config/development/testing

Select "Field types" from the available list of tests
the check "field collection entity translation"
then click on "Run Tests"

Configuration prior to running tests:
Latest core 7.43
entity_translation module with your (loopduplicate patch 8 of issue #2339315: Source language prepopulated values should be also included in $form_state['field']):

Latest dev of field_collections 7.x-1.x:
With patch 531-without-527 and the latest dev of field_collections
with patch 531-with-527 and the latest dev of field_collections

Results:

everything passes, except these two:
field_collection.test line number 1195
"Value NULL is equal to value 'Translatable DE Mod'."
field_collection.test line number 982
"The field collection item has been removed from the database."

I checked and this is the same simpletest results that patch 510 gave with the older dev.

Summary

It looks like your patches 531 are an improvement having resolved your issue and have not caused any regression. There is still the outstanding failures on the simpletest that existed previously on the previous patches, I haven't looked closely to see what is causing this, if the simpletest is needing an update or if its actually a problem that we need to solve. I'm hoping that the simpletest results will help us finalize this patch and commit it.

Thanks

loopduplicate’s picture

Thanks Joseph!

gnucifer’s picture

Using the patch in #534 (field_collection-entity_translation_support-1344672-531-without-527.patch), I still got a crash when using nested field collections if the parent field collection has more than one item. After an especially painful debugging session I tracked down this but to Entity translation module and now feel an urgent need to sooth my poor brain with some alcohol. I will create and issue (with the patch) in the Field Collection issue queue and link to it here.

EDIT: Patch can be found here: https://www.drupal.org/node/2715091
See this issue instead: https://www.drupal.org/node/2339315

loopduplicate’s picture

Hi gnucifer,

I'm a little confused by your comments. In #534 I said that you need the patch from 531 and you need the entity translation patch. But then in your #537 comment, you wrote "After a very long and especially painful debugging session I tracked down this but to Entity translation module". I mean, it sounds like you didn't apply the entity translation patch. In fact, in that same comment #537 you link to the entity translation issue with the patch I said was needed. (https://www.drupal.org/node/2339315)

I'm probably being stupid, but can you explain why using your new patches (the one here and the one on the entity translation issue) is better than using the patch from #531 here in combination with the patch from #9 on the ET issue, as outlined in #534?

Regards,
loop

loopduplicate’s picture

OK, I was being stupid. I looked more carefully at the other issue. Thanks gnucifer :)

gnucifer’s picture

@loopduplicate Yes, the size of this issue got the better of me and completely missed that there was a patch for entity translation fixing the problem with nested field collections. I unnecessarily created a duplicate patch with an alternative solution. I have now abandoned those changes, and instead made some adjustments to the original patch.

loopduplicate’s picture

OK, I'll try to clarify:

The current best solution seems to be to use your two latest patches:
* From this issue, #538:
** https://www.drupal.org/files/issues/field_collection-entity_translation_support-1344672-531-with-527-538_0.patch
* From the Entity Translation issue, #14
* https://www.drupal.org/files/issues/entity_translation-prepopulate-form-state-2339315-14.patch

The above solution hasn't been tested by many people yet but #535 has instructions for running some automated tests, when someone has time.

Regards,
loopduplicate

jmuzz’s picture

joseph.olstad’s picture

Plach recently published "Entity Translation" 7.x-1.0-beta5 which includes the related patch previously required for this issue.

What is now needed:

  1. Latest core 7.43
  2. Entity Translation version 7.x-1.0-beta5 or newer
  3. Field Collection (latest dev) with patch #543

I'm thinking that we're very close to being able to commit. If I was maintainer of this project I'd commit the best available patch and let people open new tickets for the "edge" cases that may be remaining.

gnucifer’s picture

@joseph.olstad A small correction, #538 contains the alter_hook introduced in the latest version of entity transalation, #543 is an older patch on which #538 is based, so perhaps #538 should be considered the best candidate.

sinasalek’s picture

@joseph.olstad good point, it does not have to be released right away. but when it's committed more non technical people can also easily test it. It's a monster patch, difficult to review, difficult to keep it up to date with dev and difficult to manage. good job everyone so far

james.williams’s picture

Status: Needs review » Reviewed & tested by the community

Let's do it! Tests do now pass, and there have now been many eyes on the work so far. So I'm marking this as RTBC *for the patch in comment #538. Yes, there's outstanding issues, but they can be covered in follow-up issues rather than trying to continue working on this increasingly-monolithic patch/issue. Then hopefully each outstanding issue can be dealt with in smaller/easier issues. The patch from #538 definitely covers many use cases and does work for them as far as has been seen so far, so getting this committed would be a great step to completing full entity translation support as it will then cover that for many (most?) users.

Of course someone could argue me down and change the ticket status back, in which case, fair enough, I'll accept that! :-)

The last submitted patch, 504: field_collection_field-1344672-504.patch, failed testing.

The last submitted patch, 510: field_collection_field-1344672-510.patch, failed testing.

jmuzz’s picture

Status: Reviewed & tested by the community » Needs work
FileSize
69.86 KB

I took the with-527 version and I fixed a couple of small issues:

  • The patch didn't apply to my dev.
  • Removed the part of the patch that took out the updateHostEntity call. That call originally a part of this patch but it was needed to fix something unrelated and was committed. This patch should not undo that.

The big data deletion issue still remains. I'll give some more specific steps about how to reproduce it.

Get a new drupal core. Create a dir sites/all/modules/contrib , all the required modules will go inside it. Get the following modules and put them in contrib. I don't believe the version matters:

  • entity
  • i18n
  • variable

Get the latest dev version of the following modules:

  • field_collection
  • entity_translation

Get the database from #332 and don't worry about the instructions there or the smartling modules they are not needed.

Import that database and set up this drupal install to use it. The site should work at this point. See the nodes with field collections. They have "collection3" fields with filled in text field values in field "text3".

Reset the admin password (for example drush upwd admin --password="admin") and see that the node edit forms are functional.

Apply the entity translation patch.

Run /update.php .

See an error message Failed: Exception: Unable to save a field collection item without a valid reference to a host entity. in FieldCollectionItemEntity->save() (line 431 of /home/jmuzz/devel/local.smartling.com/sites/all/modules/contrib/field_collection/field_collection.entity.inc).

Try to edit the nodes with the field collections. See that the data is no longer in the forms.

Clear the cache.

Look at the nodes with field collections and see that the lines under "collection3" fields are blank.

Check out the database and see that the data is gone, for example:

mysql> select * from field_data_field_text3;
Empty set (0.00 sec)
stefan.r’s picture

Needs work or needs review?

jmuzz’s picture

As long as it's going to delete data it needs work.

Until that is addressed the review is: "Needs to stop deleting data"

loopduplicate’s picture

Does anyone feel comfortable updating the description in this issue? It's pretty outdated.
Regards,
Jeff

joseph.olstad’s picture

jmuzz, I have not found any data integrity problems in my tests.

I acknowledge your concerns however this module is still flagged as "beta" , my take on it is the "beta" code is producing corrupted nested field collections, this patch we're working on as far as I see creates valid nested field collections since patch 510 .

For the sake of progress I propose a few options:

1) Provide a 7.x-2.x branch for entity translation support using a fork of the 7.x-1.x branch patched with the latest patch of this issue, then once a 7.x-2.x branch is created we can open issues for dealing with handling corrupted beta 1.x nested field collections in a more graceful way without deleting them.

or
2) commit this patch as is on the dev branch, open a new issue for the delete and delay tagging a beta 5 or a 1.0 release

Above you've provided a database , however that database was created using beta code prior to the patch when nested field collections were not working correctly previously.

Seems like we've got a dozen eggs, some were broken before, should we try to put the eggs back together again or eat the scrambled eggs and get some chickens to lay some new eggs?

jmuzz’s picture

@joseph.olstad I want this to be committed too, and I like the thought that it might be a problem with the database and not the patch. I don't recall seeing any such corruptions though when I was working with that data and trying to solve the problem. Could you be more specific about the corruption, link to "the patch when nested field collections were not working correctly," or provide any other evidence that that may be what's happening?

I did use a #510+ version of this patch.

I also tried updating the smartling database without this ET patch and it didn't delete anything. The data is deleted during the 7008 update added in this patch.

joseph.olstad’s picture

***EDIT***
see comment #558
jmuzz, this issue woke me up at 4am , it became apparent that I had not actually run a updatedb after having applied the patch. In my test cases I was working on new data that I was adding in. Could it be that update_7008 is no longer needed? What would happen if we just removed the update_7008 from these patches?
***EDIT*** see comment #558

maxplus’s picture

Hi Thanks,
I started testing patch #550 in combination of latest dev of Entity Translation on a production site.

gnucifer’s picture

@jmuzz @maxplus You are using an older patch which does not implement the new hook_entity_translation_source_field_state_alter introduced in the new version of entity translation. Try the one in #538 instead.

letrotteur’s picture

Can't apply #538 cleanly to latest dev.

jmuzz’s picture

I re-rolled 538, got the latest repository version of entity_translation, and tried running the update on the smartling database. The data is still being deleted and in addition the attached error messages showed after the update.

Was the addition of the hook supposed to address the data deletion?

jmuzz’s picture

I dug into the smartling example some more and found that it was expecting a missing entity controller. I think the smartling module suite is supposed to provide it but when I download that the site no longer functions, so I'll agree with @joseph.olstad that it isn't such a great example afterall.

jmuzz’s picture

Status: Needs work » Needs review

  • malberts authored c4d64f9 on 7.x-1.x
    Issue #1344672 by malberts and many others: Field Collection: Field...
jmuzz’s picture

Status: Needs review » Fixed

It was already marked RTBC in #547 based on a lot of comments and testing.

Thanks everybody for all the time put into this and for being persistent. It wasn't easy but I'd call this a success.

If there are any further problems related to entity translation please create a new issue and do not reopen this one (ever).

sinasalek’s picture

After more than 4 years, The impossible has just happened. Thanks everyone for all the hard work

plach’s picture

Oh, wow, this is disappointing, I was hoping we'd reach comment 600 ;)

Jokes aside, thank you all for your tireless efforts, I'd call this a huge success!

joseph.olstad’s picture

Thanks everyone! This was a big one!

jramby’s picture

Woooow guys, it has been a long one!!! you're all awesome!! Thanks to all!!

giupenni’s picture

Woooow! Thank you everyone, you're all awesome!!!

jmuzz’s picture

Follow up issue about tests now failing in HEAD.

Is is just me, or does it look like the tests passed when they were posted in this issue?

I'm trying to figure out what is going on. Are we supposed to have to click on the lines that say the tests passed to find out whether or not they passed?

Status: Fixed » Closed (fixed)

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

Status: Closed (fixed) » Needs work
sinasalek’s picture

Status: Needs work » Closed (fixed)

Just to check @jmuzz comment

edi44’s picture

Hello, I'm not able to get field_collection working with entity_translation 7.x-1.0-beta5... using latest dev not working... try to patch module run in erros...

How can i get this to work? Which version should i use? Which patch?

james.williams’s picture

Hi @edi44 - entity_translation 7.x-1.0-beta5 and the latest 7.x-1.x-dev should be compatible and already contains the final work from this ticket, so no patch from this ticket should be necessary.
As this is an old closed issue, please could you open a new support request, detailing your specific problems/errors if you are getting them even without patches? Thanks!

mastoll’s picture

This is the latest translation issue that I can find. Is the latest patch from this ticket working?

When updating FC from 1.0-beta 5 to the June-23-16 dev version.

Running PHP Update:

Pending update:
field_collection module
7008 - Update fields in field collections already set to use Entity Translation.

The error reads:
Update #7008
Failed: Exception: Unable to save a field collection item without a valid reference to a host entity. in FieldCollectionItemEntity->save() (line 442 of .....\field_collection\field_collection.entity.inc).

loopduplicate’s picture

Hi mastoll,

I'm going to write something similar to what was in #575.

You wrote, "This is the latest translation issue that I can find. Is the latest patch from this ticket working?"

The code from this ticket has been committed already. This mean, among other things, that any patch from this issue will not apply to the latest dev version. Perhaps what you should do is create a new issue, since you can't find an existing open one that is relevant. In the new issue describe the problem you are having. I would mark your new issue as related to this one.

Regards,
loop

mastoll’s picture

I know the latest patch from this issue has been committed. I'm wondering if it's working. More specifically, I'm wondering if update #7008 is the commit of the patch from this issue. See, the update is failing and I'm trying to figure out which issue the update is connected to so that I CAN relate whatever post to the correct place.

james.williams’s picture

Hi @mastoll -- yes, update 7008 was indeed added by the work in this ticket (see http://cgit.drupalcode.org/field_collection/commit/?id=c4d64f9d987eb9bde...), so yes, please create a new ticket outlining the problem, and relate that ticket back to this one.

This particular ticket has been going on for a very long time and so we were all just happy to move on from it. If there's a problem with this work, of course that needs resolving though, so thanks for finding it! Let's just continue in a new ticket to give a fresh clean start for the fix, rather than years of history and 500+ comments that we have here :-)

gnucifer’s picture

@mastoll It's working (at least for me, so far :)). The error you got is because you have database-corruption for your field collections, with orphaned field-collections missing a host entity. This might still be field-collection's "fault" though, I have experienced the same thing. It can be solved by writing a clean-up script, for example: drush php-script delete-orphaned-field-collections.php. Basically write an entityFieldQuery loading all field collections, check if ->hostEntity() returns false, and delete those field collection items. You might want to check the data first so you are not deleting critical data, and salvage it in some manner.

lexa.mihu’s picture

Same problem as #576

james.williams’s picture

Follow-up ticket created: #2759157: Orphaned field collections break update 7008. Let's move discussion around this problem with update 7008 to that ticket and leave this original, closed, ticket (and the 200+ people being notified by updates to it!) to rest in peace :-)

dianikol’s picture

I'm a little confused here. Which patch I need to apply??

Thanks

james.williams’s picture

@dianikol - the work done in this ticket is already part of the latest dev release (7.x-1.x-dev), but is not yet included in an official 'stable' release.

That said, you may also need the spin-off patch in #2759157: Orphaned field collections break update 7008, if you experience problems on running updates on that release.

dianikol’s picture

@james.williams - All good. All my content on my FC is there

My setup is I have translatable the host FC field on the node and non translatable the FC field itself. In case someone miss this setting we need to make Field collection translatable on the Entity translation configuration.

James do you think I should apply the patch you mention anyway?

Thank you everyone, you just add a lot more value to the Drupal

james.williams’s picture

No, you will be fine without the other patch. The other patch is just used if you had previously-corrupted/invalid data that translation would now be incompatible with. If you didn't get warnings about that, you don't have bad data in that way to be concerned about*!

*as far as we know ;-)

titouille’s picture

Hi,
Has anyone tried to translate field collections embed in paragraphs ?

I created a field collection with some fields in a paragraph bundle. The paragraph bundle is added to the basic page node bundle.
I enabled ET for basic page, paragraph bundle and field collection.
Basic pages has translations on field level.
Paragraph bundle is not checked as translatable in field definition (from basic page), but has some translatable fields.
Field collection is not checked as translatable in field definition (from paragraph bundle) but has some translatable fields.

When I create a basic page in english, I add a new paragraph with the field collection fields embedded. I fill some fields and save the content. All is ok
When I translate the basic page in french, paragraph display the english values in form, field collection too.
I change the values of paragraph translatable fields and field collection translatable fields and save the form.
Values are saved successfully.
But when I return on the original (english) content, Field collection display me a "English translation unavailable for Elements 1." message.

The paragraph is translated successfully, but field collection erase the original content with the french content.
In database, translatable fields hosted by field collection are in the two languages (two entries for each field) but field collection itself indicate that the original language is french and has only french translation, no english.

It seems that the process erase the language informations by the latest used language in form submit. If I edit and save the original (english) content, this time the field collection indicate original language as english and only english key is found in the "translations->data" key.
When I go to edit mode in french or english, I can see the field collection sub-fields translated correctly, so it can retrieve correct informations for the sub-fields, but erase the "translations" informations each time I save a basic page.

I'm using
field_collection 7.x-1.0-beta11+11-dev
entity_translation 7.x-1.0-beta5
paragraphs 7.x-1.0-rc4+5-dev patched with https://www.drupal.org/node/2452675#comment-11418169

If anyone has an idea...

Thanks in advance.

dianikol’s picture

Hey, Is the final patch commited to the last update beta version (2016-Nov-17) or should i apply it ?

Thanks

hgoto’s picture

@dianikol, I believe the patch is included in the version 7.x-1.0-beta12. You can check it in the following pages :)

dianikol’s picture

Cool Thanks

blacklabel_tom’s picture

Hi,

I'm working on a site that DOES NOT have entity_translation installed and have updated to the latest version of field_collection (7.x-1.0-beta12) and I'm getting the following error when trying to run any drush command:

PHP Fatal error:  Class 'EntityTranslationDefaultHandler' not found in field_collection/includes/translation.handler.field_collection_item.inc on line 13

Looking through the modules I can see that Content translation (translation) is enabled, which could be conflicting.

Will investigate at my end to see if I can figure out if this is a site issue or a module issue.

Cheers

Tom

DamienMcKenna’s picture

@blacklabel_tom: Please open a new issue for this bug.

Sneakyvv’s picture

Might be barging in here unappropriately, but can anyone tell me why in commit c4d64f9d these lines were added in field_collection_field_widget_embed_validate() (line 1587 in field_collection.module) ?

// Ensure field columns are poroperly populated.
    $item['value'] = $field_collection_item->item_id;
    $item['revision_id'] = $field_collection_item->revision_id;

In my use case, using paragraphs and paragraph_panes, the field collection item's item_id is not set since it is new (and attached to a non-saved paragraph item). To be even more specific, the paragraph item is never going to be saved at all, since that's the way paragraph panes is set up.
Without, for now, going deeper into detail, these lines break my module and I suppose my question is whether these lines are really necessary, since I seem to be able to create FC items without them. Both attached to an actual host entity and not.
I don't have entity translation enabled and I understand that's what this issue is about (I didn't read all 500+ comments) and thus these lines must have been added for that purpose, which my case might not be exposed to (i.e. therefore removing the lines is only not a problem for me, but it is in general).

Either way, I assume that there's some other code which, if the value key is not set (as it is in my case for a new FC item), will create a new entry in the database and checks the value key for that purpose. However, if that is the case, i.e. that's the only purpose of setting that value key, then I guess there won't be any harm done in putting an extra check around the lines above, which prevent setting the value key if there is no FC item_id, assuming of course that there's a empty() check in "that other code", and no isset() check... Or do you guys have a reason why that should not be done?

juampynr’s picture

@blacklabel_tom I experienced the same issue that you reported at #591 and created a new issue with a workaround at https://www.drupal.org/project/field_collection/issues/3117095.