Updated: Comment #106


There are two approaches to translation in D7: translating nodes, and translating fields. Gábor Hojtsy explains both approaches fairly well in this blog post.

#1316162: Support content translation and host entity cloning talks about adding support for content translation, which I assume means the "old" approach of translating nodes.

Does anyone know if the second approach, i.e. field translation, is supported and working for this module? (Support for the entity translation module?).

Proposed resolution

See the attached patch that adds support for field translation.

Remaining tasks

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

#177 field_collection-et-1344672-177.patch28.27 KBjmuzz
PASSED: [[SimpleTest]]: [MySQL] 132 pass(es).
[ View ]
#130 field_collection-1344672.tar_.gz170 KByaoweizhen
#127 field_collection-1344672-108-v2.tar_.gz227.51 KBDarren Clark
#127 field-collection-et-1344672-108-v2.patch3.39 KBDarren Clark
FAILED: [[SimpleTest]]: [MySQL] 124 pass(es), 8 fail(s), and 1 exception(s).
[ View ]


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

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?

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

Any news for this issue?

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.

Sounds like a great idea to me!

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

Status:Active» Needs review
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.

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);
                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 = array('value' => $item['entity']->item_id);

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.

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

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.

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.

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

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.

Status:Needs work» Needs review
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.

Status:Needs work» Needs review
new19.32 KB
PASSED: [[SimpleTest]]: [MySQL] 132 pass(es).
[ View ]

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:

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

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

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

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

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

@malberts: Much obliged. This is very helpful!

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.

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

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.

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

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

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

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

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

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

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.

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.

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.

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?

Status:Needs work» Needs review
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.

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.

Status:Needs work» Needs review
new19.06 KB
PASSED: [[SimpleTest]]: [MySQL] 132 pass(es).
[ View ]

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

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

Assigned:Unassigned» plach

I am working on this.

Assigned:plach» Unassigned
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.

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

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.


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


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?

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


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

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?

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;
        $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)) {

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

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.

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


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.

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

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?


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

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

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

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

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.

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.

Status:Needs work» Needs review
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.

Status:Needs review» Needs work

I see an extra line in patch #66:

         'edit' => t('Edit'),
+        'translate' => t('Translate'),
+        'translate' => t('Translate'),

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.

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

($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

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

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

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?

Status:Needs work» Needs review

Status:Needs review» Needs work

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

Status:Needs work» Needs review

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

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

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

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.

Status:Needs work» Needs review

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) {
function _field_collection_show_translatable(&$element) {
  foreach (element_children($element) as $key) {
    if (!isset($element[$key]['#type'])) {
    else {
      $field_info = field_info_field($key);
      if ($field_info['type'] == 'field_collection') {
        $element[$key]['#multilingual'] = true;
        $element[$key]['#access'] = true;

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.

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.

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.

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.

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.

Status:Needs work» Needs review
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.


#72 and #79 reverted this commit:


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.

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

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

Status:Needs work» Needs review

@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 ;)

Patch #89 works fine for me.

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.

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

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

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


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?

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.

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

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.

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

Status:Needs review» Needs work

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

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

Issue summary:View changes

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.

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:

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

Translating fields issue (Martin's Blog):

- 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.
To suppress then this needs modifications to change if ($entity->is_new) { to if (@$entity->is_new) {


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.

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

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

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

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

Hi guys,

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

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.

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

@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

@Darren Clark

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

Just inserting

->is_new = FALSE;

right after

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

Patch #108 worked for me + #119 suggestion.

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


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

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

function field_collection_field_insert($host_entity_type, $host_entity, $field, $instance, $langcode, &$items) {
  foreach (
$items as &$item) {
    if (!empty(
$item)) {
      if (
$entity = field_collection_field_get_entity($item)) {
        if (!empty(
$entity->is_new)) {
$entity->setHostEntity($host_entity_type, $host_entity, LANGUAGE_NONE, FALSE);
$entity->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->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?


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!

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.

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

Thank you so much!

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


and not working. Help plz?

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:


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


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

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

new170 KB


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

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!

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.

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.

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.


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


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

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

- 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,

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

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.

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


There are some "solutions" on github. I used one of them for #138, but I don't remember which.

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.

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.

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

This leads into following error and notices:

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

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

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

Hi guys,

What status of this issue?

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.

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

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.

Status:Needs work» Needs review
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).

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

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

Status:Needs review» Needs work

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

Status:Needs work» Needs review
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.

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.

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?

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

just one field collection.

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

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

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.

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

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.

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

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

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

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

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.

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.

Status:Needs work» Needs review
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.

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.

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 {
    + ¶


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


  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?

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)

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.

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

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

Assigned:Unassigned» jmuzz

Assigned:jmuzz» Unassigned
Status:Needs work» Needs review
Issue tags:-Needs reroll
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.

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

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.

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.

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.

Category:Feature request» Bug report
Priority:Normal» Major


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.

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