After a recent update of Field Collection, Entity Translation, and i18n, I started seeing the following warning message:

"The entities of type Field collection item do not define a valid base path: it will not be possible to translate them."

My module versions are as follows:

Field Collection: 7.x-1.0-beta4+4-dev
Entity Translation: 7.x-1.x-dev (6-16-12)
i18n: 7.x-1.7

I'm not sure if this is a Field Collection issue or an Entity Translation issue, but given what I've read in other issue queues, I thought I'd start here. (Honestly, I'm not even sure if it's a problem because the fields comprising the field collection should still be translatable, but the warning message is an annoyance.)

Anyway, please let me know what your thoughts are on this.

Thanks,

C.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

msavike’s picture

Have the same problem here! if the warning messages critical or not, looking forward to a reply.

cossimo’s picture

Bumping... a reply really would be appreciated.

C.

Anonymous’s picture

Have the same problem with english & french website using field_collection and i8n
Look here : http://drupal.org/node/1513406
Solution seems to be in the Entity API : "I can confirm that updating to the April 2 dev release of Entity API resolves this error message."
I've downloaded the last version (rc3 on August 2012) and all is OK now.
Cooool :)

cossimo’s picture

Re: #3 -- I don't think this is the same issue. I was running Entity API 7.x-1.0-rc3 when I started having this problem. Plus, the error message is different.

cossimo’s picture

Category: support » bug

I'm finding that field collection is throwing the following errors when trying to edit or translate nodes with Field Collection fields that are set to translatable.

When editing, the following message appears:

Error message
Notice: Undefined index: en in field_collection_field_attach_form() (line 1142 of /[PATH]/sites/all/modules/field_collection/field_collection.module).

And when translating, the following messages appear:

Notice: Undefined offset: 1 in field_collection_field_widget_embed_validate() (line 1347 of /[PATH]/sites/all/modules/field_collection/field_collection.module).

EntityMalformedException: Missing bundle property on entity of type field_collection_item. in entity_extract_ids() (line 7562 of /[PATH]/includes/common.inc).

The errors render the node untranslatable, and translation has to be turned off for the field collection field in order to translate the node.

While I lack the skill set to contribute to resolving this issue, I'd be willing to subsidize anyone willing to fix this problem.

Thanks,

C.

phreaknerd’s picture

Status: Active » Needs review

Please have a look at this patch. Seems to fix the error from @cossimo.

The notice "The entities of type Field collection item do not define a valid base path: it will not be possible to translate them." appears because of a missing entity_translation_handler for field_collections. (Insight: field-collections are handled like nodes and so doesn't need an own handler but entity_translation throws this message anyway.)

cossimo’s picture

Thanks phreaknerd... I tested out the #6 patch, and it seems to move things closer, in that the errors in #5 no longer appear.

However, the message "Field Collection entities are untranslatable because they do not define valid base path" still occasionally appears and, more importantly, when translating field collections, the translated entities appear for all languages, regardless of the user's current language, effectively acting as if they were language neutral. (For example, if you have an English translation and a french translation of a field collection, both translations appear in English, French, and any other language active on the site.)

cossimo’s picture

Okay, I take that back. #6 works as advertised. I forgot that I was using Views to render the field collections (and the duplication across languages issue is a problem with Views -- http://drupal.org/node/1330332).

frikovc’s picture

I have same or similar issue as cossimo had - problems with field collection and translation of fields via entity translation. Tried everything I know - spend 2 days trying =(. Seemed the right place to post issue.

My configuration:
latest dev entity translation and field collection module + patch

I tried:
1. Entity translation is on just for taxonomy term and node, but not for field collection (it triggers notice: not translatible because of valid base path...)
I have taxonomy term with field collection (unlimited value). In FC field there are just two fields that needs to be translated. FC and fields inside FC have set "enable field translation by users".
With these settings I can create a term, set values to FC fields on default language and save. Then I can translate and set values to FC fields for second language and save. All good when checking if it did saved 2 different values - each for own language. Then I create view which is used on panels and is using termID as context filter. View has relationship on FC field and I added FC fields to show.

What happens: on view when i preview with term ID (context filter) i get correct result for the language in url (en/admin/structure/views..). Also when I change url to another languge prefix i get translated fields in that language. But translated fields don't show on actual term pages.

2. Beside what I described in 1., I also enable entity translation for field collection. Notice about valid base path is still there, but I applied patch and i don't get errors when adding or translating FC.
With this configuration I create fresh FC with new fields and enable field translation for all of them. On term I set some values for FC fields and save it. I repeat this step when translating. But when I save translations and open them they are empty. On the next fill they remain. But the view for this configuration is still not showing right values for selected languages.

Does anyone have any hint what I am doing wrong? I really need to fix this issue on my site and I am short on time.
What I need is to translate FC field (and it's fields) which can have unlimited values.
Any hints?

cossimo’s picture

frikovc: I have been having similar issues to what you describe in scenario 2. Next week, I will do some more testing and post more about my experiences as well.

frikovc’s picture

Because I am on a deadline I retested on clean installation. All this apply for what I described in #9. Same result but some new/confirmed observations and possible workaround:

There is a bug in FC when translating fields for the first time values are not properly saved:

  • values are saved but when I refresh edit page, fields exist but are empty/blank, fields on default language are ok
  • what really happens: when saving translation of FC fields, they are wrongfully linked to default language and not to translated one, also they don't show up when reopening default language so that they could be deleted. This can be bad if you accidentally catch them in a view as I did (for some time this was misleading me because titles were the same).
  • possible workaround: when first translating you have to delete values that are copied from default language and save it, then you can enter translated values
  • ET for FC enabled: same issue and workaround

After creating some content on terms and translating them with workaround, I tried to show them in panels via view.

  • I created a panel and set selection to taxonomy vocabulary I am using and under content I created "new custom content" in which I included some substitutions - for FC field %term:field_test_fc (this is my test content)
    • when I change language, values change accordingly to selected language
    • substitution renders all fields of FC and shows them in correct language
    • this is why this issue is bugging me… it should work on a view too because if term itself can distinguish between different languages of FC fields so can view via panel
  • I created view (page) in which I list all FC fields of all terms grouped by term name using relationship of that FC
    • content does change accordingly to the selected language =)
  • I created another view (content pane) as above and just added context filter, set it to termID and attach it to panels
    • view shows only FC fields of language that was used last when saving term. This mean that when editing and saving term in default language, view will only show fields of default language. weird :S
  • ET for FC enabled: it broke both views (showing fields of all languages everywhere), fixed by adding filter based on FC field: language and setting it to current user language
    • panels view still didn’t work as expected, but I knew that there was a problem with context filter
    • what I had to do is to remove validation criteria from context filter ( termID)

After solving last problem, view for panel is working and viewing term in both languages shows correct (translated) FC fields =).

@cossimo: can you test this workaround on your end?

Hope it helps understanding where problems occur and how to go around them. Fix would be nice though =).

phreaknerd’s picture

@frikovc: Can you check if this patch works for you? I've added the langcode to different functions so that the correct hostentity get's saved.

Status: Needs review » Needs work

The last submitted patch, field_collection_untranslatable-1683784-12.patch, failed testing.

frikovc’s picture

Status: Needs work » Needs review

Status: Needs review » Needs work

The last submitted patch, field_collection_untranslatable-1683784-12.patch, failed testing.

frikovc’s picture

@phreaknerd: patch failed because of the php syntax error (the line with == LANGUAGE_NONE), I used the original line and tried it on my test site.

@@ -943,13 +943,13 @@ function field_collection_field_formatter_view($entity_type, $entity, $field, $i
 /**
  * Helper function to add links to a field collection field.
  */
-function field_collection_field_formatter_links(&$element, $entity_type, $entity, $field, $instance, $langcode, $items, $display) {
+function field_collection_field_formatter_links(&$element, $entity_type, $entity, $field, $instance, $langcode == LANGUAGE_NONE, $items, $display) {

Problem is that when I create term and add 2 or 3 FC fields, fields in orignal language are saved. When I try to translate them, they are proprely prepopulated with content from original language and can be saved. Problem occur when I want to edit translation - all FC fields are empty, can not be removed or added, but they are showing in the views. On edit original language, content is there and also I can add or remove FC fields without a problem.

phreaknerd’s picture

Yeah, sorry. Will upload a new patch tomorrow. Meanwhile you can check the following:

* remove the option "translatable" from the field-items in the field-collection and mark only the field-collection itself as translatable.

frikovc’s picture

Yup that did the trick. This partially fix the problem described in #16 (empty fields), but the still can not add or remove FC fields on translated page. It throws:

EntityMalformedException: Missing bundle property on entity of type taxonomy_term. in entity_extract_ids() (line 7562 of .../includes/common.inc).

edit: I can delete translation and then translate again - during translation I can add or remove unlimited number of FC fields. After I save translation, content of saved fields can be altered, but fields themself can't be added or deleted.

But we are getting closer =).

frikovc’s picture

Sorry this was my mistake. Shouldn't use taxonomy localize with entity translation =).

Found new bug when I was testing term reference. Replicates on patched (#12) and not patched site. This probably isn't field collection fault.

  • I have created new taxonomy - localized terms,
  • created terms and orderd them hierarchically (didn't translate them yet)
  • created CT with field translation and add term reference field.
  • On creation of node of type CT, under term reference I can select all terms (this is test).
  • Then I translate most of terms via field translation
  • If I try to create node of type CT when using original language prefix in URL (one that term were created), under term reference I can select only non translated terms and terms that were translated but last saved in default language
  • If I try to create node of type CT when using translated language prefix in URL, under term reference I can select only terms that were last saved in translated language and terms that weren't translated


Also one funny thing happens, randomly (still didn't found pattern) after term edit and save, term jumps out of its original hierachical place (eg. from depth 2 to root).

phreaknerd’s picture

Status: Needs work » Needs review
FileSize
3.77 KB

The corrected patch.

One thing: The fc-edit-form that is shown when using the "Add"-link in view mode don't work properly. I have to add the language here too. The field-content is saved as 'und' actually.

frikovc’s picture

Thanks. Patch #20 works.

One thing: The fc-edit-form that is shown when using the "Add"-link in view mode don't work properly. I have to add the language here too. The field-content is saved as 'und' actually.

I add new fields via edit term form - FC field display is set to fields only. But probably that is same function.

remaye’s picture

Priority: Major » Normal
Status: Needs review » Needs work
Issue tags: -D7 stable release blocker

I tried to apply patch in #20 and it didn't fix the warning message :

"The entities of type Field collection item do not define a valid base path: it will not be possible to translate them."

But also I have maybe a slightly different behaviour :

- the message doesn't appear when editing or viewing Field Collection contents, but rather when validating modules admin page, or running update page or flushing cash (whatever page is displayed when flushing cash) and other admin pages
- the translated FC contents appears empty when I translate them for the first time, but after giving some values, translated fields keep their own values safe and display them properly.
- the "add" link is not working at all but displays no error message, just new FC item is not added neither in view and edit page.

I didn't try yet to recreate some new FC since I applied the patch (I'm running the same FC created before the patch), could it be the reason why it is not working.

Or is it a different issue ?

frikovc’s picture

Status: Needs review » Needs work

Notice is still there but FC fields are translatable and saved so that could be edited again.
I also had empty fields... trick is that you have to set FC field to be translatable, translation for fields in FC have to be disabled.

cossimo’s picture

The patch in #20 seems to work well. However, (and this may be a Views issue), the translated field collections do not appear to be filterable by language when rendered in Views -- i.e., all translations show up for all languages. This has been an ongoing problem for rendering translated entities in Views and was remedied with a recent patch (See http://drupal.org/node/1515156#comment-6301672), which exposes the language for translatable fields as potential Views filters.

However, the patched version of Views will not filter translated field collections by language (using the field collection field's language as the filter criteria), when using the field collection patch in #20 above and instructions outlined in this thread. It does seem that the patched version of Views can filter on the individual field items comprising the field collection when they are set to translatable. However, this conflicts with the instructions of #17 above... i.e.,

* remove the option "translatable" from the field-items in the field-collection and mark only the field-collection itself as translatable.

...and wreaks havoc on the ability to translate the field collections themselves.

Is there a way to expose the language of the field collection field itself so that Views can filter on it? Or is the field collection's language already exposed in a way that Views *should* be able to filter on?

Thanks,

C.

frikovc’s picture

@cossimo: you have to make relationship on FC to get access to fields in it

My configuration:
FC field is set to be translatable, fields in FC are not set to be translatable
I have a view that has relationship to FC field. Then I add fields from FC based on that relationship. Under filters I have added FC field language = user's current language.

If you want to append it to panel you also need to add term or node ID and set it without validation. Set argument from context:Term/Node ID

cossimo’s picture

Status: Needs work » Needs review

Re: #24 and #25:

After a little soul-searching and head-scratching, I figured out what I did wrong (and hopefully it will be helpful for anyone else creating views with translatable field collection fields). When I first created my views, I chose "Show Field Collection Item" instead of "Show Content" as the basis for the view. The field language filter will apparently not work if you do this.

So, for all you kids watching at home, don't do drugs... and always choose "Show Content" when creating a field collection view.

C.

PS... Props to phreaknerd... You are a lifesaver....

jackplain’s picture

carn1x’s picture

Status: Needs review » Needs work

Patch in #20 won't apply to latest dev. I'm new to patches though, so I could be a moron, however I'm running:

field_collection-$ patch -p1 < field_collection_untranslatable-1683784-20.patch 
patching file field_collection.module
Hunk #1 FAILED at 202.
Hunk #2 FAILED at 646.
Hunk #3 succeeded at 1249 (offset 306 lines).
Hunk #4 succeeded at 1643 (offset 350 lines).
2 out of 4 hunks FAILED -- saving rejects to file field_collection.module.rej

field_collection.module.rej:

***************
*** 202,208 ****
      if (!empty($this->is_new)) {
        $this->hostEntityType = $entity_type;;
        $this->hostEntity = $entity;
-       $this->langcode = LANGUAGE_NONE;
        list($this->hostEntityId) = entity_extract_ids($this->hostEntityType, $this->hostEntity);
        // If the host entity is not saved yet, set the id to FALSE. So
        // fetchHostDetails() does not try to load the host entity details.
--- 202,208 ----
      if (!empty($this->is_new)) {
        $this->hostEntityType = $entity_type;;
        $this->hostEntity = $entity;
+       $this->langcode = $langcode;
        list($this->hostEntityId) = entity_extract_ids($this->hostEntityType, $this->hostEntity);
        // If the host entity is not saved yet, set the id to FALSE. So
        // fetchHostDetails() does not try to load the host entity details.
***************
*** 646,657 ****
   * may be used to seamlessly create field collection items during host-entity
   * creation or to save changes to the host entity and its collections at once.
   */
- 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, LANGUAGE_NONE, FALSE);
        }
        $item['entity']->save(TRUE);
        $item = array('value' => $item['entity']->item_id);
--- 646,657 ----
   * may be used to seamlessly create field collection items during host-entity
   * creation or to save changes to the host entity and its collections at once.
   */
+ function field_collection_field_presave($entity_type, $entity, $field, $instance, $langcode = LANGUAGE_NONE, &$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);
        }
        $item['entity']->save(TRUE);
        $item = array('value' => $item['entity']->item_id);
bartdepotter’s picture

Patch#20 works on field_collection 7.x-1.0-beta4.

A problem I ran into was that my new translated content was not entered the first time it was saved.
The fields went blank after saving the translation for the first time. When entering new content in the empty fields everything seems to work fine.

After some testing I figured out that removing the content first, through the 'Remove' button, the fields are also saved.

It's not an ideal solution but I can now translate content with field collections.

bartdepotter’s picture

Post #25 solved my problem.
Now my translation is saved without first removing the original content.

So only enable translation on the FieldCollection field and not on the fields inside the FieldCollection.

Thanks @frikovc.

kscheirer’s picture

Priority: Normal » Major
Status: Needs work » Needs review
Issue tags: +D7 stable release blocker

What's the status of this issue? Is the patch in #20 RTBC?

Status: Needs review » Needs work

The last submitted patch, field_collection_untranslatable-1683784-20.patch, failed testing.

stijndm’s picture

Attached is an updated version of the patch for beta5

kscheirer’s picture

Status: Needs work » Needs review

setting to needs review to get testbot on it...

Status: Needs review » Needs work

The last submitted patch, field_collection_untranslatable.patch, failed testing.

Hydra’s picture

Shouldn't be the patch applyng agains dev instead of beta??

Hydra’s picture

Status: Needs work » Needs review

change status

Martin Mayer’s picture

I applied the patch from #36. I still get this warnings:

Invalid translate path defined for entities of type Field collection item: parent menu item not found for field_collection_item/%field_collection_item

The entities of type Field collection item do not define a valid path scheme: it will not be possible to translate them.

Berdir’s picture

+++ b/field_collection.moduleundefined
@@ -885,7 +885,7 @@ function field_collection_field_settings_form($field, $instance) {
-function field_collection_field_presave($host_entity_type, $host_entity, $field, $instance, $langcode, &$items) {
+function field_collection_field_presave($host_entity_type, $host_entity, $field, $instance, $langcode = LANGUAGE_NONE, &$items) {

@@ -1252,13 +1252,13 @@ function field_collection_field_formatter_view($entity_type, $entity, $field, $i
-function field_collection_field_formatter_links(&$element, $entity_type, $entity, $field, $instance, $langcode, $items, $display) {
+function field_collection_field_formatter_links(&$element, $entity_type, $entity, $field, $instance, $langcode = LANGUAGE_NONE, $items, $display) {

This is not necessary.

$langcode can not be left out as there are required values afterwards.

chriscalip’s picture

#39 What are you trying to say? The function definition does not need updating to include $langcode having a default value of LANGUAGE_NONE ? is that your trying to say?

Berdir’s picture

Exactly.

chriscalip’s picture

mattez’s picture

#42 YEAH works! THANX a lot. This PATCH saves my day.

remaye’s picture

Priority: Normal » Major
Status: Needs work » Needs review
Issue tags: +D7 stable release blocker

Not working at all for me.

The entities of type Field collection item do not define a valid base path: it will not be possible to translate them.

is still here and behaviour describe in #22 remain the same.

When I create a new field_collection item using the "add item" link it add a field_collection with "und" language and indeed the new field doesn't appear in "fr" nor "en" language. If I change the "language" field in the database to "fr", it does appear in the "fr" page. And there is no way to set the language in the field_collection item edit form.

I don't know how this is related to the warning message (if it is) but there something not working well with field_collection language affectation...

eristoddle’s picture

Here is what is working for me currently (crossing fingers). I didn't create a patch file because I am unsure if this was the correct way to do things or not. But I found that every time I created a field collection, the collection itself would be in the right language, but the fields were always und. Unless I created a translation and came back and edited the original. Right about line 897 in the field_collection_field_presave function of field_collection.module, I added this:

if (!empty($entity->is_new)) {
          //Set each field language - patch
          foreach($item as $key => $fc_item){
            if(is_array($fc_item)){
              if(!in_array($langcode, array_keys($fc_item)) && in_array('und',array_keys($fc_item))){
                $entity->{$key}[$langcode] = $fc_item['und'];
              }
            }
          }
          //End patch
          $entity->setHostEntity($host_entity_type, $host_entity, $langcode, FALSE);
        

Which doesn't quite work. If I add a translation after the initial add, I have to save it twice to stick.

kscheirer’s picture

Good docs on creating a patch: https://drupal.org/node/707484

malberts’s picture

I've posted a patch at #1344672-17: Field Collection: Field translation (entity_translation) support. that attempts to bring in proper support for Entity Translations. Please have a look there.

eristoddle’s picture

Yeah, mine was a hack. Which is why I didn't create a patch. That patch semi-works. And seeing it, I realized how involved this whole fix is.

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

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

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

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

klonos’s picture

...so should we close this one as a duplicate of the other issue then?

malberts’s picture

Status: Needs review » Closed (duplicate)

I think so. This issue describes a sub-issue of integrating Entity Translation.

Marking as a duplicate of #1344672: Field Collection: Field translation (entity_translation) support.

RaulMuroc’s picture

Issue summary: View changes

And patch in #42 should not be included in the other issue?

Naim BELKAIED’s picture

You can resolve this by disabling translation of field inside the field collection, the translation must be only related to field collection .

codevoice’s picture

> You can resolve this by disabling translation of field inside the field collection, the translation must be only related to field collection .

Definitely not in my case, none of the field collections themselves have translation enabled, but I still suffer from these warnings.