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):

Files: 
CommentFileSizeAuthor
#447 field_collection-add_entity_translation_support-1344672-447.patch70.39 KBcolan
PASSED: [[SimpleTest]]: [MySQL] 166 pass(es).
[ View ]
#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
#385 field_collection-entity_translation-1344672-385.patch67.8 KBhswong3i
PASSED: [[SimpleTest]]: [MySQL] 166 pass(es).
[ View ]
#391 field_collection-entity_translation-1344672-391.patch67.99 KBkrisgraham
PASSED: [[SimpleTest]]: [MySQL] 166 pass(es).
[ View ]
#401 field_collection-entity_translation-1344672-401.patch67.9 KBjkuma
PASSED: [[SimpleTest]]: [MySQL] 166 pass(es).
[ View ]
#402 field_collection-entity_translation-1344672-402.patch67.71 KBjkuma
PASSED: [[SimpleTest]]: [MySQL] 166 pass(es).
[ View ]
#406 field_collection-entity_translation-1344672-406.patch67.51 KBjoseph.olstad
PASSED: [[SimpleTest]]: [MySQL] 166 pass(es).
[ View ]
#406 interdiff_402_to_406.txt1.07 KBjoseph.olstad
#409 interdiff-1344672-406-409.txt1.17 KBLendude
#410 field_collection-entity_translation-1344672-410.patch68.01 KBLendude
PASSED: [[SimpleTest]]: [MySQL] 166 pass(es).
[ View ]
#421 field_collection-entity_translation-1344672-421.patch70.79 KBmistermoper
PASSED: [[SimpleTest]]: [MySQL] 166 pass(es).
[ View ]
#421 interdiff-1344672-410-421.txt3.16 KBmistermoper
#437 interdiff-1344672-430-437-do-not-test.patch1.85 KBdas-peter
#437 field_collection_field-1344672-437.patch70.86 KBdas-peter
PASSED: [[SimpleTest]]: [MySQL] 166 pass(es).
[ View ]
#441 field_collection_field-1344672-441-interdiff.txt1.27 KBkallehauge
#441 field_collection_field-1344672-441.patch70.1 KBkallehauge
PASSED: [[SimpleTest]]: [MySQL] 166 pass(es).
[ View ]

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
StatusFileSize
new21.51 KB
PASSED: [[SimpleTest]]: [MySQL] 78 pass(es).
[ View ]

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

StatusFileSize
new19.11 KB
FAILED: [[SimpleTest]]: [MySQL] 9 pass(es), 11 fail(s), and 17 exception(s).
[ View ]

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
StatusFileSize
new19.75 KB
FAILED: [[SimpleTest]]: [MySQL] 9 pass(es), 11 fail(s), and 17 exception(s).
[ View ]

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
StatusFileSize
new19.32 KB
PASSED: [[SimpleTest]]: [MySQL] 132 pass(es).
[ View ]
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.

Paul 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!

Paul Broon’s picture

StatusFileSize
new23.91 KB

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.

CRY_X2’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 :)

CRY_X2’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

StatusFileSize
new638 bytes
FAILED: [[SimpleTest]]: [MySQL] 123 pass(es), 10 fail(s), and 0 exception(s).
[ View ]

#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

StatusFileSize
new1.15 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch avoid_malformed_allow_additions-1344672-37.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

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

StatusFileSize
new18.22 KB
PASSED: [[SimpleTest]]: [MySQL] 132 pass(es).
[ View ]

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
StatusFileSize
new18.22 KB
PASSED: [[SimpleTest]]: [MySQL] 132 pass(es).
[ View ]

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

StatusFileSize
new18.62 KB
FAILED: [[SimpleTest]]: [MySQL] Invalid patch format in fiel_collection-17_and_37_complete-1344672-40.patch.
[ View ]

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
StatusFileSize
new19.06 KB
PASSED: [[SimpleTest]]: [MySQL] 132 pass(es).
[ View ]

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
StatusFileSize
new22.51 KB
PASSED: [[SimpleTest]]: [MySQL] 132 pass(es).
[ View ]

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

StatusFileSize
new23.11 KB
PASSED: [[SimpleTest]]: [MySQL] 132 pass(es).
[ View ]
new1.37 KB

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.

MDJ Webdiensten’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

StatusFileSize
new980 bytes
new23.18 KB
FAILED: [[SimpleTest]]: [MySQL] 132 pass(es), 0 fail(s), and 120 exception(s).
[ View ]

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
StatusFileSize
new1.15 KB
new23.2 KB
PASSED: [[SimpleTest]]: [MySQL] 132 pass(es).
[ View ]

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

StatusFileSize
new2.38 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch interdiff_66-72.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]
new28.42 KB
PASSED: [[SimpleTest]]: [MySQL] 132 pass(es).
[ View ]

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

StatusFileSize
new1.24 KB
new27.19 KB
PASSED: [[SimpleTest]]: [MySQL] 132 pass(es).
[ View ]

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
StatusFileSize
new880 bytes
new25.21 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch field_collection-et-1344672-87.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

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

StatusFileSize
new25.22 KB
PASSED: [[SimpleTest]]: [MySQL] 132 pass(es).
[ View ]

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

jmuzz’s picture

Status:Needs work» Needs review
klonos’s picture

@jmuzz: Thank you for working on this Joel!

...just a pointer: when uploading new patches, remember to hide the previous versions it means to replace ;)

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

StatusFileSize
new23.33 KB
PASSED: [[SimpleTest]]: [MySQL] 132 pass(es).
[ View ]

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

StatusFileSize
new3.38 KB

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.

DmitryDrozdik’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

<?php
 $entity
->is_new = FALSE;
?>

right after

<?php
 $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:

<?php
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

StatusFileSize
new3.39 KB
FAILED: [[SimpleTest]]: [MySQL] 124 pass(es), 8 fail(s), and 1 exception(s).
[ View ]
new227.51 KB

@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

StatusFileSize
new170 KB

@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.

<?php
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
StatusFileSize
new25.22 KB
PASSED: [[SimpleTest]]: [MySQL] 132 pass(es).
[ View ]

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
StatusFileSize
new27.47 KB
PASSED: [[SimpleTest]]: [MySQL] 132 pass(es).
[ View ]
new2.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

StatusFileSize
new3.33 KB
new26.68 KB
PASSED: [[SimpleTest]]: [MySQL] 132 pass(es).
[ View ]

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

StatusFileSize
new27.55 KB
PASSED: [[SimpleTest]]: [MySQL] 132 pass(es).
[ View ]

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.

Bobík’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
StatusFileSize
new28.48 KB
PASSED: [[SimpleTest]]: [MySQL] 132 pass(es).
[ View ]
new3.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?

nettantra’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
StatusFileSize
new28.27 KB
PASSED: [[SimpleTest]]: [MySQL] 132 pass(es).
[ View ]

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.

biswajeet parida’s picture

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.

biswajeet parida’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
StatusFileSize
new28.6 KB
PASSED: [[SimpleTest]]: [MySQL] 132 pass(es).
[ View ]

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

StatusFileSize
new3.04 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch field_collection_et.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

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

StatusFileSize
new3.36 KB
FAILED: [[SimpleTest]]: [MySQL] 131 pass(es), 1 fail(s), and 0 exception(s).
[ View ]

@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
StatusFileSize
new28.6 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch field_collection-et-1344672-187_0.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

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

StatusFileSize
new26.5 KB

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
StatusFileSize
new28.26 KB
PASSED: [[SimpleTest]]: [MySQL] 163 pass(es).
[ View ]

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

StatusFileSize
new28.51 KB
PASSED: [[SimpleTest]]: [MySQL] 163 pass(es).
[ View ]

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

StatusFileSize
new28.51 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch field_collection-et-1344672-228.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

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
bpwt’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

StatusFileSize
new27.13 KB

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

StatusFileSize
new26.84 KB

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

Placinta’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.

Placinta’s picture

StatusFileSize
new29.13 KB

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

Placinta’s picture

Status:Needs work» Needs review
StatusFileSize
new29.47 KB
PASSED: [[SimpleTest]]: [MySQL] 163 pass(es).
[ View ]
new1.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?

Placinta’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

StatusFileSize
new27.54 KB
PASSED: [[SimpleTest]]: [MySQL] 164 pass(es).
[ View ]

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

StatusFileSize
new27.54 KB
PASSED: [[SimpleTest]]: [MySQL] 164 pass(es).
[ View ]

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

StatusFileSize
new29.67 KB
PASSED: [[SimpleTest]]: [MySQL] 164 pass(es).
[ View ]

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
StatusFileSize
new30.06 KB
PASSED: [[SimpleTest]]: [MySQL] 164 pass(es).
[ View ]

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)

Placinta’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.

<?php
// 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.

Placinta’s picture

StatusFileSize
new31.62 KB
PASSED: [[SimpleTest]]: [MySQL] 164 pass(es).
[ View ]

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.

Placinta’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 :)

Placinta’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

Placinta’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

StatusFileSize
new33.7 KB
PASSED: [[SimpleTest]]: [MySQL] 164 pass(es).
[ View ]

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

StatusFileSize
new62.21 KB
PASSED: [[SimpleTest]]: [MySQL] 164 pass(es).
[ View ]

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

StatusFileSize
new59.39 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch field_collection-entity-translation-support-1344672-292.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]
new3.71 KB

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

StatusFileSize
new1.25 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch field_collection-et-1344672-295.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

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.

Pages